From mip6-bounces@ietf.org Fri Jun 01 00:25: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 1HtygZ-0008Lp-8V; Fri, 01 Jun 2007 00:24:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtygY-0008Hd-IF for mip6@ietf.org; Fri, 01 Jun 2007 00:24:22 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtygV-0001Di-Nz for mip6@ietf.org; Fri, 01 Jun 2007 00:24: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 l514OGZ29712; Fri, 1 Jun 2007 04:24:17 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 23:24:13 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114A14EC7@zrc2hxm2.corp.nortel.com> In-Reply-To: <20070601024004.QMMD5805.oaamta01sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcejsVbfS40lMgyLQl23peLZkTLpugAFaWnwAAugWzAAAgC4oA== References: <6FC4416DDE56C44DA0AEE67BC7CA437114A14D57@zrc2hxm2.corp.nortel.com> <20070601024004.QMMD5805.oaamta01sl.mx.bigpond.com@PC20005> From: "Ahmad Muhanna" To: "Hesham Soliman" , "Brian Haley" X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 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 Hesham, Please see comments inline. Regards, Ahmad =20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Thursday, May 31, 2007 9:40 PM > To: Muhanna, Ahmad (RICH1:2H10); 'Brian Haley' > Cc: mip6@ietf.org > Subject: RE: [Mip6] FW: I-D=20 > ACTION:draft-muhanna-mip6-binding-revocation-00.txt >=20 > Hi Ahmad, >=20 > > > > The scope of the generic notification messages, as per the=20 > > draft text, > is to send opaque data with an=20 > Informational nature by > introducing a new > encapsulating=20 > header (generic notification message), if I may call it >=20 > that, inside the Mobility Header itself to be used for=20 > communicating > some generic information (fyi) to the MN.=20 >=20 > =3D> So are you suggesting that the information in draft-haley=20 > should not be opaque? Opaque is a strange word anyway when=20 > the information is sent to the ultimate receiver of the=20 > message. If that's the suggestion then I think it's doable.=20 >=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=20 > message to MAG1 in > order for > MAG1 to clean resources=20 > associated with the MN; Here, BRI1 revokes a > PMIPv6 BCE. > > 4. Let us assume that the MN moved to Access 3, where=20 > PMIPv6 is not > deployed and MN used MIPv6 for global=20 > mobility with the same HA1. BCE > Flag=3D MIPv6. > > 5. If the home domain decides to revoke the MN BCE, the=20 > HA1 sends a > BRI2. Here, BRI2 revokes a MIPv6 BCE. >=20 > =3D> That's fine but you didn't explain why this is not doable=20 > in draft-haley? > You can simply define a message to be carried in his=20 > notification header, what's wrong with that?=20 [Ahmad] Let me clarify one thing here. draft-hanley defines a messaging container mechanism via generic notification messages. According to that draft and its scope, the details of a functionality like revocation, which possibly can be carried inside the generic notification messages, is to be defined in a different draft anyway. In other words, even if we agree to define a subtype for revocation messages in the generic notification messages, (as you just suggested) the details of the revocation mechanism needs to be captured in a different draft anyway. I just would like to point that out and put it behind us. =20 On the other hand, I actually expressed before, that anything is possible and we can make anything to work. The question is, what is the best most flexible and efficient way for achieving the same outcome. ** It reminds me with the GRE issue related to DSMIP6, when you felt that defining a new TLV introduces an unnecessary overhead while others argued that there is a valid need for such TLV which justify the overhead **. (sorry for bringing that here, I am just trying to make a comparison not to argue about it). It seems that I am always on the other side:-) Anyway, you probably missed my other email, in which I pointed out that we definitely have two available options here. Snip ++++++++++++++++++++ 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. +++++++++++++++++++++ snip I, personally, believe that defining separate MH types for revocation messages (option 1) is more flexible and efficient than defining the same messages within the generic notification messages. It is more relevant since it is a control message similar to BU/BA. Otherwise, we could argue that all IPv6 mobility control messages can anyway be masked and embedded in the generic notification messages. In other words, we are creating another messaging container within the Mobility Header itself. May be in the near future some people will argue that another level/container within the generic notification message is necessary too!:)=20 I just do not see why using another messaging container to mask the revocation messages within the Mobility header is necessary! =20 >=20 > Hesham >=20 > > > > One last thing, Do you see a problem by using a separate=20 > MH types for > revocation messages to define one revocation =20 > > 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:=20 > Thursday, May 31, 2007 1:27 PM > > To: Muhanna, Ahmad=20 > (RICH1:2H10) > > Cc: mip6@ietf.org > > Subject: Re: [Mip6]=20 > 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=20 > is for > > >> Mip4 registration revocation. So maybe that=20 > set a > > precedence to do > > >> this separately? > > > > > > > > [Ahmad] > > > > I agree.=20 > > > > > > > > IMO, revocation mechanism is more of a control=20 > mechanism than > > > informational. It is similar to the=20 > registration > messages since it > > > impacts the state of=20 > the MN binding and the allocated resources.=20 > > > > Having said that, I believe we probably have a couple=20 > of > > options here: > > > > > > > > Option 1: > > > > Is to have the revocation messages stands out as a >=20 > separate MH type > > > messages. This is similar to what=20 > Mobile IPv4 has in RFC3543 and > > > detailed in the Binding=20 > Revocation for IPv6 Mobility draft. > > > > > > > > -OR- > > > > > > > > Option 2: > > > > Since the MH generic message type allows only for=20 > options to be > > > defined (in separate drafts) and=20 > including all the > > revocation related > > > information=20 > 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) > > > can be used to define the type of=20 > message that is > included in the > > > generic=20 > notification message. > > > > > > I don't follow you here. Your Binding Revocation=20 > Indication > > Message is very similar to the Signaling=20 > Request Message in > > draft-haley, having a Revoke=20 > sub-option (with some flags) > > doesn't seem like it's that=20 > different. > > > > > > The one thing that would be different is if you're=20 > sending > > multiple sub-options containing revocation=20 > information - they > > might be considered at different=20 > "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 > > > > > > So in the top case, how do you associate the Session=20 > options > > with the Revocation option, they're all just=20 > options, right? =20 > > > You'd just have to have very specific processing rules=20 > (like > > we do for Binding Cache Information Options in the=20 > > > ha-reliability draft). I can understand this problem,=20 > since > > as you define more options it could get difficult=20 > - 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 > >=20 >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 01 01:42: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 1HtztM-00079G-KX; Fri, 01 Jun 2007 01:41:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtztL-00078v-1D for mip6@ietf.org; Fri, 01 Jun 2007 01:41:39 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtztJ-0001OA-6g for mip6@ietf.org; Fri, 01 Jun 2007 01:41:39 -0400 Received: from oaamta05sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070601054134.FJRG25724.omta05sl.mx.bigpond.com@oaamta05sl.mx.bigpond.com>; Fri, 1 Jun 2007 05:41:34 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta05sl.mx.bigpond.com with ESMTP id <20070601054133.HXNH7523.oaamta05sl.mx.bigpond.com@PC20005>; Fri, 1 Jun 2007 05:41:33 +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 15:41:27 +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: <6FC4416DDE56C44DA0AEE67BC7CA437114A14EC7@zrc2hxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcejsVbfS40lMgyLQl23peLZkTLpugAFaWnwAAugWzAAAgC4oAAEMlsg Message-Id: <20070601054133.HXNH7523.oaamta05sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 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 > > => 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? > > [Ahmad] > > Let me clarify one thing here. draft-hanley defines a messaging > container mechanism via generic notification messages. > According to that > draft and its scope, the details of a functionality like revocation, > which possibly can be carried inside the generic > notification messages, > is to be defined in a different draft anyway. In other > words, even if we > agree to define a subtype for revocation messages in the generic > notification messages, (as you just suggested) the details of the > revocation mechanism needs to be captured in a different > draft anyway. I > just would like to point that out and put it behind us. => Yes that's true of course. > > On the other hand, I actually expressed before, that anything is > possible and we can make anything to work. The question is, > what is the > best most flexible and efficient way for achieving the same > outcome. => Ok, so what is that most flexible way? > > Snip > ++++++++++++++++++++ > 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. > +++++++++++++++++++++ > snip > > I, personally, believe that defining separate MH types for revocation > messages (option 1) is more flexible and efficient than defining the > same messages within the generic notification messages. It is more > relevant since it is a control message similar to BU/BA. => Ok, it's clear that this is your belief. What's not clear is why you think it's efficient and flexible. This is a one message that is not sent frequently to the MN, so what efficiency metrics do you use to come to this conclusion? I think it's a waste (albeit not so significant of course) to define a new MH type just for this message. I really don't care which way this goes because both will work with little differences. I'm trying to understand why we're talking so much about this and what the differences are, if any. I don't really see much difference. > > > > > > 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? => Other than wasting a new MH type, I see zero practical differences. Hesham > > > > > > 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 From mip6-bounces@ietf.org Fri Jun 01 02:59:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu164-0004lN-JQ; Fri, 01 Jun 2007 02:58:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu162-0004lE-IE for mip6@ietf.org; Fri, 01 Jun 2007 02:58:50 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu162-00081G-1k for mip6@ietf.org; Fri, 01 Jun 2007 02:58:50 -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 l516wkZ13029; Fri, 1 Jun 2007 06:58:47 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: Fri, 1 Jun 2007 01:58:44 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114A14F21@zrc2hxm2.corp.nortel.com> In-Reply-To: <20070601054133.HXNH7523.oaamta05sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcejsVbfS40lMgyLQl23peLZkTLpugAFaWnwAAugWzAAAgC4oAAEMlsgAADb+qA= References: <6FC4416DDE56C44DA0AEE67BC7CA437114A14EC7@zrc2hxm2.corp.nortel.com> <20070601054133.HXNH7523.oaamta05sl.mx.bigpond.com@PC20005> From: "Ahmad Muhanna" To: "Hesham Soliman" , "Brian Haley" X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 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 Hesham, Please see comments inline. Regards, Ahmad =20 > > > > [Ahmad] > > > > Let me clarify one thing here. draft-hanley defines a=20 > messaging > container mechanism via generic notification messages.=20 > > According to that > > draft and its scope, the details of a functionality like=20 > revocation, > which possibly can be carried inside the=20 > generic > notification messages, > is to be defined in a=20 > different draft anyway. In other > words, even if we >=20 > agree to define a subtype for revocation messages in the=20 > generic > notification messages, (as you just suggested) the=20 > details of the > revocation mechanism needs to be captured=20 > in a different > draft anyway. I > just would like to point=20 > that out and put it behind us. >=20 > =3D> Yes that's true of course. [Ahmad] That is good. >=20 > > > > On the other hand, I actually expressed before, that=20 > anything is > possible and we can make anything to work. The=20 > question is, > what is the > best most flexible and=20 > efficient way for achieving the same > outcome.=20 >=20 > =3D> Ok, so what is that most flexible way? [Ahmad] Please see my comments below. Just to address the whole thing in one place.=20 >=20 >=20 > > > > Snip > > ++++++++++++++++++++ > > Option 1: > > Is to have the revocation messages stands out as a=20 > separate MH type > messages. This is similar to what Mobile=20 > IPv4 has in RFC3543 and > detailed in the Binding Revocation=20 > for IPv6 Mobility draft. > > > > -OR- > > > > Option 2: > > Since the MH generic message type allows only for options=20 > to > be defined > (in separate drafts) and including all=20 > the revocation related > information would not be possible=20 > in a single option (unless > it becomes > a message), then=20 > a subtype (as the first byte after the MH) > can be used >=20 > to define the type of message that is included in the generic=20 > > notification message. > > +++++++++++++++++++++ > > snip > > > > I, personally, believe that defining separate MH types for=20 > revocation > messages (option 1) is more flexible and=20 > efficient than defining the > same messages within the=20 > generic notification messages. It is more > relevant since=20 > it is a control message similar to BU/BA.=20 >=20 > =3D> Ok, it's clear that this is your belief. What's not clear=20 > is why you think it's efficient and flexible. This is a one=20 > message that is not sent frequently to the MN, so what=20 > efficiency metrics do you use to come to this conclusion? I=20 > think it's a waste (albeit not so significant of course) to=20 > define a new MH type just for this message.=20 [Ahmad] Again, Please see the comments below. >=20 > I really don't care which way this goes because both will=20 > work with little differences. I'm trying to understand why=20 > we're talking so much about this and what the differences=20 > are, if any. I don't really see much difference.=20 >=20 > > > > > > > > One last thing, Do you see a problem by using a=20 > separate > > MH types for > revocation messages to define=20 > one revocation > > > mechanism/messages which is >=20 > applicable to MIPv6 and PMIPv6? >=20 > =3D> Other than wasting a new MH type, I see zero practical=20 > differences.=20 [Ahmad] Since most of your questions are, basically, related to efficiency, I would like to address everything in one place. If the whole concept behind the generic notification message is to AVOID and SAVE a new MH type and basically mask all future IPv6 mobility control related messages, then I believe that the proposed mechanism as per draft-haley is inefficient and all what we need is the following: 1. In order to enable the generic notification mechanism, we need to define/reserve a specific MH Type (TBD=3DGeneric Mobility Header) which identifies the presence of a two bytes (Generic Mobility Header, GMH) at the end of the Mobility header which, if included ALONE makes the mobility header length equal to ZERO. 2. These two bytes (GMH) are used to define a 64k subtypes for the Generic Mobility Header. 3. Each subtype define a single message, for example, 01: Binding Revocation Indication, 02: Binding Revocation Acknowledgement, 03: etc. 4. Separate drafts, like Binding Revocation for IPv6 Mobility, for example, defines the messages format and describe in details the revocation mechanism. Now, why I think this or a separate messages is more efficient than what is already defined and proposed in draft-haley? 1. Since the whole objective here is to save MH type, we eliminate the need for defining two messages, generic notification message and generic notification acknowledgement. 2. We eliminated the use of the generic notification sequence number which may be limited in here. As a matter of fact, why do we need that if the new functionality is going to define all the needed formats and details. 3. We define the details of the revocation mechanism, for example, independently without any possible conflict with the generic message A bit, for example. In other words, the A bit is defined where it is mattered most, i.e. in the Binding Revocation Indication message, rather than in the masking container structure. Moreover, all needed bits will be defined and processed in one place rather defining the Acknowledgement bit in the container header, while figuring out the Global bit inside the Binding Revocation Indication message, just as an example. 4. Provide the flexibility to define any other messaging protocol without being restricted with the rules of the generic notification messages mechanism and whatever limitations it may have. 5. If this messaging mechanism is really generic in the full sense, how anyone expect that one byte of status is enough to address all possible status for all the possible functionalities that could ever be masked/encapsulated using this generic messaging mechanism. In other words, I believe that the status should be moved from the Generic notification message header to the specific message, where it is more relevant. For example, what the following status has to do with revocation mechanism, for example: "130 Insufficient resources". I thought we are trying to FREE resources here! 6. Why do we have to define retransmission for this generic notification messaging mechanism. Is not this supposed to be generic enough to fit the need of any functionality that we may think of. Is not there is a possibility that we define a functionality that depends on best effort that does not require retransmission. 7. Finally, how do we expect to have this mechanism generically sound and at the same time we define limitation that may or may not work for all generic functionalities that could be masked/encapsulated inside such container, for example, why do you think that the following timeouts is applicable to all functionalities. I believe that these numbers need to be defined specifically by each functionality. INITIAL_MH_SIGNAL_TIMEOUT 5 seconds MAX_MH_SIGNAL_TIMEOUT 20 seconds 8. I hope that you would agree that using the generic notification messages mechanism as per the current proposed mechanism in draft-haley is not the most efficient mechanism to protect and save MH types and at the same time offer a generic enough mechanism to contain almost any possible generically sound functionality. 9. Finally, if we are concerned to preserve what left of the MH types, I believe the above proposed Generic Mobility Header is the best way to go forward. "2 bytes of 64k subtypes" that simple. >=20 > Hesham >=20 > > > > > > > > Thanks in advance. > > > > > > > > Regards, > > > > Ahmad > > > > > > > > > -----Original Message----- > > > > > From: Brian Haley [mailto:brian.haley@hp.com] > > Sent:=20 > > > Thursday, May 31, 2007 1:27 PM > > To: Muhanna, Ahmad =20 > > > (RICH1:2H10) > > Cc: mip6@ietf.org > > Subject: Re:=20 > [Mip6] > > FW: I-D > >=20 > ACTION:draft-muhanna-mip6-binding-revocation-00.txt > > > > > > > > > > Hi Ahmad, > > > > > > > > > > Comments inline. > > > > > > > > > > Ahmad Muhanna wrote: > > > > > >> Correction. It was pointed out to me that RFC=20 > 3543 > > is for > > >> Mip4 registration revocation. So=20 > maybe that > > set a > > precedence to do > > >> this separately? > > > > > > > > > > > > [Ahmad] > > > > > > I agree.=20 > > > > > > > > > > > > IMO, revocation mechanism is more of a control >=20 > > mechanism than > > > informational. It is similar to the =20 > > > registration > messages since it > > > impacts the=20 > state of > > the MN binding and the allocated resources.=20 > > > > > > Having said that, I believe we probably have a=20 > couple > > of > > options here: > > > > > > > > > > > > Option 1: > > > > > > Is to have the revocation messages stands out as=20 > a > > > separate MH type > > > messages. This is similar=20 > to what > > Mobile IPv4 has in RFC3543 and > > > detailed=20 > in the Binding > > Revocation for IPv6 Mobility draft. > > > > > > > > > > > > -OR- > > > > > > > > > > > > Option 2: > > > > > > Since the MH generic message type allows only for=20 > > > options to be > > > defined (in separate drafts) and >=20 > > including all the > > revocation related > > >=20 > information > > would not be possible in a single option=20 > (unless it > > > > > becomes a message), then a subtype (as=20 > the first byte > > > after the MH) > > > can be used to=20 > define the type of > > message that is > included in the >=20 > > > generic > > notification message. > > > > > > > > > > I don't follow you here. Your Binding Revocation =20 > > > Indication > > Message is very similar to the Signaling =20 > > > Request Message in > > draft-haley, having a Revoke > >=20 > sub-option (with some flags) > > doesn't seem like it's that=20 > > > different. > > > > > > > > > > The one thing that would be different is if you're =20 > > > sending > > multiple sub-options containing revocation =20 > > > information - they > > might be considered at different =20 > > > "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 > > > > > > > > > > So in the top case, how do you associate the=20 > Session > > options > > with the Revocation option, they're=20 > all just > > options, right? =20 > > > > > You'd just have to have very specific processing=20 > rules > > (like > > we do for Binding Cache Information=20 > Options in the > > > > ha-reliability draft). I can=20 > understand this problem, > > since > > as you define more=20 > options it could get difficult > > - is this > > the main=20 > 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 > > > > > > > > > > > > > > >=20 >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 01 04:23: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 1Hu2Oq-0005Eg-Ed; Fri, 01 Jun 2007 04:22:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu2Op-0005EY-JG for mip6@ietf.org; Fri, 01 Jun 2007 04:22:19 -0400 Received: from nz-out-0506.google.com ([64.233.162.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu2Oo-0004sk-7E for mip6@ietf.org; Fri, 01 Jun 2007 04:22:19 -0400 Received: by nz-out-0506.google.com with SMTP id z31so421912nzd for ; Fri, 01 Jun 2007 01:22:17 -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=TVmmbojhuc4QvGsKft6pie4IbcDBIcBP4i2y3StUYZDtxr1CgxD7l9eXXm4riSyqwXrRK6ASNCN7+9JWeJ0CNyXmA/iJpOtk4Zfaw5mF8Nrr5zl17IjNxB4NbxP/kyQ3EJnFscorPl2QeF88DFl96RDSrdBNSkYW1UXPMiMZ+bU= 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=XsgSWNTH7jF8w1GOcrV4++4NWYnyR6iIB8SQGj6VmfVz5r8F/sToDKEDdq/tetiE68jw6awiG8eGBuoN+bhTV8/kzAYvwf3xR2XSeviYwf2vPQTZEjAMZY0tg7OGvkWnZ6+Sl2ZSsHFXtPaYPKNwHO2M26/FNaG7HRj41rR2Glk= Received: by 10.114.184.16 with SMTP id h16mr1596058waf.1180686133145; Fri, 01 Jun 2007 01:22:13 -0700 (PDT) Received: from ?203.178.143.191? ( [203.178.143.191]) by mx.google.com with ESMTP id m10sm670186waf.2007.06.01.01.22.09; Fri, 01 Jun 2007 01:22:10 -0700 (PDT) In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437114A14F21@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437114A14EC7@zrc2hxm2.corp.nortel.com> <20070601054133.HXNH7523.oaamta05sl.mx.bigpond.com@PC20005> <6FC4416DDE56C44DA0AEE67BC7CA437114A14F21@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: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Date: Fri, 1 Jun 2007 17:22:05 +0900 To: Ahmad Muhanna X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Cc: mip6@ietf.org, Brian Haley 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 and Hesham, Sorry Hesham, let me jump in this thread. On 2007/06/01, at 15:58, Ahmad Muhanna wrote: > Hi Hesham, > Please see comments inline. > > Regards, > Ahmad > > >>> >>> [Ahmad] >>> >>> Let me clarify one thing here. draft-hanley defines a >> messaging > container mechanism via generic notification messages. >>> According to that >>> draft and its scope, the details of a functionality like >> revocation, > which possibly can be carried inside the >> generic > notification messages, > is to be defined in a >> different draft anyway. In other > words, even if we > >> agree to define a subtype for revocation messages in the >> generic > notification messages, (as you just suggested) the >> details of the > revocation mechanism needs to be captured >> in a different > draft anyway. I > just would like to point >> that out and put it behind us. >> >> => Yes that's true of course. > > [Ahmad] > That is good. >> >>> >>> On the other hand, I actually expressed before, that >> anything is > possible and we can make anything to work. The >> question is, > what is the > best most flexible and >> efficient way for achieving the same > outcome. >> >> => Ok, so what is that most flexible way? > > [Ahmad] > Please see my comments below. Just to address the whole thing in one > place. >> >> >>> >>> Snip >>> ++++++++++++++++++++ >>> 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. >>> +++++++++++++++++++++ >>> snip >>> >>> I, personally, believe that defining separate MH types for >> revocation > messages (option 1) is more flexible and >> efficient than defining the > same messages within the >> generic notification messages. It is more > relevant since >> it is a control message similar to BU/BA. >> >> => Ok, it's clear that this is your belief. What's not clear >> is why you think it's efficient and flexible. This is a one >> message that is not sent frequently to the MN, so what >> efficiency metrics do you use to come to this conclusion? I >> think it's a waste (albeit not so significant of course) to >> define a new MH type just for this message. > > [Ahmad] > Again, Please see the comments below. >> >> I really don't care which way this goes because both will >> work with little differences. I'm trying to understand why >> we're talking so much about this and what the differences >> are, if any. I don't really see much difference. >> >>>>> >>>>> 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? >> >> => Other than wasting a new MH type, I see zero practical >> differences. > > [Ahmad] > Since most of your questions are, basically, related to efficiency, I > would like to address everything in one place. > If the whole concept behind the generic notification message is to > AVOID > and SAVE a new MH type and basically mask all future IPv6 mobility > control related messages, then I believe that the proposed > mechanism as > per draft-haley is inefficient and all what we need is the following: > > 1. In order to enable the generic notification mechanism, we need to > define/reserve a specific MH Type (TBD=Generic Mobility Header) which > identifies the presence of a two bytes (Generic Mobility Header, > GMH) at > the end of the Mobility header which, if included ALONE makes the > mobility header length equal to ZERO. > > 2. These two bytes (GMH) are used to define a 64k subtypes for the > Generic Mobility Header. > 3. Each subtype define a single message, for example, 01: Binding > Revocation Indication, 02: Binding Revocation Acknowledgement, 03: > etc. > 4. Separate drafts, like Binding Revocation for IPv6 Mobility, for > example, defines the messages format and describe in details the > revocation mechanism. > > Now, why I think this or a separate messages is more efficient than > what > is already defined and proposed in draft-haley? > > 1. Since the whole objective here is to save MH type, we eliminate the > need for defining two messages, generic notification message and > generic > notification acknowledgement. Isn't this such big issue?! Anyway, if you have a new MH, you should consider the IPsec setting up. The MH type is now a selector in IPsec, you need additional SAD/SPD for the new revocation message?! > > 2. We eliminated the use of the generic notification sequence number > which may be limited in here. As a matter of fact, why do we need that > if the new functionality is going to define all the needed formats and > details. You can always overwrite the draft-haley in your document. > 3. We define the details of the revocation mechanism, for example, > independently without any possible conflict with the generic message A > bit, for example. In other words, the A bit is defined where it is > mattered most, i.e. in the Binding Revocation Indication message, > rather > than in the masking container structure. Moreover, all needed bits > will > be defined and processed in one place rather defining the > Acknowledgement bit in the container header, while figuring out the > Global bit inside the Binding Revocation Indication message, just > as an > example. > > 4. Provide the flexibility to define any other messaging protocol > without being restricted with the rules of the generic notification > messages mechanism and whatever limitations it may have. > > 5. If this messaging mechanism is really generic in the full sense, > how > anyone expect that one byte of status is enough to address all > possible > status for all the possible functionalities that could ever be > masked/encapsulated using this generic messaging mechanism. In other > words, I believe that the status should be moved from the Generic > notification message header to the specific message, where it is more > relevant. For example, what the following status has to do with > revocation mechanism, for example: "130 Insufficient resources". I > thought we are trying to FREE resources here! > Can you define your status field in your options?? > 6. Why do we have to define retransmission for this generic > notification > messaging mechanism. Is not this supposed to be generic enough to fit > the need of any functionality that we may think of. Is not there is a > possibility that we define a functionality that depends on best effort > that does not require retransmission. Retransmission is required, because MH does not provide reliable transmission. If you don't want retransmission, you just override that spec. in your document... The haley's draft defines a generic MH message, you can always overwrite it as you want. Otherwise, nobody can use draft-haley... > 7. Finally, how do we expect to have this mechanism generically sound > and at the same time we define limitation that may or may not work for > all generic functionalities that could be masked/encapsulated inside > such container, for example, why do you think that the following > timeouts is applicable to all functionalities. I believe that these > numbers need to be defined specifically by each functionality. > > INITIAL_MH_SIGNAL_TIMEOUT 5 seconds > MAX_MH_SIGNAL_TIMEOUT 20 seconds please overwrite it... RFC3775 also overrides the constant value of RFC2461. > 8. I hope that you would agree that using the generic notification > messages mechanism as per the current proposed mechanism in draft- > haley > is not the most efficient mechanism to protect and save MH types > and at > the same time offer a generic enough mechanism to contain almost any > possible generically sound functionality. > > 9. Finally, if we are concerned to preserve what left of the MH > types, I > believe the above proposed Generic Mobility Header is the best way > to go > forward. "2 bytes of 64k subtypes" that simple. Finally, I feel the same with Hesham. I am fine either case, but what you are saying here is not such correct.. If you have any problems to use the draft-haley as a base, you can also raise the issue to the draft-haley. It is still under consensus call. Your comments aren't specific to the binding revocation, but more general problem whether the Mobility Header Signaling Message is useful or not.. regards, ryuji > >> >> Hesham >> >>>>> >>>>> 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 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 01 06:40: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 1Hu4XG-0002jc-Jo; Fri, 01 Jun 2007 06:39:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu4XE-0002jF-Rw for mip6@ietf.org; Fri, 01 Jun 2007 06:39:08 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu4XD-0001ki-QC for mip6@ietf.org; Fri, 01 Jun 2007 06:39:08 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 495A421371 for ; Fri, 1 Jun 2007 12:39:07 +0200 (CEST) X-AuditID: c1b4fb3e-b01efbb0000061ca-07-465ff74bc1b5 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 202CF21263 for ; Fri, 1 Jun 2007 12:39:07 +0200 (CEST) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 12:39:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Jun 2007 12:39:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: question on DS-MIPv6 security Thread-Index: AcekORQS3FnWSBDKSwKA12zKkyDn+g== From: "Karen E. Nielsen (AH/LMD)" To: X-OriginalArrivalTime: 01 Jun 2007 10:39:06.0942 (UTC) FILETIME=[149F3DE0:01C7A439] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e Subject: [Mip6] question on DS-MIPv6 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: , Content-Type: multipart/mixed; boundary="===============0516863991==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0516863991== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A439.149A4DB6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A439.149A4DB6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A couple of questions to the security model of DS-MIPv6. The option for BU protection described below in option 2 in a mail cut from the archives seems to say UDP ESP tunnel encapsulation (RFC 3948). Is that correctly understood and if yes then why would you need a specific port for this usage in DS-MIPv6 ? ******snip***** To: "Basavaraj Patil" , "ext Tsirtsis, George" , "Sri Gundavelli" , "Hesham Soliman" , , =20 Subject: RE: [Mip6] The use of GRE=20 From: "Vijay Devarapalli" =20 Date: Wed, 16 May 2007 14:33:59 -0700=20 Cc:=20 List-help: =20 List-id: mip6.ietf.org=20 List-post: =20 List-subscribe: , =20 List-unsubscribe: , =20 References: =20 Thread-index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAAa6kGYQAInDPQ=20 Thread-topic: [Mip6] The use of GRE=20 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 ********************* On the other hand, this option is not described in the DS-MIP draft which only seems to reference the destination option/routing header versions of the BU and not the optional tunneling version from RFC 4877. I find it a little confusing that optional ways to transmit BU's are described on the list and not in the draft - ? =20 Secondly, looking into the destination option/routing header versions of the BU as described in Section 4.1 of DS-MIP, then these are described without security headers, although they in Section 5 of DS-MIP are said to be protected using IPSec (as in standard [MIP] modulo RFC 4285). In this respect, I am rather concerned with the processing of the stack: IPv4 header (src=3DV4ADDR, dst=3DHA_V4ADDR)=20 UDP header=20 IPv6 header (src=3DV4CoA, dst=3DHAADDR)=20 DST-OPT HAO (IPv6 home address)=20 ESP (transport) Mobility header BU [IPv4 HAO]=20 as the appearance of ESP after a transport header will require a not very nice processing flow in the stack, unless IPSec is made to understand "IP" headers of form IP-UDP-IP - Has this been discussed or is it not perceived as a problem by other implementators ? I have to admit that I have been away from this list in a very long time, and yes, I haven't=20 checked the archives all that way back, but I hope you can, at least,=20 let me know whether this has been thought through,=20 and I just haven't grasped the=20 details yet, or whether these details are still being finalized. Thanks, Karen ------_=_NextPart_001_01C7A439.149A4DB6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable question on DS-MIPv6 security

Hi,

A couple of questions to the security = model of DS-MIPv6.

The option for BU protection described = below in option 2 in a mail cut from the archives
seems to say UDP ESP tunnel = encapsulation (RFC 3948). Is that correctly understood and if yes
then why would you need a specific = port for this usage in DS-MIPv6 ?

******snip*****
To: "Basavaraj Patil" = <basavaraj.patil at nsn.com>, "ext Tsirtsis, George" = <tsirtsis at qualcomm.com>, "Sri Gundavelli" = <sgundave at cisco.com>, "Hesham Soliman" <Hesham at = elevatemobile.com>, <mip6 at ietf.org>, <nemo at = ietf.org>

Subject: RE: [Mip6] The use of GRE =
From: "Vijay Devarapalli" = <Vijay.Devarapalli at AzaireNet.com>
Date: Wed, 16 May 2007 14:33:59 -0700 =
Cc:
List-help: <mailto:mip6-request@ietf.org?subject=3Dhelp= >
List-id: mip6.ietf.org
List-post: <mailto:mip6@ietf.org>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/mip6= >, <mailto:mip6-request@ietf.org?subject=3Dsubscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6= >, <mailto:mip6-request@ietf.org?subject=3Dunsubscribe<= /U>>
References: = <C270A4D3.370F7%basavaraj.patil@nsn.com>
Thread-index: = AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAAa6kGYQAInDPQ
Thread-topic: [Mip6] The use of GRE =

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=3DMN-IPv4-CoA, dst=3DHA-IPv4)
     UDP = hdr
     ESP = hdr
     IPv6 = (src=3DMN-IPv6-HoA, dst=3DCN)
     Payload =
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
*********************

On the other hand, this option is not = described in the DS-MIP draft which only seems to reference the = destination option/routing header versions

of the BU and not the optional = tunneling version from RFC 4877. I find it a little confusing that = optional ways to transmit BU's are described on the list

and not in the draft - ?
 
Secondly, looking into the destination = option/routing header versions of the BU as described in Section 4.1 of = DS-MIP, then these are described without security

headers, although they in Section 5 of = DS-MIP are said to be protected using IPSec (as in standard [MIP] modulo = RFC 4285). In this respect,

I am rather concerned with the = processing of the stack:
IPv4 header (src=3DV4ADDR, = dst=3DHA_V4ADDR)
UDP header
IPv6 header (src=3DV4CoA, = dst=3DHAADDR)
DST-OPT HAO (IPv6 home address) =
ESP (transport)
Mobility header BU [IPv4 HAO]

as the appearance of ESP after a = transport header will require a not very nice processing flow in the = stack, unless IPSec is made to understand

"IP" headers of form = IP-UDP-IP - Has this been discussed or is it not perceived as a problem = by other implementators ?

I have to admit that I have been away = from this list in a very long time,  and yes, I haven't
checked the archives all that way = back, but I hope you can, at least,
let me know whether this has been = thought through,
and I just haven't grasped the
details yet, or whether these details = are still being finalized.

Thanks,
Karen


------_=_NextPart_001_01C7A439.149A4DB6-- --===============0516863991== 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 --===============0516863991==-- From mip6-bounces@ietf.org Fri Jun 01 07:40: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 1Hu5Ti-0001SY-9Z; Fri, 01 Jun 2007 07:39:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu5Tg-0001NF-Ph for mip6@ietf.org; Fri, 01 Jun 2007 07:39:32 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu5Tg-0003ti-9k for mip6@ietf.org; Fri, 01 Jun 2007 07:39:32 -0400 Received: from oaamta04sl.mx.bigpond.com ([124.191.178.123]) by omta04sl.mx.bigpond.com with ESMTP id <20070601113929.LODN28583.omta04sl.mx.bigpond.com@oaamta04sl.mx.bigpond.com>; Fri, 1 Jun 2007 11:39:29 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta04sl.mx.bigpond.com with ESMTP id <20070601113928.WLFL1743.oaamta04sl.mx.bigpond.com@PC20005>; Fri, 1 Jun 2007 11:39:28 +0000 From: "Hesham Soliman" To: "'Karen E. Nielsen \(AH/LMD\)'" , Date: Fri, 1 Jun 2007 21:39:23 +1000 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcekORQS3FnWSBDKSwKA12zKkyDn+gAB9i0w Subject: RE: [Mip6] question on DS-MIPv6 security Message-Id: <20070601113928.WLFL1743.oaamta04sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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="===============0272191581==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0272191581== Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C7A495.522C3620" This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C7A495.522C3620 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Karen, Please ignore option 2 below, we're not doing this in the draft. This was part of a concensus call and we're leaving the draft as is today as a result of this call. Secondly, looking into the destination option/routing header versions of the BU as described in Section 4.1 of DS-MIP, then these are described without security headers, although they in Section 5 of DS-MIP are said to be protected using IPSec (as in standard [MIP] modulo RFC 4285). In this respect, I am rather concerned with the processing of the stack: IPv4 header (src=V4ADDR, dst=HA_V4ADDR) UDP header IPv6 header (src=V4CoA, dst=HAADDR) DST-OPT HAO (IPv6 home address) ESP (transport) Mobility header BU [IPv4 HAO] as the appearance of ESP after a transport header will require a not very nice processing flow in the stack, unless IPSec is made to understand "IP" headers of form IP-UDP-IP - Has this been discussed or is it not perceived as a problem by other implementators ? => I'm not sure I understand the problem you're seeing above. By the time IPsec gets this packet there would not be IPv4/UDP headers and it would look like a normal IPsec protected IPv6 packet. Hesham ------=_NextPart_000_002E_01C7A495.522C3620 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable question on DS-MIPv6 security
Karen,
 
Please ignore option 2 below, we're not doing = this in the=20 draft. This was part of a concensus call and we're leaving the draft as = is today=20 as a result of this call.

Secondly, looking into the destination=20 option/routing header versions of the BU as described in Section 4.1 = of=20 DS-MIP, then these are described without security

headers, although they in Section 5 of = DS-MIP are=20 said to be protected using IPSec (as in standard [MIP] modulo RFC = 4285). In=20 this respect,

I am rather concerned with the = processing of the=20 stack:
IPv4 header = (src=3DV4ADDR,=20 dst=3DHA_V4ADDR)
UDP header=20
IPv6 header (src=3DV4CoA, = dst=3DHAADDR)=20
DST-OPT HAO (IPv6 home = address)=20
ESP (transport) =
Mobility header BU [IPv4 HAO]

as the appearance of ESP after a = transport header=20 will require a not very nice processing flow in the stack, unless = IPSec is=20 made to understand

"IP" headers of form IP-UDP-IP - Has = this been=20 discussed or is it not perceived as a problem by other implementators=20 ?  

=3D>=20 I'm not sure I understand the problem you're seeing above. By the time = IPsec=20 gets this packet there would not be IPv4/UDP headers and it would look = like a=20 normal IPsec protected IPv6 packet.

 Hesham

------=_NextPart_000_002E_01C7A495.522C3620-- --===============0272191581== 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 --===============0272191581==-- From mip6-bounces@ietf.org Fri Jun 01 08:00: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 1Hu5nR-0001I2-5D; Fri, 01 Jun 2007 07:59:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu5nP-0001Hw-CF for mip6@ietf.org; Fri, 01 Jun 2007 07:59:55 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu5nN-0000Ga-MT for mip6@ietf.org; Fri, 01 Jun 2007 07:59:55 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 27E87212DB; Fri, 1 Jun 2007 13:59:53 +0200 (CEST) X-AuditID: c1b4fb3e-b01efbb0000061ca-55-46600a39b806 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F32DC20005; Fri, 1 Jun 2007 13:59:52 +0200 (CEST) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 13:59:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] question on DS-MIPv6 security Date: Fri, 1 Jun 2007 13:59:51 +0200 Message-ID: In-Reply-To: <20070601113928.WLFL1743.oaamta04sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] question on DS-MIPv6 security Thread-Index: AcekORQS3FnWSBDKSwKA12zKkyDn+gAB9i0wAAC3CqA= References: <20070601113928.WLFL1743.oaamta04sl.mx.bigpond.com@PC20005> From: "Karen E. Nielsen (AH/LMD)" To: "Hesham Soliman" , X-OriginalArrivalTime: 01 Jun 2007 11:59:52.0744 (UTC) FILETIME=[5CF1F280:01C7A444] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 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="===============1529543077==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1529543077== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A444.5CD69FB2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A444.5CD69FB2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 The problem, I see, is the looping from higher transport layer, UDP, back to IP/IPSec processing.=20 =20 With ESP UDP encapsulation=20 the processing of the full header IP-UDP-IP-IPSEC is kept in the IP/IPSec layer. =20 BR, Karen ________________________________ From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 Sent: 1. juni 2007 13:39 To: Karen E. Nielsen (AH/LMD); mip6@ietf.org Subject: RE: [Mip6] question on DS-MIPv6 security =09 =09 Karen,=20 =20 Please ignore option 2 below, we're not doing this in the draft. This was part of a concensus call and we're leaving the draft as is today as a result of this call.=20 Secondly, looking into the destination option/routing header versions of the BU as described in Section 4.1 of DS-MIP, then these are described without security headers, although they in Section 5 of DS-MIP are said to be protected using IPSec (as in standard [MIP] modulo RFC 4285). In this respect, I am rather concerned with the processing of the stack:=20 IPv4 header (src=3DV4ADDR, dst=3DHA_V4ADDR)=20 UDP header=20 IPv6 header (src=3DV4CoA, dst=3DHAADDR)=20 DST-OPT HAO (IPv6 home address)=20 ESP (transport)=20 Mobility header BU [IPv4 HAO]=20 as the appearance of ESP after a transport header will require a not very nice processing flow in the stack, unless IPSec is made to understand "IP" headers of form IP-UDP-IP - Has this been discussed or is it not perceived as a problem by other implementators ? =20 =3D> I'm not sure I understand the problem you're seeing above. By the time IPsec gets this packet there would not be IPv4/UDP headers and it would look like a normal IPsec protected IPv6 packet.=20 Hesham ------_=_NextPart_001_01C7A444.5CD69FB2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable question on DS-MIPv6 security
Hi,
 
The=20 problem, I see,  is the looping from higher transport layer, UDP, = back to=20 IP/IPSec processing.
 
With=20 ESP UDP encapsulation
the=20 processing of the full header IP-UDP-IP-IPSEC is kept in the = IP/IPSec=20 layer.
 
BR,=20 Karen

From: Hesham Soliman=20 [mailto:Hesham@elevatemobile.com]
Sent: 1. juni 2007=20 13:39
To: Karen E. Nielsen (AH/LMD);=20 mip6@ietf.org
Subject: RE: [Mip6] question on DS-MIPv6=20 security

Karen,
 
Please ignore option 2 below, we're not doing = this in the=20 draft. This was part of a concensus call and we're leaving the draft = as is=20 today as a result of this call.

Secondly, looking into the = destination=20 option/routing header versions of the BU as described in Section 4.1 = of=20 DS-MIP, then these are described without security

headers, although they in Section 5 = of DS-MIP are=20 said to be protected using IPSec (as in standard [MIP] modulo RFC = 4285). In=20 this respect,

I am rather concerned with the = processing of the=20 stack:
IPv4 header = (src=3DV4ADDR,=20 dst=3DHA_V4ADDR)
UDP = header=20
IPv6 header (src=3DV4CoA, = dst=3DHAADDR)=20
DST-OPT HAO (IPv6 home = address)=20
ESP (transport) =
Mobility header BU [IPv4 HAO]

as the appearance of ESP after a = transport header=20 will require a not very nice processing flow in the stack, unless = IPSec is=20 made to understand

"IP" headers of form IP-UDP-IP - Has = this been=20 discussed or is it not perceived as a problem by other = implementators=20 ?  

=3D> I'm not sure I understand the problem you're seeing = above. By=20 the time IPsec gets this packet there would not be IPv4/UDP headers = and it=20 would look like a normal IPsec protected IPv6 packet. =

 Hesham

= ------_=_NextPart_001_01C7A444.5CD69FB2-- --===============1529543077== 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 --===============1529543077==-- From mip6-bounces@ietf.org Fri Jun 01 08: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 1Hu5tW-0002db-C4; Fri, 01 Jun 2007 08:06:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu5tU-0002dR-Dw for mip6@ietf.org; Fri, 01 Jun 2007 08:06:12 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu5tT-0002Ck-Ja for mip6@ietf.org; Fri, 01 Jun 2007 08:06:12 -0400 Received: from oaamta05sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070601120609.VAOF25724.omta05sl.mx.bigpond.com@oaamta05sl.mx.bigpond.com>; Fri, 1 Jun 2007 12:06:09 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta05sl.mx.bigpond.com with ESMTP id <20070601120608.LFMN7523.oaamta05sl.mx.bigpond.com@PC20005>; Fri, 1 Jun 2007 12:06:08 +0000 From: "Hesham Soliman" To: "'Karen E. Nielsen \(AH/LMD\)'" , Subject: RE: [Mip6] question on DS-MIPv6 security Date: Fri, 1 Jun 2007 22:06:03 +1000 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcekORQS3FnWSBDKSwKA12zKkyDn+gAB9i0wAAC3CqAAAFRBUA== Message-Id: <20070601120608.LFMN7523.oaamta05sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 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="===============0902843896==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0902843896== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01C7A499.0C1B8470" This is a multi-part message in MIME format. ------=_NextPart_000_003F_01C7A499.0C1B8470 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Ah, sure, that's a problem if you do implement this in user space. What can I say, let's hope NATs disappear! Not much else we can do about this. Hesham _____ From: Karen E. Nielsen (AH/LMD) [mailto:karen.e.nielsen@ericsson.com] Sent: Friday, June 01, 2007 10:00 PM To: Hesham Soliman; mip6@ietf.org Subject: RE: [Mip6] question on DS-MIPv6 security Hi, The problem, I see, is the looping from higher transport layer, UDP, back to IP/IPSec processing. With ESP UDP encapsulation the processing of the full header IP-UDP-IP-IPSEC is kept in the IP/IPSec layer. BR, Karen _____ From: Hesham Soliman [mailto:Hesham@elevatemobile.com] Sent: 1. juni 2007 13:39 To: Karen E. Nielsen (AH/LMD); mip6@ietf.org Subject: RE: [Mip6] question on DS-MIPv6 security Karen, Please ignore option 2 below, we're not doing this in the draft. This was part of a concensus call and we're leaving the draft as is today as a result of this call. Secondly, looking into the destination option/routing header versions of the BU as described in Section 4.1 of DS-MIP, then these are described without security headers, although they in Section 5 of DS-MIP are said to be protected using IPSec (as in standard [MIP] modulo RFC 4285). In this respect, I am rather concerned with the processing of the stack: IPv4 header (src=V4ADDR, dst=HA_V4ADDR) UDP header IPv6 header (src=V4CoA, dst=HAADDR) DST-OPT HAO (IPv6 home address) ESP (transport) Mobility header BU [IPv4 HAO] as the appearance of ESP after a transport header will require a not very nice processing flow in the stack, unless IPSec is made to understand "IP" headers of form IP-UDP-IP - Has this been discussed or is it not perceived as a problem by other implementators ? => I'm not sure I understand the problem you're seeing above. By the time IPsec gets this packet there would not be IPv4/UDP headers and it would look like a normal IPsec protected IPv6 packet. Hesham ------=_NextPart_000_003F_01C7A499.0C1B8470 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable question on DS-MIPv6 security
Ah, sure, that's a problem if you do implement = this in user=20 space. What can I say, let's hope NATs disappear! Not much else we can = do about=20 this.
 
Hesham

From: Karen E. Nielsen (AH/LMD)=20 [mailto:karen.e.nielsen@ericsson.com]
Sent: Friday, June = 01, 2007=20 10:00 PM
To: Hesham Soliman; = mip6@ietf.org
Subject: RE:=20 [Mip6] question on DS-MIPv6 security

Hi,
 
The=20 problem, I see,  is the looping from higher transport layer, UDP, = back to=20 IP/IPSec processing.
 
With=20 ESP UDP encapsulation
the=20 processing of the full header IP-UDP-IP-IPSEC=20 is kept in the IP/IPSec layer.
 
BR,=20 Karen

From: Hesham Soliman=20 [mailto:Hesham@elevatemobile.com]
Sent: 1. juni 2007=20 13:39
To: Karen E. Nielsen (AH/LMD);=20 mip6@ietf.org
Subject: RE: [Mip6] question on DS-MIPv6=20 security

Karen,
 
Please ignore option 2 below, we're not = doing this in=20 the draft. This was part of a concensus call and we're leaving the = draft as=20 is today as a result of this call.

Secondly, looking into the = destination=20 option/routing header versions of the BU as described in Section = 4.1 of=20 DS-MIP, then these are described without security

headers, although they in Section 5 = of DS-MIP=20 are said to be protected using IPSec (as in standard [MIP] modulo = RFC=20 4285). In this respect,

I am rather concerned with the = processing of=20 the stack:
IPv4 header=20 (src=3DV4ADDR, dst=3DHA_V4ADDR)
UDP=20 header
IPv6 header = (src=3DV4CoA,=20 dst=3DHAADDR)
DST-OPT = HAO (IPv6 home=20 address)
ESP = (transport)=20
Mobility header BU [IPv4 HAO] =

as the appearance of ESP after a = transport=20 header will require a not very nice processing flow in the stack, = unless=20 IPSec is made to understand

"IP" headers of form IP-UDP-IP - = Has this been=20 discussed or is it not perceived as a problem by other = implementators=20 ?  

=3D> I'm not sure I understand the problem you're = seeing above. By=20 the time IPsec gets this packet there would not be IPv4/UDP = headers and it=20 would look like a normal IPsec protected IPv6 packet. =

 Hesham

<= /BODY> ------=_NextPart_000_003F_01C7A499.0C1B8470-- --===============0902843896== 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 --===============0902843896==-- From mip6-bounces@ietf.org Fri Jun 01 08:36: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 1Hu6Lt-0006cW-OI; Fri, 01 Jun 2007 08:35:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu6Lr-0006FY-N5 for mip6@ietf.org; Fri, 01 Jun 2007 08:35:31 -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 1Hu6Lq-0000rr-BB for mip6@ietf.org; Fri, 01 Jun 2007 08:35:31 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1Hu6Ln-00086H-Uz; Fri, 01 Jun 2007 14:35:28 +0200 Message-ID: <46601290.40702@levkowetz.com> Date: Fri, 01 Jun 2007 14:35:28 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] question on DS-MIPv6 security References: <20070601113928.WLFL1743.oaamta04sl.mx.bigpond.com@PC20005> In-Reply-To: <20070601113928.WLFL1743.oaamta04sl.mx.bigpond.com@PC20005> X-Enigmail-Version: 0.95.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: Hesham@elevatemobile.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: cf4fa59384e76e63313391b70cd0dd25 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 2007-06-01 13:39 Hesham Soliman said the following: > Karen, > > Please ignore option 2 below, we're not doing this in the draft. This was > part of a concensus call and we're leaving the draft as is today as a result > of this call. Umm -- are you saying that there has been a consensus determination from the chairs regarding this question, or just that option 2 has been ruled out? I'd agree with the latter, but not the former... Henrik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 01 08:48: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 1Hu6XV-0005pH-KP; Fri, 01 Jun 2007 08:47:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu6XT-0005iF-GW for mip6@ietf.org; Fri, 01 Jun 2007 08:47:31 -0400 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu6XP-00039Q-2C for mip6@ietf.org; Fri, 01 Jun 2007 08:47:31 -0400 Received: from oaamta02sl.mx.bigpond.com ([124.191.178.123]) by omta02sl.mx.bigpond.com with ESMTP id <20070601124724.OFHH10557.omta02sl.mx.bigpond.com@oaamta02sl.mx.bigpond.com>; Fri, 1 Jun 2007 12:47:24 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta02sl.mx.bigpond.com with ESMTP id <20070601124723.NSUW7229.oaamta02sl.mx.bigpond.com@PC20005>; Fri, 1 Jun 2007 12:47:23 +0000 From: "Hesham Soliman" To: "'Henrik Levkowetz'" Subject: RE: [Mip6] question on DS-MIPv6 security Date: Fri, 1 Jun 2007 22:47:17 +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: <46601290.40702@levkowetz.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcekSV4AhHzzTdlZSLOeidJ6GJlVKgAAXGTA Message-Id: <20070601124723.NSUW7229.oaamta02sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 The chairs already sent the way forward on the list and I was asked to update the draft for other issues and leaving it as is for this one. So, yes a decision was publicly announced on the list a few weeks ago. Hesham > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Friday, June 01, 2007 10:35 PM > To: Hesham Soliman > Cc: mip6@ietf.org > Subject: Re: [Mip6] question on DS-MIPv6 security > > > > On 2007-06-01 13:39 Hesham Soliman said the following: > > Karen, > > > > Please ignore option 2 below, we're not doing this in the > draft. This was > > part of a concensus call and we're leaving the draft as is > today as a result > > of this call. > > Umm -- are you saying that there has been a consensus determination > from the chairs regarding this question, or just that option 2 has > been ruled out? I'd agree with the latter, but not the former... > > > Henrik > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 01 09:04: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 1Hu6mx-0004yf-5u; Fri, 01 Jun 2007 09:03:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu6mv-0004yB-I5 for mip6@ietf.org; Fri, 01 Jun 2007 09:03:29 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu6mt-0000BA-IV for mip6@ietf.org; Fri, 01 Jun 2007 09:03:29 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E724D21200; Fri, 1 Jun 2007 15:03:26 +0200 (CEST) X-AuditID: c1b4fb3e-ae1ebbb0000061ca-d9-4660191ef907 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C5BC120248; Fri, 1 Jun 2007 15:03:26 +0200 (CEST) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 15:03:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] question on DS-MIPv6 security Date: Fri, 1 Jun 2007 15:03:25 +0200 Message-ID: In-Reply-To: <20070601120608.LFMN7523.oaamta05sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] question on DS-MIPv6 security Thread-Index: AcekORQS3FnWSBDKSwKA12zKkyDn+gAB9i0wAAC3CqAAAFRBUAABy7Mg References: <20070601120608.LFMN7523.oaamta05sl.mx.bigpond.com@PC20005> From: "Karen E. Nielsen (AH/LMD)" To: "Hesham Soliman" , X-OriginalArrivalTime: 01 Jun 2007 13:03:26.0530 (UTC) FILETIME=[3E238220:01C7A44D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c 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="===============0411199723==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0411199723== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A44D.3E32F7F6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A44D.3E32F7F6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 No, to keep it in IP/IPSec kernel space I guess the options, as you have discussed on the list, is specific UDP port for IP-UDP-IP or ESP UDP encapsulation and the option 2 tunnel BU format. =20 I do not want to attempt to reopen this discussion. I have a better idea about where the spec is now. Thanks. =20 Karen =20 =20 ________________________________ From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 Sent: 1. juni 2007 14:06 To: Karen E. Nielsen (AH/LMD); mip6@ietf.org Subject: RE: [Mip6] question on DS-MIPv6 security =09 =09 Ah, sure, that's a problem if you do implement this in user space. What can I say, let's hope NATs disappear! Not much else we can do about this.=20 =20 Hesham ________________________________ From: Karen E. Nielsen (AH/LMD) [mailto:karen.e.nielsen@ericsson.com]=20 Sent: Friday, June 01, 2007 10:00 PM To: Hesham Soliman; mip6@ietf.org Subject: RE: [Mip6] question on DS-MIPv6 security =09 =09 Hi, =20 The problem, I see, is the looping from higher transport layer, UDP, back to IP/IPSec processing.=20 =20 With ESP UDP encapsulation=20 the processing of the full header IP-UDP-IP-IPSEC is kept in the IP/IPSec layer. =20 BR, Karen ________________________________ From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 Sent: 1. juni 2007 13:39 To: Karen E. Nielsen (AH/LMD); mip6@ietf.org Subject: RE: [Mip6] question on DS-MIPv6 security =09 =09 Karen,=20 =20 Please ignore option 2 below, we're not doing this in the draft. This was part of a concensus call and we're leaving the draft as is today as a result of this call.=20 Secondly, looking into the destination option/routing header versions of the BU as described in Section 4.1 of DS-MIP, then these are described without security headers, although they in Section 5 of DS-MIP are said to be protected using IPSec (as in standard [MIP] modulo RFC 4285). In this respect, I am rather concerned with the processing of the stack:=20 IPv4 header (src=3DV4ADDR, dst=3DHA_V4ADDR)=20 UDP header=20 IPv6 header (src=3DV4CoA, dst=3DHAADDR)=20 DST-OPT HAO (IPv6 home address)=20 ESP (transport)=20 Mobility header BU [IPv4 HAO]=20 as the appearance of ESP after a transport header will require a not very nice processing flow in the stack, unless IPSec is made to understand "IP" headers of form IP-UDP-IP - Has this been discussed or is it not perceived as a problem by other implementators ? =20 =3D> I'm not sure I understand the problem you're seeing above. By the time IPsec gets this packet there would not be IPv4/UDP headers and it would look like a normal IPsec protected IPv6 packet.=20 Hesham ------_=_NextPart_001_01C7A44D.3E32F7F6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable question on DS-MIPv6 security
Hi,
 
No, to=20 keep it in IP/IPSec kernel space I guess the options, as you have = discussed=20 on the list, is
specific UDP port for IP-UDP-IP or ESP UDP=20 encapsulation and the option 2 tunnel BU format.
 
I do=20 not want to attempt to reopen this discussion. I have a better idea = about where=20 the spec is now.
Thanks.
 
Karen
 
 

From: Hesham Soliman=20 [mailto:Hesham@elevatemobile.com]
Sent: 1. juni 2007=20 14:06
To: Karen E. Nielsen (AH/LMD);=20 mip6@ietf.org
Subject: RE: [Mip6] question on DS-MIPv6=20 security

Ah, sure, that's a problem if you do = implement this in=20 user space. What can I say, let's hope NATs disappear! Not much else = we can do=20 about this.
 
Hesham

From: Karen E. Nielsen (AH/LMD)=20 [mailto:karen.e.nielsen@ericsson.com]
Sent: Friday, June = 01, 2007=20 10:00 PM
To: Hesham Soliman; = mip6@ietf.org
Subject: RE:=20 [Mip6] question on DS-MIPv6 security

Hi,
 
The problem, I see,  is the looping from higher = transport layer,=20 UDP, back to IP/IPSec processing.
 
With ESP UDP encapsulation
the processing of the full header IP-UDP-IP-IPSEC is kept in the IP/IPSec = layer.
 
BR, Karen

From: Hesham Soliman=20 [mailto:Hesham@elevatemobile.com]
Sent: 1. juni 2007=20 13:39
To: Karen E. Nielsen (AH/LMD);=20 mip6@ietf.org
Subject: RE: [Mip6] question on DS-MIPv6=20 security

Karen,
 
Please ignore option 2 below, we're not = doing this in=20 the draft. This was part of a concensus call and we're leaving the = draft=20 as is today as a result of this call.

Secondly, looking into the = destination=20 option/routing header versions of the BU as described in Section = 4.1 of=20 DS-MIP, then these are described without security

headers, although they in Section = 5 of DS-MIP=20 are said to be protected using IPSec (as in standard [MIP] = modulo RFC=20 4285). In this respect,

I am rather concerned with the = processing of=20 the stack:
IPv4 header = (src=3DV4ADDR, dst=3DHA_V4ADDR)
UDP=20 header
IPv6 header = (src=3DV4CoA,=20 dst=3DHAADDR)
DST-OPT = HAO (IPv6=20 home address)
ESP=20 (transport)
Mobility = header BU=20 [IPv4 HAO]

as the appearance of ESP after a = transport=20 header will require a not very nice processing flow in the = stack, unless=20 IPSec is made to understand

"IP" headers of form IP-UDP-IP - = Has this=20 been discussed or is it not perceived as a problem by other=20 implementators ?  

=3D> I'm not sure I understand the problem you're = seeing above.=20 By the time IPsec gets this packet there would not be IPv4/UDP = headers=20 and it would look like a normal IPsec protected IPv6 packet.=20

 Hesham

<= /BLOCKQUOTE> ------_=_NextPart_001_01C7A44D.3E32F7F6-- --===============0411199723== 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 --===============0411199723==-- From mip6-bounces@ietf.org Fri Jun 01 13:24: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 1HuAqb-0001dv-WA; Fri, 01 Jun 2007 13:23:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuAqb-0001cu-Fm for mip6@ietf.org; Fri, 01 Jun 2007 13:23:33 -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 1HuAqa-0000OF-Dw for mip6@ietf.org; Fri, 01 Jun 2007 13:23:33 -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 l51HMxqO011030; Fri, 1 Jun 2007 20:23:20 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 20:23:18 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 12:23:15 -0500 Received: from 10.241.58.164 ([10.241.58.164]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Jun 2007 17:23:15 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 01 Jun 2007 12:23:17 -0500 Subject: Re: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt From: Basavaraj Patil To: ext Ahmad Muhanna , Hesham Soliman , Brian Haley Message-ID: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcejsVbfS40lMgyLQl23peLZkTLpugAFaWnwAAugWzAAAgC4oAAEMlsgAADb+qAAF/QpWg== In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437114A14F21@zrc2hxm2.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Jun 2007 17:23:15.0921 (UTC) FILETIME=[8A23CC10:01C7A471] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d 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 et al, Let me try and summarize this discussion: Basically you are arguing that binding revocation is a control message which does not really fit in with the generic mh-signaling message being defined by draft-haley. And the reasoning (IMO) that you seem to have is that the generic-mh-header signaling scheme is intended for informational updates only. You have also stated that the generic mh-signaling scheme limits flexibility. As to what flexibility is required for binding revocation, it has not been clearly spelled out. I think other claims about processing efficiency etc. to me seem like hand-waving. Binding revocation in general would not be frequently used in a deployment. So trying to optimize it is not a strong requirement. As Hesham and Ryuji have said, there is no reason why you cannot accomplish binding revocation using the generic-mh-signaling message defined in draft-haley. You can solve the binding revocation problem either by defining new messages as you are currently doing and stating that this is the only method that makes the most sense or by notifying the MS about the binding being revoked via a standardized option (IANA assigned) in the generic MN-header signaling message. Both of them will work. I don't think there is any disagreement about the solution. Reuse of a signaling message would be a good approach. If you were to specify binding revocation using the generic-mh-signaling message and the behavior of the host and the HA in a separate draft, I think it would solve the problem just as well. I hope you will consider this option as well. -Raj On 6/1/07 1:58 AM, "ext Ahmad Muhanna" wrote: > Hi Hesham, > Please see comments inline. > > Regards, > Ahmad > > >>> >>> [Ahmad] >>> >>> Let me clarify one thing here. draft-hanley defines a >> messaging > container mechanism via generic notification messages. >>> According to that >>> draft and its scope, the details of a functionality like >> revocation, > which possibly can be carried inside the >> generic > notification messages, > is to be defined in a >> different draft anyway. In other > words, even if we > >> agree to define a subtype for revocation messages in the >> generic > notification messages, (as you just suggested) the >> details of the > revocation mechanism needs to be captured >> in a different > draft anyway. I > just would like to point >> that out and put it behind us. >> >> => Yes that's true of course. > > [Ahmad] > That is good. >> >>> >>> On the other hand, I actually expressed before, that >> anything is > possible and we can make anything to work. The >> question is, > what is the > best most flexible and >> efficient way for achieving the same > outcome. >> >> => Ok, so what is that most flexible way? > > [Ahmad] > Please see my comments below. Just to address the whole thing in one > place. >> >> >>> >>> Snip >>> ++++++++++++++++++++ >>> 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. >>> +++++++++++++++++++++ >>> snip >>> >>> I, personally, believe that defining separate MH types for >> revocation > messages (option 1) is more flexible and >> efficient than defining the > same messages within the >> generic notification messages. It is more > relevant since >> it is a control message similar to BU/BA. >> >> => Ok, it's clear that this is your belief. What's not clear >> is why you think it's efficient and flexible. This is a one >> message that is not sent frequently to the MN, so what >> efficiency metrics do you use to come to this conclusion? I >> think it's a waste (albeit not so significant of course) to >> define a new MH type just for this message. > > [Ahmad] > Again, Please see the comments below. >> >> I really don't care which way this goes because both will >> work with little differences. I'm trying to understand why >> we're talking so much about this and what the differences >> are, if any. I don't really see much difference. >> >>>>> >>>>> 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? >> >> => Other than wasting a new MH type, I see zero practical >> differences. > > [Ahmad] > Since most of your questions are, basically, related to efficiency, I > would like to address everything in one place. > If the whole concept behind the generic notification message is to AVOID > and SAVE a new MH type and basically mask all future IPv6 mobility > control related messages, then I believe that the proposed mechanism as > per draft-haley is inefficient and all what we need is the following: > > 1. In order to enable the generic notification mechanism, we need to > define/reserve a specific MH Type (TBD=Generic Mobility Header) which > identifies the presence of a two bytes (Generic Mobility Header, GMH) at > the end of the Mobility header which, if included ALONE makes the > mobility header length equal to ZERO. > > 2. These two bytes (GMH) are used to define a 64k subtypes for the > Generic Mobility Header. > 3. Each subtype define a single message, for example, 01: Binding > Revocation Indication, 02: Binding Revocation Acknowledgement, 03: etc. > 4. Separate drafts, like Binding Revocation for IPv6 Mobility, for > example, defines the messages format and describe in details the > revocation mechanism. > > Now, why I think this or a separate messages is more efficient than what > is already defined and proposed in draft-haley? > > 1. Since the whole objective here is to save MH type, we eliminate the > need for defining two messages, generic notification message and generic > notification acknowledgement. > > 2. We eliminated the use of the generic notification sequence number > which may be limited in here. As a matter of fact, why do we need that > if the new functionality is going to define all the needed formats and > details. > > 3. We define the details of the revocation mechanism, for example, > independently without any possible conflict with the generic message A > bit, for example. In other words, the A bit is defined where it is > mattered most, i.e. in the Binding Revocation Indication message, rather > than in the masking container structure. Moreover, all needed bits will > be defined and processed in one place rather defining the > Acknowledgement bit in the container header, while figuring out the > Global bit inside the Binding Revocation Indication message, just as an > example. > > 4. Provide the flexibility to define any other messaging protocol > without being restricted with the rules of the generic notification > messages mechanism and whatever limitations it may have. > > 5. If this messaging mechanism is really generic in the full sense, how > anyone expect that one byte of status is enough to address all possible > status for all the possible functionalities that could ever be > masked/encapsulated using this generic messaging mechanism. In other > words, I believe that the status should be moved from the Generic > notification message header to the specific message, where it is more > relevant. For example, what the following status has to do with > revocation mechanism, for example: "130 Insufficient resources". I > thought we are trying to FREE resources here! > > 6. Why do we have to define retransmission for this generic notification > messaging mechanism. Is not this supposed to be generic enough to fit > the need of any functionality that we may think of. Is not there is a > possibility that we define a functionality that depends on best effort > that does not require retransmission. > > 7. Finally, how do we expect to have this mechanism generically sound > and at the same time we define limitation that may or may not work for > all generic functionalities that could be masked/encapsulated inside > such container, for example, why do you think that the following > timeouts is applicable to all functionalities. I believe that these > numbers need to be defined specifically by each functionality. > > INITIAL_MH_SIGNAL_TIMEOUT 5 seconds > MAX_MH_SIGNAL_TIMEOUT 20 seconds > > 8. I hope that you would agree that using the generic notification > messages mechanism as per the current proposed mechanism in draft-haley > is not the most efficient mechanism to protect and save MH types and at > the same time offer a generic enough mechanism to contain almost any > possible generically sound functionality. > > 9. Finally, if we are concerned to preserve what left of the MH types, I > believe the above proposed Generic Mobility Header is the best way to go > forward. "2 bytes of 64k subtypes" that simple. > > >> >> Hesham >> >>>>> >>>>> 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 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 01 14:12: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 1HuBcC-0001Z8-OE; Fri, 01 Jun 2007 14:12:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuBcB-0001Xo-Hy for mip6@ietf.org; Fri, 01 Jun 2007 14:12:43 -0400 Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuBcA-00072t-8V for mip6@ietf.org; Fri, 01 Jun 2007 14:12:43 -0400 Received: from smtp2.fc.hp.com (smtp.fc.hp.com [15.11.136.114]) by atlrel6.hp.com (Postfix) with ESMTP id 7D3C836AC1; Fri, 1 Jun 2007 14:12:41 -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 BAA6C18975C; Fri, 1 Jun 2007 18:12:40 +0000 (UTC) Message-ID: <46606198.8040408@hp.com> Date: Fri, 01 Jun 2007 14:12:40 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.10 (X11/20070403) MIME-Version: 1.0 To: RYUJI WAKIKAWA Subject: Re: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt References: <6FC4416DDE56C44DA0AEE67BC7CA437114A14EC7@zrc2hxm2.corp.nortel.com> <20070601054133.HXNH7523.oaamta05sl.mx.bigpond.com@PC20005> <6FC4416DDE56C44DA0AEE67BC7CA437114A14F21@zrc2hxm2.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 RYUJI WAKIKAWA wrote: >> 9. Finally, if we are concerned to preserve what left of the MH types, I >> believe the above proposed Generic Mobility Header is the best way to go >> forward. "2 bytes of 64k subtypes" that simple. > > Finally, I feel the same with Hesham. > I am fine either case, but what you are saying here is not such correct.. > > If you have any problems to use the draft-haley as a base, > you can also raise the issue to the draft-haley. > It is still under consensus call. Your comments aren't specific to the > binding revocation, > but more general problem whether the Mobility Header Signaling Message > is useful or not.. Yes, if there are things in draft-haley that need to be resolved/fixed/etc so it can be better used for signaling, please send them to the list or to me, I'll be happy to update it. Irregardless of the outcome of this discussion... -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 01 14:18: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 1HuBhH-0001Go-AF; Fri, 01 Jun 2007 14:17:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuBhG-0001Gj-EQ for mip6@ietf.org; Fri, 01 Jun 2007 14:17:58 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuBhF-0007ih-6R for mip6@ietf.org; Fri, 01 Jun 2007 14:17:58 -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 l51IGkJ20990; Fri, 1 Jun 2007 18:16:46 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: Fri, 1 Jun 2007 13:17:48 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114A7252C@zrc2hxm2.corp.nortel.com> In-Reply-To: <46606198.8040408@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: AcekeHRasxhgK8OaR/iMnUgc4Ci7qAAAAc9w References: <6FC4416DDE56C44DA0AEE67BC7CA437114A14EC7@zrc2hxm2.corp.nortel.com> <20070601054133.HXNH7523.oaamta05sl.mx.bigpond.com@PC20005> <6FC4416DDE56C44DA0AEE67BC7CA437114A14F21@zrc2hxm2.corp.nortel.com> <46606198.8040408@hp.com> From: "Ahmad Muhanna" To: "Brian Haley" , "RYUJI WAKIKAWA" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 Thanks Brian, I will provide the suggested change when the discussion is concluded. One point, as per the discussion on this thread, I tried to avoid giving opinion about the generic container mechanism introduce in the draft-haley. However, when I was asked to justify the deficiency claim, I had to highlight what I think is causing some deficiency and limitation. Regards, Ahmad =20 > -----Original Message----- > From: Brian Haley [mailto:brian.haley@hp.com]=20 > Sent: Friday, June 01, 2007 1:13 PM > To: RYUJI WAKIKAWA > Cc: Muhanna, Ahmad (RICH1:2H10); Hesham Soliman; mip6@ietf.org > Subject: Re: [Mip6] FW: I-D=20 > ACTION:draft-muhanna-mip6-binding-revocation-00.txt >=20 > RYUJI WAKIKAWA wrote: > >> 9. Finally, if we are concerned to preserve what left of the MH=20 > >> types, I believe the above proposed Generic Mobility Header is the=20 > >> best way to go forward. "2 bytes of 64k subtypes" that simple. > >=20 > > Finally, I feel the same with Hesham. > > I am fine either case, but what you are saying here is not=20 > such correct.. > >=20 > > If you have any problems to use the draft-haley as a base, you can=20 > > also raise the issue to the draft-haley. > > It is still under consensus call. Your comments aren't=20 > specific to the=20 > > binding revocation, but more general problem whether the Mobility=20 > > Header Signaling Message is useful or not.. >=20 > Yes, if there are things in draft-haley that need to be=20 > resolved/fixed/etc so it can be better used for signaling,=20 > please send them to the list or to me, I'll be happy to=20 > update it. Irregardless of the outcome of this discussion... >=20 > -Brian >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 01 14:38: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 1HuC1M-0000dg-Sj; Fri, 01 Jun 2007 14:38:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuC1K-0000b4-Eh for mip6@ietf.org; Fri, 01 Jun 2007 14:38:42 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuC1J-0001UF-Lf for mip6@ietf.org; Fri, 01 Jun 2007 14:38:42 -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 l51IccZ16768; Fri, 1 Jun 2007 18:38:39 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: Fri, 1 Jun 2007 13:38:34 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114A725CF@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: AcejsVbfS40lMgyLQl23peLZkTLpugAFaWnwAAugWzAAAgC4oAAEMlsgAADb+qAAF/QpWgAA+4Ew References: <6FC4416DDE56C44DA0AEE67BC7CA437114A14F21@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Basavaraj Patil" , "Hesham Soliman" , "Brian Haley" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10e6cb90de4fe268e7150fb24857273b 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, As I said before, I am not against using a generic container mechanism in order to mask/carry the Binding revocation messages. However, In my answer to Hesham below, I identified several deficiency issues with the current proposed generic container mechanism. Let me make on point clear before moving forward, according to the discussion you referred to with Hesham and Ryuji, the main concern was that the MH types are running out quickly and a generic container mechanism is very useful to have some protection. Having said that, I would like to summarize some of the discussion with Hesham and Ryuji below. Also, I would propose an optimization to the generic container mechanism which I already shared with Ryuji in a separate thread as a reply to the wg consensus call. Here is a summary: Concern No. 1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> =3D> Other than wasting a new MH type, I see zero practical differences. >> Since the whole objective here is to save MH type, we eliminate the=20 >> need for defining two messages, generic notification message and=20 >> generic notification acknowledgement. > Isn't this such big issue?! [Ahmad] Agreement on preserving the remaining MH types. As per the generic notification mechanism in draft-haley, the proposed modified container mechanism will preserve this as well. Concern No. 2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Anyway, if you have a new MH, you should consider the IPsec setting=20 > up. > The MH type is now a selector in IPsec, you need additional SAD/SPD=20 > for the new revocation message?! [Ahmad] If we use the generic container mechanism with the proposed modification, then we are all happy and on the same page. Concern No. 3: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 2. We eliminated the use of the generic notification sequence number > > which may be limited in here. As a matter of fact, why do we need that > > if the new functionality is going to define all the needed formats and > > details. >=20 > You can always overwrite the draft-haley in your document. [Ahmad] Well, my understanding is that we will end up with two sequence number fields, one in the generic notification message and another in the revocation message. Is not that right? If so, why do we need to have two? Concern No. 4: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> If this messaging mechanism is really generic in the full sense,=20 >> how anyone expect that one byte of status is enough to address all=20 >> possible status for all the possible functionalities that could ever=20 >> be masked/encapsulated using this generic messaging mechanism. In=20 >> other words, I believe that the status should be moved from the=20 >> Generic notification message header to the specific message, where it >> is more relevant. For example, what the following status has to do=20 >> with revocation mechanism, for example: "130 Insufficient resources". >> I thought we are trying to FREE resources here! > >=20 > Can you define your status field in your options?? [Ahmad] Again, same as concern No.3.=20 Why do we need to end up handling two different status field for addressing the same status?. Concern No. 5: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> We define the details of the revocation mechanism, for example,=20 >> independently without any possible conflict with the generic message A=20 >> bit, for example. In other words, the A bit is defined where it is=20 >> mattered most, i.e. in the Binding Revocation Indication message,=20 >> rather than in the masking container structure. Moreover, all needed=20 >> bits will be defined and processed in one place rather defining the=20 >> Acknowledgement bit in the container header, while figuring out the=20 >> Global bit inside the Binding Revocation Indication message, just as=20 >> an example. Concern No. 6: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Why do we have to define retransmission for this generic=20 >> notification messaging mechanism. Is not this supposed to be generic=20 >> enough to fit the need of any functionality that we may think of. Is=20 >> not there is a possibility that we define a functionality that depends=20 >> on best effort that does not require retransmission. > Retransmission is required, because MH does not provide reliable=20 > transmission. > If you don't want retransmission, you just override that spec. in your > document... > The haley's draft defines a generic MH message, you can always=20 > overwrite it as you want. > Otherwise, nobody can use draft-haley... [Ahmad] Agree. I assumed here that the functionality embedded requires best effort. However, if we allow each functionality the option to overwrite the generic mechanism numbers, why do we need these numbers to start with. If that concept is generic enough, then I assume we have two options: 1. These numbers are very generic that are applicable to all functionalities, OR,=20 2. Do not define them to start with. IMO, all what we need is a container rather than another level of embedded messaging. Right? Concern No. 7: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Finally, how do we expect to have this mechanism generically sound=20 >> and at the same time we define limitation that may or may not work for=20 >> all generic functionalities that could be masked/encapsulated inside=20 >> such container, for example, why do you think that the following=20 >> timeouts is applicable to all functionalities. I believe that these=20 >> numbers need to be defined specifically by each functionality. >> >> INITIAL_MH_SIGNAL_TIMEOUT 5 seconds >> MAX_MH_SIGNAL_TIMEOUT 20 seconds > > please overwrite it... > RFC3775 also overrides the constant value of RFC2461. [Ahmad] Same as concern No. 6. Regards, Ahmad =20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Friday, June 01, 2007 12:23 PM > To: Muhanna, Ahmad (RICH1:2H10); Hesham Soliman; Brian Haley > Cc: mip6@ietf.org > Subject: Re: [Mip6] FW: I-D=20 > ACTION:draft-muhanna-mip6-binding-revocation-00.txt >=20 >=20 > Ahmad et al, >=20 > Let me try and summarize this discussion: >=20 > Basically you are arguing that binding revocation is a=20 > control message which does not really fit in with the generic=20 > mh-signaling message being defined by draft-haley. And the=20 > reasoning (IMO) that you seem to have is that the=20 > generic-mh-header signaling scheme is intended for=20 > informational updates only. You have also stated that the=20 > generic mh-signaling scheme limits flexibility. As to what=20 > flexibility is required for binding revocation, it has not=20 > been clearly spelled out. I think other claims about=20 > processing efficiency etc. to me seem like hand-waving. >=20 > Binding revocation in general would not be frequently used in=20 > a deployment. > So trying to optimize it is not a strong requirement. >=20 > As Hesham and Ryuji have said, there is no reason why you=20 > cannot accomplish binding revocation using the=20 > generic-mh-signaling message defined in draft-haley. > You can solve the binding revocation problem either by=20 > defining new messages as you are currently doing and stating=20 > that this is the only method that makes the most sense or by=20 > notifying the MS about the binding being revoked via a=20 > standardized option (IANA assigned) in the generic MN-header=20 > signaling message. Both of them will work. I don't think=20 > there is any disagreement about the solution. >=20 > Reuse of a signaling message would be a good approach. >=20 > If you were to specify binding revocation using the=20 > generic-mh-signaling message and the behavior of the host and=20 > the HA in a separate draft, I think it would solve the=20 > problem just as well. I hope you will consider this option as well. >=20 > -Raj=20 >=20 >=20 > On 6/1/07 1:58 AM, "ext Ahmad Muhanna" wrote: >=20 > > Hi Hesham, > > Please see comments inline. > >=20 > > Regards, > > Ahmad > > =20 > >=20 > >>>=20 > >>> [Ahmad] > >>>=20 > >>> Let me clarify one thing here. draft-hanley defines a > >> messaging > container mechanism via generic notification messages. > >>> According to that > >>> draft and its scope, the details of a functionality like > >> revocation, > which possibly can be carried inside the generic >=20 > >> notification messages, > is to be defined in a different draft=20 > >> anyway. In other > words, even if we > agree to define a subtype=20 > >> for revocation messages in the generic > notification=20 > messages, (as=20 > >> you just suggested) the details of the > revocation=20 > mechanism needs=20 > >> to be captured in a different > draft anyway. I > just=20 > would like=20 > >> to point that out and put it behind us. > >>=20 > >> =3D> Yes that's true of course. > >=20 > > [Ahmad] > > That is good. > >>=20 > >>>=20 > >>> On the other hand, I actually expressed before, that > >> anything is > possible and we can make anything to work. The=20 > >> question is, > what is the > best most flexible and=20 > efficient way=20 > >> for achieving the same > outcome. > >>=20 > >> =3D> Ok, so what is that most flexible way? > >=20 > > [Ahmad] > > Please see my comments below. Just to address the whole=20 > thing in one=20 > > place. > >>=20 > >>=20 > >>>=20 > >>> Snip > >>> ++++++++++++++++++++ > >>> 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=20 > >> IPv6 Mobility draft. > >>>=20 > >>> -OR- > >>>=20 > >>> Option 2: > >>> Since the MH generic message type allows only for options > >> to > be defined > (in separate drafts) and including all the=20 > >> revocation related > information would not be possible in=20 > a single=20 > >> option (unless > it becomes > a message), then a subtype (as the=20 > >> first byte after the MH) > can be used > to define the type of=20 > >> message that is included in the generic > >>> notification message. > >>> +++++++++++++++++++++ > >>> snip > >>>=20 > >>> I, personally, believe that defining separate MH types for > >> revocation > messages (option 1) is more flexible and=20 > efficient than=20 > >> defining the > same messages within the generic notification=20 > >> messages. It is more > relevant since it is a control message=20 > >> similar to BU/BA. > >>=20 > >> =3D> Ok, it's clear that this is your belief. What's not=20 > clear is why=20 > >> you think it's efficient and flexible. This is a one=20 > message that is=20 > >> not sent frequently to the MN, so what efficiency metrics=20 > do you use=20 > >> to come to this conclusion? I think it's a waste (albeit not so=20 > >> significant of course) to define a new MH type just for=20 > this message. > >=20 > > [Ahmad] > > Again, Please see the comments below. > >>=20 > >> I really don't care which way this goes because both will=20 > work with=20 > >> little differences. I'm trying to understand why we're talking so=20 > >> much about this and what the differences are, if any. I=20 > don't really=20 > >> see much difference. > >>=20 > >>>>>=20 > >>>>> One last thing, Do you see a problem by using a > >> separate > > MH types for > revocation messages to define one=20 > >> revocation > > > mechanism/messages which is >=20 > applicable to MIPv6=20 > >> and PMIPv6? > >>=20 > >> =3D> Other than wasting a new MH type, I see zero practical=20 > >> differences. > >=20 > > [Ahmad] > > Since most of your questions are, basically, related to=20 > efficiency, I=20 > > would like to address everything in one place. > > If the whole concept behind the generic notification message is to=20 > > AVOID and SAVE a new MH type and basically mask all future IPv6=20 > > mobility control related messages, then I believe that the proposed=20 > > mechanism as per draft-haley is inefficient and all what we=20 > need is the following: > >=20 > > 1. In order to enable the generic notification mechanism,=20 > we need to=20 > > define/reserve a specific MH Type (TBD=3DGeneric Mobility=20 > Header) which=20 > > identifies the presence of a two bytes (Generic Mobility=20 > Header, GMH)=20 > > at the end of the Mobility header which, if included ALONE=20 > makes the=20 > > mobility header length equal to ZERO. > >=20 > > 2. These two bytes (GMH) are used to define a 64k subtypes for the=20 > > Generic Mobility Header. > > 3. Each subtype define a single message, for example, 01: Binding=20 > > Revocation Indication, 02: Binding Revocation=20 > Acknowledgement, 03: etc. > > 4. Separate drafts, like Binding Revocation for IPv6 Mobility, for=20 > > example, defines the messages format and describe in details the=20 > > revocation mechanism. > >=20 > > Now, why I think this or a separate messages is more efficient than=20 > > what is already defined and proposed in draft-haley? > >=20 > > 1. Since the whole objective here is to save MH type, we=20 > eliminate the=20 > > need for defining two messages, generic notification message and=20 > > generic notification acknowledgement. > >=20 > > 2. We eliminated the use of the generic notification=20 > sequence number=20 > > which may be limited in here. As a matter of fact, why do=20 > we need that=20 > > if the new functionality is going to define all the needed=20 > formats and=20 > > details. > >=20 > > 3. We define the details of the revocation mechanism, for example,=20 > > independently without any possible conflict with the=20 > generic message A=20 > > bit, for example. In other words, the A bit is defined where it is=20 > > mattered most, i.e. in the Binding Revocation Indication message,=20 > > rather than in the masking container structure. Moreover,=20 > all needed=20 > > bits will be defined and processed in one place rather defining the=20 > > Acknowledgement bit in the container header, while figuring out the=20 > > Global bit inside the Binding Revocation Indication=20 > message, just as=20 > > an example. > >=20 > > 4. Provide the flexibility to define any other messaging protocol=20 > > without being restricted with the rules of the generic notification=20 > > messages mechanism and whatever limitations it may have. > >=20 > > 5. If this messaging mechanism is really generic in the full sense,=20 > > how anyone expect that one byte of status is enough to address all=20 > > possible status for all the possible functionalities that=20 > could ever=20 > > be masked/encapsulated using this generic messaging mechanism. In=20 > > other words, I believe that the status should be moved from the=20 > > Generic notification message header to the specific=20 > message, where it=20 > > is more relevant. For example, what the following status has to do=20 > > with revocation mechanism, for example: "130 Insufficient=20 > resources".=20 > > I thought we are trying to FREE resources here! > >=20 > > 6. Why do we have to define retransmission for this generic=20 > > notification messaging mechanism. Is not this supposed to=20 > be generic=20 > > enough to fit the need of any functionality that we may=20 > think of. Is=20 > > not there is a possibility that we define a functionality=20 > that depends=20 > > on best effort that does not require retransmission. > >=20 > > 7. Finally, how do we expect to have this mechanism=20 > generically sound=20 > > and at the same time we define limitation that may or may=20 > not work for=20 > > all generic functionalities that could be=20 > masked/encapsulated inside=20 > > such container, for example, why do you think that the following=20 > > timeouts is applicable to all functionalities. I believe that these=20 > > numbers need to be defined specifically by each functionality. > >=20 > > INITIAL_MH_SIGNAL_TIMEOUT 5 seconds > > MAX_MH_SIGNAL_TIMEOUT 20 seconds > >=20 > > 8. I hope that you would agree that using the generic notification=20 > > messages mechanism as per the current proposed mechanism in=20 > > draft-haley is not the most efficient mechanism to protect=20 > and save MH=20 > > types and at the same time offer a generic enough mechanism=20 > to contain=20 > > almost any possible generically sound functionality. > >=20 > > 9. Finally, if we are concerned to preserve what left of=20 > the MH types,=20 > > I believe the above proposed Generic Mobility Header is the=20 > best way=20 > > to go forward. "2 bytes of 64k subtypes" that simple. > >=20 > >=20 > >>=20 > >> Hesham > >>=20 > >>>>>=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=20 > maybe that =20 > >> > > set a > > precedence to do > > >> this separately? > >>>>>>>=20 > >>>>>>> [Ahmad] > >>>>>>> I agree.=20 > >>>>>>>=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: > >>>>>>>=20 > >>>>>>> Option 1: > >>>>>>> Is to have the revocation messages stands out as > >> a > > > separate MH type > > > messages. This is=20 > similar to what =20 > >> > > Mobile IPv4 has in RFC3543 and > > > detailed in the=20 > Binding >=20 > >> > Revocation for IPv6 Mobility draft. > >>>>>>>=20 > >>>>>>> -OR- > >>>>>>>=20 > >>>>>>> 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=20 > (unless it =20 > >> > > > > > becomes a message), then a subtype (as the=20 > first byte > =20 > >> > > after the MH) > > > can be used to define the type of > >=20 > >> message that is > included in the > > >>>> generic > > notification message. > >>>>>>=20 > >>>>>> I don't follow you here. Your Binding Revocation > >>>> Indication > > Message is very similar to the Signaling Request=20 > >>>> Message in > > draft-haley, having a Revoke > > > >> sub-option (with some flags) > > doesn't seem like it's that > >>>> different. > >>>>>>=20 > >>>>>> The one thing that would be different is if you're > >>>> sending > > multiple sub-options containing revocation=20 > information=20 > >>>> - they > > might be considered at different "levels" in each=20 > >>>> 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 > > with the Revocation option, they're all=20 > >> just > > options, right? > >>>>>> You'd just have to have very specific processing > >> rules > > (like > > we do for Binding Cache Information=20 > Options in=20 > >> the > > > > ha-reliability draft). I can understand=20 > this problem, =20 > >> > > since > > as you define more options it could get=20 > difficult > >=20 > >> - 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 > >>>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>=20 > >>=20 > >>=20 > >>=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 From mip6-bounces@ietf.org Fri Jun 01 15:32: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 1HuCr2-0002kh-Lf; Fri, 01 Jun 2007 15:32:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCr1-0002kc-EQ for mip6@ietf.org; Fri, 01 Jun 2007 15:32: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 1HuCr0-0008TI-01 for mip6@ietf.org; Fri, 01 Jun 2007 15:32:07 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HuCqw-0000Kz-QT; Fri, 01 Jun 2007 21:32:04 +0200 Message-ID: <46607432.9090207@levkowetz.com> Date: Fri, 01 Jun 2007 21:32:02 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] question on DS-MIPv6 security References: <20070601124723.NSUW7229.oaamta02sl.mx.bigpond.com@PC20005> In-Reply-To: <20070601124723.NSUW7229.oaamta02sl.mx.bigpond.com@PC20005> X-Enigmail-Version: 0.95.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: Hesham@elevatemobile.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: 3e15cc4fdc61d7bce84032741d11c8e5 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 Hesham, On 2007-06-01 14:47 Hesham Soliman said the following: > The chairs already sent the way forward on the list and I was asked to > update the draft for other issues and leaving it as is for this one. So, yes > a decision was publicly announced on the list a few weeks ago. Are you referring to Raj's mail of 2007-05-16, with the title "Re: [Mip6] The use of GRE" ? If so, then we have a problem here. The discussion continued after that mail; that mail was neither in title nor in the text announcing a consensus call, and if you have received instructions to update the draft based on that mail as a consensus call, I'll have to challenge those instructions. Henrik > Hesham > >> -----Original Message----- >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >> Sent: Friday, June 01, 2007 10:35 PM >> To: Hesham Soliman >> Cc: mip6@ietf.org >> Subject: Re: [Mip6] question on DS-MIPv6 security >> >> >> >> On 2007-06-01 13:39 Hesham Soliman said the following: >>> Karen, >>> >>> Please ignore option 2 below, we're not doing this in the >> draft. This was >>> part of a concensus call and we're leaving the draft as is >> today as a result >>> of this call. >> Umm -- are you saying that there has been a consensus determination >> from the chairs regarding this question, or just that option 2 has >> been ruled out? I'd agree with the latter, but not the former... >> >> >> Henrik >> >> > > > > _______________________________________________ > 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 Jun 01 15:38:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCx4-0004Nt-RZ; Fri, 01 Jun 2007 15:38:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCx3-0004Nm-OB for mip6@ietf.org; Fri, 01 Jun 2007 15:38: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 1HuCx2-0000uR-5c for mip6@ietf.org; Fri, 01 Jun 2007 15:38:21 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l51Jc1Ap008931; Fri, 1 Jun 2007 22:38:09 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 22:38:09 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 14:38:07 -0500 Received: from 10.241.58.171 ([10.241.58.171]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Jun 2007 19:38:07 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 01 Jun 2007 14:38:09 -0500 Subject: Re: [Mip6] question on DS-MIPv6 security From: Basavaraj Patil To: Levkowetz , Hesham Soliman Message-ID: Thread-Topic: [Mip6] question on DS-MIPv6 security Thread-Index: AcekhGH9oKOV3hB3Edyx6wARJNUNiA== In-Reply-To: <46607432.9090207@levkowetz.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Jun 2007 19:38:07.0094 (UTC) FILETIME=[60DAD160:01C7A484] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 Well... Maybe there was not a final summary note sent out to close that discussion. Let me send one now. -Raj On 6/1/07 2:32 PM, "ext Henrik Levkowetz" wrote: > Hi Hesham, > > On 2007-06-01 14:47 Hesham Soliman said the following: >> The chairs already sent the way forward on the list and I was asked to >> update the draft for other issues and leaving it as is for this one. So, yes >> a decision was publicly announced on the list a few weeks ago. > > Are you referring to Raj's mail of 2007-05-16, with the title > "Re: [Mip6] The use of GRE" ? > > If so, then we have a problem here. The discussion continued > after that mail; that mail was neither in title nor in the text > announcing a consensus call, and if you have received instructions > to update the draft based on that mail as a consensus call, > I'll have to challenge those instructions. > > > Henrik > > >> Hesham >> >>> -----Original Message----- >>> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >>> Sent: Friday, June 01, 2007 10:35 PM >>> To: Hesham Soliman >>> Cc: mip6@ietf.org >>> Subject: Re: [Mip6] question on DS-MIPv6 security >>> >>> >>> >>> On 2007-06-01 13:39 Hesham Soliman said the following: >>>> Karen, >>>> >>>> Please ignore option 2 below, we're not doing this in the >>> draft. This was >>>> part of a concensus call and we're leaving the draft as is >>> today as a result >>>> of this call. >>> Umm -- are you saying that there has been a consensus determination >>> from the chairs regarding this question, or just that option 2 has >>> been ruled out? I'd agree with the latter, but not the former... >>> >>> >>> Henrik >>> >>> >> >> >> >> _______________________________________________ >> 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 Jun 01 15: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 1HuD5R-0000Ib-34; Fri, 01 Jun 2007 15:47:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuD5P-0000IK-0g; Fri, 01 Jun 2007 15:46:59 -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 1HuD5O-0002ht-GV; Fri, 01 Jun 2007 15:46:58 -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 l51Jka6U005089; Fri, 1 Jun 2007 22:46:56 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 22:46:50 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 14:46:38 -0500 Received: from 10.241.58.171 ([10.241.58.171]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Jun 2007 19:46:38 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 01 Jun 2007 14:46:40 -0500 From: Basavaraj Patil To: ext Basavaraj Patil , Mobile IPv6 Mailing List , Message-ID: Thread-Topic: Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiASz3DPB In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Jun 2007 19:46:38.0225 (UTC) FILETIME=[91833810:01C7A485] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Subject: [Mip6] Summary and conclusion of: 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 So after an extensive discussion on this topic which spun off into a discussion about the need/use for GRE, I would like to summarize where we are with the options that we have. Conclusion was that for DS-MIP6, Option 1 which is : " Parse the protocol header following the UDP header" is good enough. So it implies no changes to the current text in the DS-MIP6 I-D w.r.t this issue are needed. It was pointed out that in the future if GRE was determined as a protocol that needs to be supported as well either for MIP6, NEMO or PMIP6 then it would be specified in the appropriate WG and a UDP port reserved for the same. In such a case it would essentially be the equivalent of option 2 in the choices list (below). At this time, the need for GRE especially in the scope of DS-MIP6 which is primarily MIP6 and NEMO is not proven. Hence we will move forward with Option 1 and close this issue. -Raj On 5/8/07 4:16 PM, "ext Basavaraj Patil" wrote: > > 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 Fri Jun 01 16:52: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 1HuE7C-0002F7-7s; Fri, 01 Jun 2007 16:52:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuE7A-0002Eo-Fq; Fri, 01 Jun 2007 16:52:52 -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 1HuE78-0003OL-Ps; Fri, 01 Jun 2007 16:52:52 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HuE77-0005QQ-OZ; Fri, 01 Jun 2007 22:52:49 +0200 Message-ID: <46608721.1030902@levkowetz.com> Date: Fri, 01 Jun 2007 22:52:49 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Basavaraj Patil References: In-Reply-To: X-Enigmail-Version: 0.95.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: b280b4db656c3ca28dd62e5e0b03daa8 Cc: nemo@ietf.org, Mobile IPv6 Mailing List Subject: [Mip6] Re: [nemo] Summary and conclusion of: 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 Hi Raj, On 2007-06-01 21:46 Basavaraj Patil said the following: > So after an extensive discussion on this topic which spun off into a > discussion about the need/use for GRE, I would like to summarize where we > are with the options that we have. > > Conclusion was that for DS-MIP6, Option 1 which is : " Parse the protocol > header following the UDP header" is good enough. Could you give us an indication of who preferred which option? You seem to be very clear about the outcome, while it was far from obvious to me that the counts turned out to support above conclusion... Henrik > So it implies no changes to the current text in the DS-MIP6 I-D w.r.t this > issue are needed. > > > It was pointed out that in the future if GRE was determined as a protocol > that needs to be supported as well either for MIP6, NEMO or PMIP6 then it > would be specified in the appropriate WG and a UDP port reserved for the > same. In such a case it would essentially be the equivalent of option 2 in > the choices list (below). > > At this time, the need for GRE especially in the scope of DS-MIP6 which is > primarily MIP6 and NEMO is not proven. Hence we will move forward with > Option 1 and close this issue. > > -Raj > > > > On 5/8/07 4:16 PM, "ext Basavaraj Patil" wrote: > >> 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 Fri Jun 01 17:18: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 1HuEVk-0004lp-7V; Fri, 01 Jun 2007 17:18:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuEVj-0004lI-1n; Fri, 01 Jun 2007 17:18:15 -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 1HuEVi-0003Nu-GC; Fri, 01 Jun 2007 17:18:15 -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 l51LI3mv014621; Sat, 2 Jun 2007 00:18:12 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Jun 2007 00:18:07 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 16:18:02 -0500 Received: from 10.241.59.35 ([10.241.59.35]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Jun 2007 21:18:02 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 01 Jun 2007 16:18:05 -0500 From: Basavaraj Patil To: Levkowetz Message-ID: Thread-Topic: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: AcekklfilimLPBCFEdyx6wARJNUNiA== In-Reply-To: <46608721.1030902@levkowetz.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Jun 2007 21:18:02.0807 (UTC) FILETIME=[56940470:01C7A492] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: nemo@ietf.org, Mobile IPv6 Mailing List Subject: [Mip6] Re: [nemo] Summary and conclusion of: 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 Henrik, Rough consensus is what I am going by here. But I will send the count or who chose what if it helps anyway. -Raj On 6/1/07 3:52 PM, "ext Henrik Levkowetz" wrote: > Hi Raj, > > On 2007-06-01 21:46 Basavaraj Patil said the following: >> So after an extensive discussion on this topic which spun off into a >> discussion about the need/use for GRE, I would like to summarize where we >> are with the options that we have. >> >> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the protocol >> header following the UDP header" is good enough. > > Could you give us an indication of who preferred which option? You seem > to be very clear about the outcome, while it was far from obvious to me > that the counts turned out to support above conclusion... > > > Henrik > >> So it implies no changes to the current text in the DS-MIP6 I-D w.r.t this >> issue are needed. >> >> >> It was pointed out that in the future if GRE was determined as a protocol >> that needs to be supported as well either for MIP6, NEMO or PMIP6 then it >> would be specified in the appropriate WG and a UDP port reserved for the >> same. In such a case it would essentially be the equivalent of option 2 in >> the choices list (below). >> >> At this time, the need for GRE especially in the scope of DS-MIP6 which is >> primarily MIP6 and NEMO is not proven. Hence we will move forward with >> Option 1 and close this issue. >> >> -Raj >> >> >> >> On 5/8/07 4:16 PM, "ext Basavaraj Patil" wrote: >> >>> 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 Fri Jun 01 17:37: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 1HuEoW-00015G-Gz; Fri, 01 Jun 2007 17:37:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuEoV-00014k-9Z; Fri, 01 Jun 2007 17:37:39 -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 1HuEoT-0002XC-O4; Fri, 01 Jun 2007 17:37:39 -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 l51LbJSA006619; Sat, 2 Jun 2007 00:37:35 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Jun 2007 00:36:47 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 16:36:25 -0500 Received: from 10.241.59.35 ([10.241.59.35]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Jun 2007 21:36:25 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 01 Jun 2007 16:36:27 -0500 From: Basavaraj Patil To: Levkowetz Message-ID: Thread-Topic: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: AceklOi6J29uFhCIEdyx6wARJNUNiA== In-Reply-To: <46608721.1030902@levkowetz.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Jun 2007 21:36:25.0525 (UTC) FILETIME=[E7D96E50:01C7A494] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: nemo@ietf.org, Mobile IPv6 Mailing List Subject: [Mip6] Re: [nemo] Summary and conclusion of: 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 Vijay D. - Option 4 originally and then changed to Option 2 Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - Option 1 (Interpreted) So we have a sort of a tie if you strictly go by count. If I were to express my own opinion (non-chair-hat), I would go with option 1 as well for the current DS-MIP6 proposal (aligned with my earlier email that if and when GRE is planned for use, another UDP port can be reserved... But for now option 1). That would break any deadlock issues. Or the other way is to let the chairs decide what is the sense of the discussion on the ML and from the perspective of the charter/scope and urgency of this protocol. And from this angle as well, I would stick by my conclusion, i.e option 1. -Raj On 6/1/07 3:52 PM, "ext Henrik Levkowetz" wrote: > Hi Raj, > > On 2007-06-01 21:46 Basavaraj Patil said the following: >> So after an extensive discussion on this topic which spun off into a >> discussion about the need/use for GRE, I would like to summarize where we >> are with the options that we have. >> >> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the protocol >> header following the UDP header" is good enough. > > Could you give us an indication of who preferred which option? You seem > to be very clear about the outcome, while it was far from obvious to me > that the counts turned out to support above conclusion... > > > Henrik > >> So it implies no changes to the current text in the DS-MIP6 I-D w.r.t this >> issue are needed. >> >> >> It was pointed out that in the future if GRE was determined as a protocol >> that needs to be supported as well either for MIP6, NEMO or PMIP6 then it >> would be specified in the appropriate WG and a UDP port reserved for the >> same. In such a case it would essentially be the equivalent of option 2 in >> the choices list (below). >> >> At this time, the need for GRE especially in the scope of DS-MIP6 which is >> primarily MIP6 and NEMO is not proven. Hence we will move forward with >> Option 1 and close this issue. >> >> -Raj >> >> >> >> On 5/8/07 4:16 PM, "ext Basavaraj Patil" wrote: >> >>> 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 Fri Jun 01 18:13: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 1HuFMx-0008Gy-BR; Fri, 01 Jun 2007 18:13:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFMv-0007yR-8C; Fri, 01 Jun 2007 18:13:13 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuFMu-0005dK-MM; Fri, 01 Jun 2007 18:13:13 -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 l51MDAxH002849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2007 15:13:11 -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 l51MDA5e029026; Fri, 1 Jun 2007 15:13:10 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 15:13:10 -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] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Date: Fri, 1 Jun 2007 15:13:11 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: AceklOi6J29uFhCIEdyx6wARJNUNiAABRPsw References: <46608721.1030902@levkowetz.com> From: "Narayanan, Vidya" To: "Basavaraj Patil" , "Levkowetz" X-OriginalArrivalTime: 01 Jun 2007 22:13:10.0314 (UTC) FILETIME=[0A0188A0:01C7A49A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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 FWIW, I had also supported going with Option 1 for DS-MIP6.=20 Vidya=20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Friday, June 01, 2007 2:36 PM > To: Levkowetz > Cc: nemo@ietf.org; Mobile IPv6 Mailing List > Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6=20 > - Consensus call to close issue 93 >=20 >=20 >=20 > Vijay D. - Option 4 originally and then changed to Option 2=20 > Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3=20 > Ahmad Muhanna - Option 3 Alex Petrescu - Option 1=20 > (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3=20 > Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. -=20 > Option 1 (Interpreted) >=20 > So we have a sort of a tie if you strictly go by count. > If I were to express my own opinion (non-chair-hat), I would=20 > go with option 1 as well for the current DS-MIP6 proposal=20 > (aligned with my earlier email that if and when GRE is=20 > planned for use, another UDP port can be reserved... But for=20 > now option 1). That would break any deadlock issues. >=20 > Or the other way is to let the chairs decide what is the=20 > sense of the discussion on the ML and from the perspective of=20 > the charter/scope and urgency of this protocol. And from this=20 > angle as well, I would stick by my conclusion, i.e option 1. >=20 > -Raj >=20 >=20 > On 6/1/07 3:52 PM, "ext Henrik Levkowetz"=20 > wrote: >=20 > > Hi Raj, > >=20 > > On 2007-06-01 21:46 Basavaraj Patil said the following: > >> So after an extensive discussion on this topic which spun=20 > off into a=20 > >> discussion about the need/use for GRE, I would like to summarize=20 > >> where we are with the options that we have. > >>=20 > >> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the=20 > >> protocol header following the UDP header" is good enough. > >=20 > > Could you give us an indication of who preferred which option? You=20 > > seem to be very clear about the outcome, while it was far=20 > from obvious=20 > > to me that the counts turned out to support above conclusion... > >=20 > >=20 > > Henrik > >=20 > >> So it implies no changes to the current text in the=20 > DS-MIP6 I-D w.r.t=20 > >> this issue are needed. > >>=20 > >>=20 > >> It was pointed out that in the future if GRE was determined as a=20 > >> protocol that needs to be supported as well either for=20 > MIP6, NEMO or=20 > >> PMIP6 then it would be specified in the appropriate WG and=20 > a UDP port=20 > >> reserved for the same. In such a case it would essentially be the=20 > >> equivalent of option 2 in the choices list (below). > >>=20 > >> At this time, the need for GRE especially in the scope of DS-MIP6=20 > >> which is primarily MIP6 and NEMO is not proven. Hence we will move=20 > >> forward with Option 1 and close this issue. > >>=20 > >> -Raj > >>=20 > >>=20 > >>=20 > >> On 5/8/07 4:16 PM, "ext Basavaraj Patil"=20 > wrote: > >>=20 > >>> Hello, > >>>=20 > >>> The DS-MIP6 I-D =20 > still has=20 > >>> issue 93 open. This was discussed at IETF68. Vijay presented 4=20 > >>> 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=20 > >>> I-D. At the meeting itself, I got the sense that option 3 was the=20 > >>> 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=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=20 > >>> 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.)=20 > >>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > >>> 4. Encapsulated protocol header type is indicated in the=20 > BU message > >>>=20 > >>> Pros and cons of these choices are in the slides that=20 > were presented=20 > >>> at IETF68 (see URL above). > >>>=20 > >>> Please provide your opinions and comments by May 15th, 07 on the=20 > >>> MIP6 mailing list. > >>>=20 > >>> -Raj > >>>=20 > >>>=20 > >>> _______________________________________________ > >>> Mip6 mailing list > >>> Mip6@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mip6 > >>=20 > >>=20 > >>=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 From mip6-bounces@ietf.org Fri Jun 01 18:13: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 1HuFNW-0000zF-OY; Fri, 01 Jun 2007 18:13:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFNU-0000xv-Cx; Fri, 01 Jun 2007 18:13:48 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuFNT-00069K-Tr; Fri, 01 Jun 2007 18:13:48 -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 l51MDAxH002849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2007 15:13:11 -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 l51MDA5e029026; Fri, 1 Jun 2007 15:13:10 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 15:13:10 -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] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Date: Fri, 1 Jun 2007 15:13:11 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: AceklOi6J29uFhCIEdyx6wARJNUNiAABRPsw References: <46608721.1030902@levkowetz.com> From: "Narayanan, Vidya" To: "Basavaraj Patil" , "Levkowetz" X-OriginalArrivalTime: 01 Jun 2007 22:13:10.0314 (UTC) FILETIME=[0A0188A0:01C7A49A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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 FWIW, I had also supported going with Option 1 for DS-MIP6.=20 Vidya=20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Friday, June 01, 2007 2:36 PM > To: Levkowetz > Cc: nemo@ietf.org; Mobile IPv6 Mailing List > Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6=20 > - Consensus call to close issue 93 >=20 >=20 >=20 > Vijay D. - Option 4 originally and then changed to Option 2=20 > Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3=20 > Ahmad Muhanna - Option 3 Alex Petrescu - Option 1=20 > (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3=20 > Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. -=20 > Option 1 (Interpreted) >=20 > So we have a sort of a tie if you strictly go by count. > If I were to express my own opinion (non-chair-hat), I would=20 > go with option 1 as well for the current DS-MIP6 proposal=20 > (aligned with my earlier email that if and when GRE is=20 > planned for use, another UDP port can be reserved... But for=20 > now option 1). That would break any deadlock issues. >=20 > Or the other way is to let the chairs decide what is the=20 > sense of the discussion on the ML and from the perspective of=20 > the charter/scope and urgency of this protocol. And from this=20 > angle as well, I would stick by my conclusion, i.e option 1. >=20 > -Raj >=20 >=20 > On 6/1/07 3:52 PM, "ext Henrik Levkowetz"=20 > wrote: >=20 > > Hi Raj, > >=20 > > On 2007-06-01 21:46 Basavaraj Patil said the following: > >> So after an extensive discussion on this topic which spun=20 > off into a=20 > >> discussion about the need/use for GRE, I would like to summarize=20 > >> where we are with the options that we have. > >>=20 > >> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the=20 > >> protocol header following the UDP header" is good enough. > >=20 > > Could you give us an indication of who preferred which option? You=20 > > seem to be very clear about the outcome, while it was far=20 > from obvious=20 > > to me that the counts turned out to support above conclusion... > >=20 > >=20 > > Henrik > >=20 > >> So it implies no changes to the current text in the=20 > DS-MIP6 I-D w.r.t=20 > >> this issue are needed. > >>=20 > >>=20 > >> It was pointed out that in the future if GRE was determined as a=20 > >> protocol that needs to be supported as well either for=20 > MIP6, NEMO or=20 > >> PMIP6 then it would be specified in the appropriate WG and=20 > a UDP port=20 > >> reserved for the same. In such a case it would essentially be the=20 > >> equivalent of option 2 in the choices list (below). > >>=20 > >> At this time, the need for GRE especially in the scope of DS-MIP6=20 > >> which is primarily MIP6 and NEMO is not proven. Hence we will move=20 > >> forward with Option 1 and close this issue. > >>=20 > >> -Raj > >>=20 > >>=20 > >>=20 > >> On 5/8/07 4:16 PM, "ext Basavaraj Patil"=20 > wrote: > >>=20 > >>> Hello, > >>>=20 > >>> The DS-MIP6 I-D =20 > still has=20 > >>> issue 93 open. This was discussed at IETF68. Vijay presented 4=20 > >>> 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=20 > >>> I-D. At the meeting itself, I got the sense that option 3 was the=20 > >>> 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=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=20 > >>> 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.)=20 > >>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > >>> 4. Encapsulated protocol header type is indicated in the=20 > BU message > >>>=20 > >>> Pros and cons of these choices are in the slides that=20 > were presented=20 > >>> at IETF68 (see URL above). > >>>=20 > >>> Please provide your opinions and comments by May 15th, 07 on the=20 > >>> MIP6 mailing list. > >>>=20 > >>> -Raj > >>>=20 > >>>=20 > >>> _______________________________________________ > >>> Mip6 mailing list > >>> Mip6@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mip6 > >>=20 > >>=20 > >>=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 From mip6-bounces@ietf.org Fri Jun 01 19:27: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 1HuGWv-0004wH-HX; Fri, 01 Jun 2007 19:27:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGWt-0004ly-K0 for mip6@ietf.org; Fri, 01 Jun 2007 19:27:35 -0400 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HuGWs-0007hz-29 for mip6@ietf.org; Fri, 01 Jun 2007 19:27:35 -0400 Received: (qmail 5458 invoked for bounce); 2 Jun 2007 01:29:46 -0000 Received: from unknown (HELO ?192.168.3.7?) (lorchat@unknown) by unknown with SMTP; 2 Jun 2007 01:29:46 -0000 Message-ID: <4660AB63.3010608@sfc.wide.ad.jp> Date: Sat, 02 Jun 2007 08:27:31 +0900 From: Jean Lorchat User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070521) MIME-Version: 1.0 To: nemo@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Mobile IPv6 Mailing List Subject: [Mip6] Re: [nemo] Summary and conclusion of: 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 Hi, In the Nautilus6 project, we are working on a Linux implementation of the DS-MIP6 draft and as such, we currently provide option 1. It seems satisfactory enough for us and we have no issues to report with that, as of yet. Implicitly, I'd say we support option 1 as implementors. Also, I personally feel that it is important for the DS-MIP6 specification to move forward quickly. Regards, Jean Basavaraj Patil wrote: > > Vijay D. - Option 4 originally and then changed to Option 2 > Hesham - Option 1 > Sri Gundavelli - Option 3 > Kent - Option 3 > Ahmad Muhanna - Option 3 > Alex Petrescu - Option 1 (Interpreted) > George T. - Option 1 > Mohamed Khalil - Option 3 > Markku Ala-V - Option 2 > Henrik L. - Option 3 > Pascal T. - Option 1 (Interpreted) > > So we have a sort of a tie if you strictly go by count. > If I were to express my own opinion (non-chair-hat), I would go with > option 1 as well for the current DS-MIP6 proposal (aligned with my > earlier email that if and when GRE is planned for use, another UDP > port can be reserved... But for now option 1). That would break any > deadlock issues. > > Or the other way is to let the chairs decide what is the sense of the > discussion on the ML and from the perspective of the charter/scope and > urgency of this protocol. And from this angle as well, I would stick > by my conclusion, i.e option 1. > > -Raj > > > On 6/1/07 3:52 PM, "ext Henrik Levkowetz" wrote: > >> Hi Raj, >> >> On 2007-06-01 21:46 Basavaraj Patil said the following: >>> So after an extensive discussion on this topic which spun off into a >>> discussion about the need/use for GRE, I would like to summarize where we >>> are with the options that we have. >>> >>> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the protocol >>> header following the UDP header" is good enough. >> Could you give us an indication of who preferred which option? You seem >> to be very clear about the outcome, while it was far from obvious to me >> that the counts turned out to support above conclusion... >> >> >> Henrik >> >>> So it implies no changes to the current text in the DS-MIP6 I-D w.r.t this >>> issue are needed. >>> >>> >>> It was pointed out that in the future if GRE was determined as a protocol >>> that needs to be supported as well either for MIP6, NEMO or PMIP6 then it >>> would be specified in the appropriate WG and a UDP port reserved for the >>> same. In such a case it would essentially be the equivalent of option 2 in >>> the choices list (below). >>> >>> At this time, the need for GRE especially in the scope of DS-MIP6 which is >>> primarily MIP6 and NEMO is not proven. Hence we will move forward with >>> Option 1 and close this issue. >>> >>> -Raj >>> >>> >>> >>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" wrote: >>> >>>> 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 Fri Jun 01 19:27: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 1HuGXG-0006M4-Nn; Fri, 01 Jun 2007 19:27:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGXE-0006LJ-OS; Fri, 01 Jun 2007 19:27:56 -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 1HuGXC-0007is-TX; Fri, 01 Jun 2007 19:27:56 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HuGXC-000606-3z; Sat, 02 Jun 2007 01:27:54 +0200 Message-ID: <4660AB79.3050204@levkowetz.com> Date: Sat, 02 Jun 2007 01:27:53 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Basavaraj Patil References: In-Reply-To: X-Enigmail-Version: 0.95.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: a1852b4f554b02e7e4548cc7928acc1f Cc: nemo@ietf.org, Mobile IPv6 Mailing List Subject: [Mip6] Re: [nemo] Summary and conclusion of: 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 On 2007-06-01 23:36 Basavaraj Patil said the following: > > Vijay D. - Option 4 originally and then changed to Option 2 > Hesham - Option 1 > Sri Gundavelli - Option 3 > Kent - Option 3 > Ahmad Muhanna - Option 3 > Alex Petrescu - Option 1 (Interpreted) > George T. - Option 1 > Mohamed Khalil - Option 3 > Markku Ala-V - Option 2 > Henrik L. - Option 3 > Pascal T. - Option 1 (Interpreted) > > So we have a sort of a tie if you strictly go by count. No, if we strictly go by the above count, there's no tie: Option 3 5 counts Option 1 4 counts Option 2 2 counts > If I were to express my own opinion (non-chair-hat), I would go with > option 1 as well for the current DS-MIP6 proposal (aligned with my > earlier email that if and when GRE is planned for use, another UDP > port can be reserved... But for now option 1). That would break any > deadlock issues. That would be credible if you'd said that before pronouncing a consensus for option 1. Now it doesn't. > Or the other way is to let the chairs decide what is the sense of the > discussion on the ML and from the perspective of the charter/scope and > urgency of this protocol. And from this angle as well, I would stick > by my conclusion, i.e option 1. That was my original reason for asking for the count -- having followed the discussion, my perception was *very* different, and there wasn't a consensus for 1 in the sense of the discussion. Henrik > -Raj > > > On 6/1/07 3:52 PM, "ext Henrik Levkowetz" wrote: > >> Hi Raj, >> >> On 2007-06-01 21:46 Basavaraj Patil said the following: >>> So after an extensive discussion on this topic which spun off into a >>> discussion about the need/use for GRE, I would like to summarize where we >>> are with the options that we have. >>> >>> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the protocol >>> header following the UDP header" is good enough. >> Could you give us an indication of who preferred which option? You seem >> to be very clear about the outcome, while it was far from obvious to me >> that the counts turned out to support above conclusion... >> >> >> Henrik >> >>> So it implies no changes to the current text in the DS-MIP6 I-D w.r.t this >>> issue are needed. >>> >>> >>> It was pointed out that in the future if GRE was determined as a protocol >>> that needs to be supported as well either for MIP6, NEMO or PMIP6 then it >>> would be specified in the appropriate WG and a UDP port reserved for the >>> same. In such a case it would essentially be the equivalent of option 2 in >>> the choices list (below). >>> >>> At this time, the need for GRE especially in the scope of DS-MIP6 which is >>> primarily MIP6 and NEMO is not proven. Hence we will move forward with >>> Option 1 and close this issue. >>> >>> -Raj >>> >>> >>> >>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" wrote: >>> >>>> 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 Fri Jun 01 19:28: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 1HuGXr-0006db-GA; Fri, 01 Jun 2007 19:28:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGXp-0006c9-V7; Fri, 01 Jun 2007 19:28:33 -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 1HuGXp-0007nI-E3; Fri, 01 Jun 2007 19:28:33 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HuGXl-00061e-Qz; Sat, 02 Jun 2007 01:28:29 +0200 Message-ID: <4660AB9D.3040809@levkowetz.com> Date: Sat, 02 Jun 2007 01:28:29 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 References: <46608721.1030902@levkowetz.com> In-Reply-To: X-Enigmail-Version: 0.95.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: vidyan@qualcomm.com, basavaraj.patil@nsn.com, nemo@ietf.org, 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: 0770535483960d190d4a0d020e7060bd 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 Vidya, Rai, On 2007-06-02 00:13 Narayanan, Vidya said the following: > FWIW, I had also supported going with Option 1 for DS-MIP6. Of course that matters, Vidya, but the more important thing here is that it's pretty clear to me that there is *no* rough consensus present. Please don't manufacture one when there isn't one; if there really isn't one, do another call for discussion and/or show of hands, and if the group is deadlocked, use 3929. I can't accept this pronouncement of a consensus, rough or not, in the group, neither from my observation of the discussion or from the count. Henrik > Vidya > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Friday, June 01, 2007 2:36 PM >> To: Levkowetz >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List >> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 >> - Consensus call to close issue 93 >> >> >> >> Vijay D. - Option 4 originally and then changed to Option 2 >> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 >> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 >> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 >> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - >> Option 1 (Interpreted) >> >> So we have a sort of a tie if you strictly go by count. >> If I were to express my own opinion (non-chair-hat), I would >> go with option 1 as well for the current DS-MIP6 proposal >> (aligned with my earlier email that if and when GRE is >> planned for use, another UDP port can be reserved... But for >> now option 1). That would break any deadlock issues. >> >> Or the other way is to let the chairs decide what is the >> sense of the discussion on the ML and from the perspective of >> the charter/scope and urgency of this protocol. And from this >> angle as well, I would stick by my conclusion, i.e option 1. >> >> -Raj >> >> >> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" >> wrote: >> >>> Hi Raj, >>> >>> On 2007-06-01 21:46 Basavaraj Patil said the following: >>>> So after an extensive discussion on this topic which spun >> off into a >>>> discussion about the need/use for GRE, I would like to summarize >>>> where we are with the options that we have. >>>> >>>> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the >>>> protocol header following the UDP header" is good enough. >>> Could you give us an indication of who preferred which option? You >>> seem to be very clear about the outcome, while it was far >> from obvious >>> to me that the counts turned out to support above conclusion... >>> >>> >>> Henrik >>> >>>> So it implies no changes to the current text in the >> DS-MIP6 I-D w.r.t >>>> this issue are needed. >>>> >>>> >>>> It was pointed out that in the future if GRE was determined as a >>>> protocol that needs to be supported as well either for >> MIP6, NEMO or >>>> PMIP6 then it would be specified in the appropriate WG and >> a UDP port >>>> reserved for the same. In such a case it would essentially be the >>>> equivalent of option 2 in the choices list (below). >>>> >>>> At this time, the need for GRE especially in the scope of DS-MIP6 >>>> which is primarily MIP6 and NEMO is not proven. Hence we will move >>>> forward with Option 1 and close this issue. >>>> >>>> -Raj >>>> >>>> >>>> >>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" >> wrote: >>>>> 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 Jun 01 19:44: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 1HuGn0-0008R9-7A; Fri, 01 Jun 2007 19:44:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGmy-0008Qd-5K; Fri, 01 Jun 2007 19:44:12 -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 1HuGmx-0002bu-7T; Fri, 01 Jun 2007 19:44:12 -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 l51Ni2tD007749; Sat, 2 Jun 2007 02:44:09 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Jun 2007 02:44:07 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 18:44:05 -0500 Received: from 10.241.58.165 ([10.241.58.165]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Jun 2007 23:44:05 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 01 Jun 2007 18:44:06 -0500 From: Basavaraj Patil To: Levkowetz Message-ID: Thread-Topic: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: Acekpr3Z/Kv7EBCZEdyx6wARJNUNiA== In-Reply-To: <4660AB79.3050204@levkowetz.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Jun 2007 23:44:05.0382 (UTC) FILETIME=[BD7ADA60:01C7A4A6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: nemo@ietf.org, Mobile IPv6 Mailing List Subject: [Mip6] Re: [nemo] Summary and conclusion of: 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 Henrik, On 6/1/07 6:27 PM, "ext Henrik Levkowetz" wrote: > > > On 2007-06-01 23:36 Basavaraj Patil said the following: >> >> Vijay D. - Option 4 originally and then changed to Option 2 >> Hesham - Option 1 >> Sri Gundavelli - Option 3 >> Kent - Option 3 >> Ahmad Muhanna - Option 3 >> Alex Petrescu - Option 1 (Interpreted) >> George T. - Option 1 >> Mohamed Khalil - Option 3 >> Markku Ala-V - Option 2 >> Henrik L. - Option 3 >> Pascal T. - Option 1 (Interpreted) >> >> So we have a sort of a tie if you strictly go by count. > > No, if we strictly go by the above count, there's no tie: > > Option 3 5 counts > Option 1 4 counts > Option 2 2 counts Guess I need to count better. Sorry, my mistake. Yes based on the above that is true. But I missed Vidya in this count (which she indicated following the email). So if I were to include Vidya in the count and myself, it would be very rough consensus. -Raj > >> If I were to express my own opinion (non-chair-hat), I would go with >> option 1 as well for the current DS-MIP6 proposal (aligned with my >> earlier email that if and when GRE is planned for use, another UDP >> port can be reserved... But for now option 1). That would break any >> deadlock issues. > > That would be credible if you'd said that before pronouncing a consensus > for option 1. Now it doesn't. > >> Or the other way is to let the chairs decide what is the sense of the >> discussion on the ML and from the perspective of the charter/scope and >> urgency of this protocol. And from this angle as well, I would stick >> by my conclusion, i.e option 1. > > That was my original reason for asking for the count -- having followed > the discussion, my perception was *very* different, and there wasn't a > consensus for 1 in the sense of the discussion. > > > Henrik > > >> -Raj >> >> >> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" wrote: >> >>> Hi Raj, >>> >>> On 2007-06-01 21:46 Basavaraj Patil said the following: >>>> So after an extensive discussion on this topic which spun off into a >>>> discussion about the need/use for GRE, I would like to summarize where we >>>> are with the options that we have. >>>> >>>> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the protocol >>>> header following the UDP header" is good enough. >>> Could you give us an indication of who preferred which option? You seem >>> to be very clear about the outcome, while it was far from obvious to me >>> that the counts turned out to support above conclusion... >>> >>> >>> Henrik >>> >>>> So it implies no changes to the current text in the DS-MIP6 I-D w.r.t this >>>> issue are needed. >>>> >>>> >>>> It was pointed out that in the future if GRE was determined as a protocol >>>> that needs to be supported as well either for MIP6, NEMO or PMIP6 then it >>>> would be specified in the appropriate WG and a UDP port reserved for the >>>> same. In such a case it would essentially be the equivalent of option 2 in >>>> the choices list (below). >>>> >>>> At this time, the need for GRE especially in the scope of DS-MIP6 which is >>>> primarily MIP6 and NEMO is not proven. Hence we will move forward with >>>> Option 1 and close this issue. >>>> >>>> -Raj >>>> >>>> >>>> >>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" wrote: >>>> >>>>> 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 Fri Jun 01 19: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 1HuGus-0006X2-MK; Fri, 01 Jun 2007 19:52:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGuq-0006N8-PD; Fri, 01 Jun 2007 19:52:20 -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 1HuGuq-0003dM-2H; Fri, 01 Jun 2007 19:52:20 -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 l51Nq8G8014602; Sat, 2 Jun 2007 02:52:18 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Jun 2007 02:52:15 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 18:52:13 -0500 Received: from 10.241.58.165 ([10.241.58.165]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Jun 2007 23:52:13 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 01 Jun 2007 18:52:15 -0500 Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 From: Basavaraj Patil To: Levkowetz , "Narayanan, Vidya" Message-ID: Thread-Topic: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: Acekp+FQH7aIcRCbEdyx6wARJNUNiA== In-Reply-To: <4660AB9D.3040809@levkowetz.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Jun 2007 23:52:13.0654 (UTC) FILETIME=[E0833F60:01C7A4A7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d 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 Henrik, Rough consensus is what we have from my perspective on this issue. It is not being fabricated. Apparently you differ. I can ask Jari (AD) for his recommendation on whether: 1. To do a new consensus call 2. Use any of the RFC 3929 alternatives -Raj On 6/1/07 6:28 PM, "ext Henrik Levkowetz" wrote: > Hi Vidya, Rai, > > On 2007-06-02 00:13 Narayanan, Vidya said the following: >> FWIW, I had also supported going with Option 1 for DS-MIP6. > > Of course that matters, Vidya, but the more important thing here > is that it's pretty clear to me that there is *no* rough consensus > present. > > Please don't manufacture one when there isn't one; if there > really isn't one, do another call for discussion and/or show > of hands, and if the group is deadlocked, use 3929. > > I can't accept this pronouncement of a consensus, rough or not, > in the group, neither from my observation of the discussion or > from the count. > > > Henrik > > >> Vidya >> >>> -----Original Message----- >>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>> Sent: Friday, June 01, 2007 2:36 PM >>> To: Levkowetz >>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List >>> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 >>> - Consensus call to close issue 93 >>> >>> >>> >>> Vijay D. - Option 4 originally and then changed to Option 2 >>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 >>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 >>> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 >>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - >>> Option 1 (Interpreted) >>> >>> So we have a sort of a tie if you strictly go by count. >>> If I were to express my own opinion (non-chair-hat), I would >>> go with option 1 as well for the current DS-MIP6 proposal >>> (aligned with my earlier email that if and when GRE is >>> planned for use, another UDP port can be reserved... But for >>> now option 1). That would break any deadlock issues. >>> >>> Or the other way is to let the chairs decide what is the >>> sense of the discussion on the ML and from the perspective of >>> the charter/scope and urgency of this protocol. And from this >>> angle as well, I would stick by my conclusion, i.e option 1. >>> >>> -Raj >>> >>> >>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" >>> wrote: >>> >>>> Hi Raj, >>>> >>>> On 2007-06-01 21:46 Basavaraj Patil said the following: >>>>> So after an extensive discussion on this topic which spun >>> off into a >>>>> discussion about the need/use for GRE, I would like to summarize >>>>> where we are with the options that we have. >>>>> >>>>> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the >>>>> protocol header following the UDP header" is good enough. >>>> Could you give us an indication of who preferred which option? You >>>> seem to be very clear about the outcome, while it was far >>> from obvious >>>> to me that the counts turned out to support above conclusion... >>>> >>>> >>>> Henrik >>>> >>>>> So it implies no changes to the current text in the >>> DS-MIP6 I-D w.r.t >>>>> this issue are needed. >>>>> >>>>> >>>>> It was pointed out that in the future if GRE was determined as a >>>>> protocol that needs to be supported as well either for >>> MIP6, NEMO or >>>>> PMIP6 then it would be specified in the appropriate WG and >>> a UDP port >>>>> reserved for the same. In such a case it would essentially be the >>>>> equivalent of option 2 in the choices list (below). >>>>> >>>>> At this time, the need for GRE especially in the scope of DS-MIP6 >>>>> which is primarily MIP6 and NEMO is not proven. Hence we will move >>>>> forward with Option 1 and close this issue. >>>>> >>>>> -Raj >>>>> >>>>> >>>>> >>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" >>> wrote: >>>>>> 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 Jun 01 21:42: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 1HuId0-00027Y-30; Fri, 01 Jun 2007 21:42:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuIcy-000278-T8; Fri, 01 Jun 2007 21:42:00 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuIcx-0007ji-0Z; Fri, 01 Jun 2007 21:42:00 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070602014156.HTRS25724.omta05sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Sat, 2 Jun 2007 01:41:56 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta07sl.mx.bigpond.com with ESMTP id <20070602014155.TZKO4756.oaamta07sl.mx.bigpond.com@PC20005>; Sat, 2 Jun 2007 01:41:55 +0000 From: "Hesham Soliman" To: "'Henrik Levkowetz'" , "'Narayanan, Vidya'" Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensuscall to close issue 93 Date: Sat, 2 Jun 2007 11:41:51 +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: <4660AB9D.3040809@levkowetz.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcekpJQfzhZgBsfQR2CLJyxXoLmIUAAElTHQ Message-Id: <20070602014155.TZKO4756.oaamta07sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 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 Henrik, You seem to be looking for a vote. We've always asked for concencus to change anything in the draft. The numbers that Raj sent clearly indicate that there is no concensus to change the draft. 5:4 is not concensus. Therefore, I think Raj's decision is correct. I hope we don't turn the IETF into a voting organisation, if we do then the whole process of providing a vote would be different from what we do today. Hesham > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Saturday, June 02, 2007 9:28 AM > To: Narayanan, Vidya > Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Basavaraj Patil > Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: > DS-MIP6 - Consensuscall to close issue 93 > > Hi Vidya, Rai, > > On 2007-06-02 00:13 Narayanan, Vidya said the following: > > FWIW, I had also supported going with Option 1 for DS-MIP6. > > Of course that matters, Vidya, but the more important thing here > is that it's pretty clear to me that there is *no* rough consensus > present. > > Please don't manufacture one when there isn't one; if there > really isn't one, do another call for discussion and/or show > of hands, and if the group is deadlocked, use 3929. > > I can't accept this pronouncement of a consensus, rough or not, > in the group, neither from my observation of the discussion or > from the count. > > > Henrik > > > > Vidya > > > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >> Sent: Friday, June 01, 2007 2:36 PM > >> To: Levkowetz > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List > >> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 > >> - Consensus call to close issue 93 > >> > >> > >> > >> Vijay D. - Option 4 originally and then changed to Option 2 > >> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 > >> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 > >> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 > >> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - > >> Option 1 (Interpreted) > >> > >> So we have a sort of a tie if you strictly go by count. > >> If I were to express my own opinion (non-chair-hat), I would > >> go with option 1 as well for the current DS-MIP6 proposal > >> (aligned with my earlier email that if and when GRE is > >> planned for use, another UDP port can be reserved... But for > >> now option 1). That would break any deadlock issues. > >> > >> Or the other way is to let the chairs decide what is the > >> sense of the discussion on the ML and from the perspective of > >> the charter/scope and urgency of this protocol. And from this > >> angle as well, I would stick by my conclusion, i.e option 1. > >> > >> -Raj > >> > >> > >> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" > >> wrote: > >> > >>> Hi Raj, > >>> > >>> On 2007-06-01 21:46 Basavaraj Patil said the following: > >>>> So after an extensive discussion on this topic which spun > >> off into a > >>>> discussion about the need/use for GRE, I would like to > summarize > >>>> where we are with the options that we have. > >>>> > >>>> Conclusion was that for DS-MIP6, Option 1 which is : " > Parse the > >>>> protocol header following the UDP header" is good enough. > >>> Could you give us an indication of who preferred which > option? You > >>> seem to be very clear about the outcome, while it was far > >> from obvious > >>> to me that the counts turned out to support above conclusion... > >>> > >>> > >>> Henrik > >>> > >>>> So it implies no changes to the current text in the > >> DS-MIP6 I-D w.r.t > >>>> this issue are needed. > >>>> > >>>> > >>>> It was pointed out that in the future if GRE was > determined as a > >>>> protocol that needs to be supported as well either for > >> MIP6, NEMO or > >>>> PMIP6 then it would be specified in the appropriate WG and > >> a UDP port > >>>> reserved for the same. In such a case it would > essentially be the > >>>> equivalent of option 2 in the choices list (below). > >>>> > >>>> At this time, the need for GRE especially in the scope > of DS-MIP6 > >>>> which is primarily MIP6 and NEMO is not proven. Hence > we will move > >>>> forward with Option 1 and close this issue. > >>>> > >>>> -Raj > >>>> > >>>> > >>>> > >>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" > >> wrote: > >>>>> 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 Jun 01 21:59:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuIth-0004ad-PH; Fri, 01 Jun 2007 21:59:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuItg-0004aI-0r; Fri, 01 Jun 2007 21:59:16 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuIte-0002tM-4k; Fri, 01 Jun 2007 21:59:16 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070602015912.IFOD25724.omta05sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Sat, 2 Jun 2007 01:59:12 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta07sl.mx.bigpond.com with ESMTP id <20070602015911.UCFD4756.oaamta07sl.mx.bigpond.com@PC20005>; Sat, 2 Jun 2007 01:59:11 +0000 From: "Hesham Soliman" To: "'Hesham Soliman'" , "'Henrik Levkowetz'" , "'Narayanan, Vidya'" Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 -Consensuscall to close issue 93 Date: Sat, 2 Jun 2007 11:59:07 +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: <20070602014155.TZKO4756.oaamta07sl.mx.bigpond.com@PC20005> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcekpJQfzhZgBsfQR2CLJyxXoLmIUAAElTHQAACiGBA= Message-Id: <20070602015911.UCFD4756.oaamta07sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee 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 incidentally it is apparently 6:5 in favour of option 1. If the draft contained option 2 today then I would say that 6:5 is not concensus to change the draft. Hesham > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Saturday, June 02, 2007 11:42 AM > To: 'Henrik Levkowetz'; 'Narayanan, Vidya' > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: > DS-MIP6 -Consensuscall to close issue 93 > > Henrik, > > You seem to be looking for a vote. We've always asked for > concencus to > change anything > in the draft. The numbers that Raj sent clearly indicate > that there is no > concensus to change the draft. 5:4 is not concensus. > Therefore, I think > Raj's decision is correct. I hope we don't turn the IETF > into a voting > organisation, if we do then the whole process of providing a > vote would be > different from what we do today. > > Hesham > > > -----Original Message----- > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > Sent: Saturday, June 02, 2007 9:28 AM > > To: Narayanan, Vidya > > Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Basavaraj Patil > > Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: > > DS-MIP6 - Consensuscall to close issue 93 > > > > Hi Vidya, Rai, > > > > On 2007-06-02 00:13 Narayanan, Vidya said the following: > > > FWIW, I had also supported going with Option 1 for DS-MIP6. > > > > Of course that matters, Vidya, but the more important thing here > > is that it's pretty clear to me that there is *no* rough consensus > > present. > > > > Please don't manufacture one when there isn't one; if there > > really isn't one, do another call for discussion and/or show > > of hands, and if the group is deadlocked, use 3929. > > > > I can't accept this pronouncement of a consensus, rough or not, > > in the group, neither from my observation of the discussion or > > from the count. > > > > > > Henrik > > > > > > > Vidya > > > > > >> -----Original Message----- > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > >> Sent: Friday, June 01, 2007 2:36 PM > > >> To: Levkowetz > > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > >> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 > > >> - Consensus call to close issue 93 > > >> > > >> > > >> > > >> Vijay D. - Option 4 originally and then changed to Option 2 > > >> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 > > >> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 > > >> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 > > >> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - > > >> Option 1 (Interpreted) > > >> > > >> So we have a sort of a tie if you strictly go by count. > > >> If I were to express my own opinion (non-chair-hat), I would > > >> go with option 1 as well for the current DS-MIP6 proposal > > >> (aligned with my earlier email that if and when GRE is > > >> planned for use, another UDP port can be reserved... But for > > >> now option 1). That would break any deadlock issues. > > >> > > >> Or the other way is to let the chairs decide what is the > > >> sense of the discussion on the ML and from the perspective of > > >> the charter/scope and urgency of this protocol. And from this > > >> angle as well, I would stick by my conclusion, i.e option 1. > > >> > > >> -Raj > > >> > > >> > > >> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" > > >> wrote: > > >> > > >>> Hi Raj, > > >>> > > >>> On 2007-06-01 21:46 Basavaraj Patil said the following: > > >>>> So after an extensive discussion on this topic which spun > > >> off into a > > >>>> discussion about the need/use for GRE, I would like to > > summarize > > >>>> where we are with the options that we have. > > >>>> > > >>>> Conclusion was that for DS-MIP6, Option 1 which is : " > > Parse the > > >>>> protocol header following the UDP header" is good enough. > > >>> Could you give us an indication of who preferred which > > option? You > > >>> seem to be very clear about the outcome, while it was far > > >> from obvious > > >>> to me that the counts turned out to support above > conclusion... > > >>> > > >>> > > >>> Henrik > > >>> > > >>>> So it implies no changes to the current text in the > > >> DS-MIP6 I-D w.r.t > > >>>> this issue are needed. > > >>>> > > >>>> > > >>>> It was pointed out that in the future if GRE was > > determined as a > > >>>> protocol that needs to be supported as well either for > > >> MIP6, NEMO or > > >>>> PMIP6 then it would be specified in the appropriate WG and > > >> a UDP port > > >>>> reserved for the same. In such a case it would > > essentially be the > > >>>> equivalent of option 2 in the choices list (below). > > >>>> > > >>>> At this time, the need for GRE especially in the scope > > of DS-MIP6 > > >>>> which is primarily MIP6 and NEMO is not proven. Hence > > we will move > > >>>> forward with Option 1 and close this issue. > > >>>> > > >>>> -Raj > > >>>> > > >>>> > > >>>> > > >>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" > > >> wrote: > > >>>>> 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 Jun 01 23:48: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 1HuKbJ-000326-0D; Fri, 01 Jun 2007 23:48:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuKbH-000321-RU for mip6@ietf.org; Fri, 01 Jun 2007 23:48:23 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuKbH-0000am-Cw for mip6@ietf.org; Fri, 01 Jun 2007 23:48:23 -0400 Received: from oaamta04sl.mx.bigpond.com ([124.191.178.123]) by omta04sl.mx.bigpond.com with ESMTP id <20070602034818.FJKE28583.omta04sl.mx.bigpond.com@oaamta04sl.mx.bigpond.com>; Sat, 2 Jun 2007 03:48:18 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta04sl.mx.bigpond.com with ESMTP id <20070602034813.ZDSI1743.oaamta04sl.mx.bigpond.com@PC20005>; Sat, 2 Jun 2007 03:48:13 +0000 From: "Hesham Soliman" To: "'Ahmad Muhanna'" , "'Basavaraj Patil'" , "'Brian Haley'" Subject: RE: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Date: Sat, 2 Jun 2007 13:48: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 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437114A725CF@zrc2hxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcejsVbfS40lMgyLQl23peLZkTLpugAFaWnwAAugWzAAAgC4oAAEMlsgAADb+qAAF/QpWgAA+4EwABSW1dA= Message-Id: <20070602034813.ZDSI1743.oaamta04sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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, > Concern No. 1: > ============== > >>> => Other than wasting a new MH type, I see zero practical > differences. > > >> Since the whole objective here is to save MH type, we > eliminate the > >> need for defining two messages, generic notification message and > >> generic notification acknowledgement. > > > Isn't this such big issue?! > > [Ahmad] > Agreement on preserving the remaining MH types. As per the generic > notification mechanism in draft-haley, the proposed modified > container > mechanism will preserve this as well. => Ok so we agree on this. > Concern No. 2: > ============== > > > > Anyway, if you have a new MH, you should consider the > IPsec setting > > up. > > The MH type is now a selector in IPsec, you need > additional SAD/SPD > > for the new revocation message?! > > [Ahmad] > If we use the generic container mechanism with the proposed > modification, then we are all happy and on the same page. => ok good. I agree with Ryuji's comment on the security aspect. > > Concern No. 3: > ============== > > > > 2. We eliminated the use of the generic notification > sequence number > > > which may be limited in here. As a matter of fact, why do we need > that > > > if the new functionality is going to define all the > needed formats > and > > > details. > > > > You can always overwrite the draft-haley in your document. > > [Ahmad] > Well, my understanding is that we will end up with two > sequence number > fields, one in the generic notification message and another in the > revocation message. Is not that right? If so, why do we need to have > two? => Why can't you use the one in draft-haley? This is a revocation message, it's removing the binding completely, why does it need its own seq number? > > Concern No. 4: > ============== > >> If this messaging mechanism is really generic in the full sense, > >> how anyone expect that one byte of status is enough to > address all > >> possible status for all the possible functionalities that > could ever > >> be masked/encapsulated using this generic messaging mechanism. In > >> other words, I believe that the status should be moved from the => I completely disagree with your premise above. I think 255 is plenty. If a specific message needs more than 255 then it can add its own status. I don't know why you'd need that in this case. > >> Generic notification message header to the specific > message, where it > > >> is more relevant. For example, what the following status > has to do > >> with revocation mechanism, for example: "130 Insufficient > resources". => You don't *have* to use every generic error code, you can use/define the ones that are relevant to you. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Jun 02 03:28: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 1HuO1k-0005a6-O6; Sat, 02 Jun 2007 03:27:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuO1j-0005Zx-CS for mip6@ietf.org; Sat, 02 Jun 2007 03:27:55 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuO1i-0004VV-0J for mip6@ietf.org; Sat, 02 Jun 2007 03:27: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 l527Rpb10967; Sat, 2 Jun 2007 07:27:51 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] Consensus call: Make I-D draft-haley-mip6-mh-signaling-02.txt a WG doc Date: Sat, 2 Jun 2007 02:27:46 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C3F@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Mip6] Consensus call: Make I-D draft-haley-mip6-mh-signaling-02.txt a WG doc Thread-Index: Acek53PjVXmEZCoUTcKLXKz1D5V9zQ== From: "Ahmad Muhanna" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: brian.haley@hp.com, ext 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 Hello, =20 My understanding that the scope of draft-haley is as follows: o A generic container which can be used to communicate multiple=20 functionalities while preserving the MH types. o Introduce a Generic Notification Messages and Generic Notification mechanism=20 that can be used to communicate several common notification event(s) between=20 the HA and the MN. Having said that, I would like to propose a small change to the current=20 Draft-haley revision 02 which would hopefully enrich and enhance the draft. The following summarize the proposed changes: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Define the first two bytes, of the current generic notification message, and call them , for example, Generic Mobility Container, GMC, or XYZ. 2. The Generic Mobility Container is 2 bytes length and can have up to 64k different values which we can call, for example, GMC Type. i.e. Generic Notification Request message, Generic Notification Ack, Binding Revocation Indication message, Binding Revocation Ack, etc. 3. Every common functionality defines its own messages and mechanism including its own mechanism as fits the need of the specified functionality. 4. Any functionality, e.g. Generic Notification, may define the use=20 of any MH option inside its own messages or define new ones. Here is the format, let us use the Generic Notification and Binding=20 Revocation as examples: =20 1. Generic Mobility Container Message=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 This Signaling Generic Mobility Container Message uses the MH Type value (TBD). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GMC Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Message Data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2. Generic Notification =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Let us assume that this application requires two messages, a Request and an acknowledgement. 3.1. Generic Notification Request =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This Generic Notification Request uses a GMC Type of (TBD). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GMC Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Generic Notification Request . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2. Generic Notification Ack =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D This Generic Notification Ack uses a GMC Type of (TBD). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GMC Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Generic Notification Ack . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 3. Binding Revocation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The following are the revocation messages that are defined by the Binding Revocation Functionality as specified by the Binding Revocation for IPv6 Mobility draft. =20 2.1. Binding Revocation Indication =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This Binding Revocation Indication uses a GMC Type of (TBD). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GMC Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Binding Revocation Indication . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 2.2. Binding Revocation Acknowledgement =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This Binding Revocation Acknowledgement uses a GMC Type (TBD). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GMC Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Binding Revocation Acknowledgement . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Finally and as a suggestion, I would like to suggest that draft-haley address two things: 1. Introducing the Generic Mobility Container, GMC. 2. Define the Generic Notification Messages and the related Mechanism. While the Binding Revocation for IPv6 Mobility draft can define the Binding=20 Revocation messages and the binding revocation mechanism. Best Regards, Ahmad > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Wednesday, May 30, 2007 12:23 PM > To: Mobile IPv6 Mailing List > Cc: brian.haley@hp.com; ext Sri Gundavelli > Subject: [Mip6] Consensus call: Make I-D=20 > draft-haley-mip6-mh-signaling-02.txt a WG doc >=20 >=20 > Hello, >=20 > At the Prague IETF (IETF68), the MIP6 WG discussed the following I-D: > Mobility Header Signaling Message=20 > >=20 > There was consensus in the meeting to make this a WG=20 > document. We would like to obtain consensus on the WG ML=20 > prior to making it a WG doc. Please review the I-D and=20 > indicate if you are in favor of this I-D becoming a WG document. >=20 > We will decide after June 10th, 07 the status of this I-D=20 > following the feedback from the WG members. >=20 > 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=20 > event that > requires attention. >=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 Sat Jun 02 06:14:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuQdE-0000SQ-VH; Sat, 02 Jun 2007 06:14:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuQdC-00008n-Fr; Sat, 02 Jun 2007 06:14:46 -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 1HuQdA-0005DV-Fl; Sat, 02 Jun 2007 06:14:46 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HuQd9-00025N-KQ; Sat, 02 Jun 2007 12:14:43 +0200 Message-ID: <46614313.2050302@levkowetz.com> Date: Sat, 02 Jun 2007 12:14:43 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 References: In-Reply-To: X-Enigmail-Version: 0.95.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, nemo@ietf.org, 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: 33cc095b503da4365ce57c727e553cf1 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-06-02 01:52 Basavaraj Patil said the following: > Henrik, > > Rough consensus is what we have from my perspective on this issue. It is not > being fabricated. Then you use a very different definition of rough consensus than I do. I see no consensus at all in this question yet. > Apparently you differ. I can ask Jari (AD) for his recommendation on > whether: > 1. To do a new consensus call > 2. Use any of the RFC 3929 alternatives Yes, please do so. Henrik > -Raj > > On 6/1/07 6:28 PM, "ext Henrik Levkowetz" wrote: > >> Hi Vidya, Rai, >> >> On 2007-06-02 00:13 Narayanan, Vidya said the following: >>> FWIW, I had also supported going with Option 1 for DS-MIP6. >> Of course that matters, Vidya, but the more important thing here >> is that it's pretty clear to me that there is *no* rough consensus >> present. >> >> Please don't manufacture one when there isn't one; if there >> really isn't one, do another call for discussion and/or show >> of hands, and if the group is deadlocked, use 3929. >> >> I can't accept this pronouncement of a consensus, rough or not, >> in the group, neither from my observation of the discussion or >> from the count. >> >> >> Henrik >> >> >>> Vidya >>> >>>> -----Original Message----- >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>>> Sent: Friday, June 01, 2007 2:36 PM >>>> To: Levkowetz >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 >>>> - Consensus call to close issue 93 >>>> >>>> >>>> >>>> Vijay D. - Option 4 originally and then changed to Option 2 >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 >>>> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - >>>> Option 1 (Interpreted) >>>> >>>> So we have a sort of a tie if you strictly go by count. >>>> If I were to express my own opinion (non-chair-hat), I would >>>> go with option 1 as well for the current DS-MIP6 proposal >>>> (aligned with my earlier email that if and when GRE is >>>> planned for use, another UDP port can be reserved... But for >>>> now option 1). That would break any deadlock issues. >>>> >>>> Or the other way is to let the chairs decide what is the >>>> sense of the discussion on the ML and from the perspective of >>>> the charter/scope and urgency of this protocol. And from this >>>> angle as well, I would stick by my conclusion, i.e option 1. >>>> >>>> -Raj >>>> >>>> >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" >>>> wrote: >>>> >>>>> Hi Raj, >>>>> >>>>> On 2007-06-01 21:46 Basavaraj Patil said the following: >>>>>> So after an extensive discussion on this topic which spun >>>> off into a >>>>>> discussion about the need/use for GRE, I would like to summarize >>>>>> where we are with the options that we have. >>>>>> >>>>>> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the >>>>>> protocol header following the UDP header" is good enough. >>>>> Could you give us an indication of who preferred which option? You >>>>> seem to be very clear about the outcome, while it was far >>>> from obvious >>>>> to me that the counts turned out to support above conclusion... >>>>> >>>>> >>>>> Henrik >>>>> >>>>>> So it implies no changes to the current text in the >>>> DS-MIP6 I-D w.r.t >>>>>> this issue are needed. >>>>>> >>>>>> >>>>>> It was pointed out that in the future if GRE was determined as a >>>>>> protocol that needs to be supported as well either for >>>> MIP6, NEMO or >>>>>> PMIP6 then it would be specified in the appropriate WG and >>>> a UDP port >>>>>> reserved for the same. In such a case it would essentially be the >>>>>> equivalent of option 2 in the choices list (below). >>>>>> >>>>>> At this time, the need for GRE especially in the scope of DS-MIP6 >>>>>> which is primarily MIP6 and NEMO is not proven. Hence we will move >>>>>> forward with Option 1 and close this issue. >>>>>> >>>>>> -Raj >>>>>> >>>>>> >>>>>> >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" >>>> wrote: >>>>>>> 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 Sat Jun 02 06:15:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuQeN-00029J-HI; Sat, 02 Jun 2007 06:15:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuQeL-00027y-80; Sat, 02 Jun 2007 06:15:57 -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 1HuQeK-0005Z4-Iq; Sat, 02 Jun 2007 06:15:57 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HuQeI-00067B-MX; Sat, 02 Jun 2007 12:15:54 +0200 Message-ID: <4661435A.2040505@levkowetz.com> Date: Sat, 02 Jun 2007 12:15:54 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensuscall to close issue 93 References: <20070602014155.TZKO4756.oaamta07sl.mx.bigpond.com@PC20005> In-Reply-To: <20070602014155.TZKO4756.oaamta07sl.mx.bigpond.com@PC20005> X-Enigmail-Version: 0.95.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: Hesham@elevatemobile.com, nemo@ietf.org, mip6@ietf.org, basavaraj.patil@nsn.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: 97c820c82c68af374c4e382a80dc5017 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, On 2007-06-02 03:41 Hesham Soliman said the following: > Henrik, > > You seem to be looking for a vote. No, I'm not looking for a vote. I'm looking for consensus on how to handle the issue. And I don't see any consensus on how to handle the issue here. Henrik > We've always asked for concencus to > change anything > in the draft. The numbers that Raj sent clearly indicate that there is no > concensus to change the draft. 5:4 is not concensus. Therefore, I think > Raj's decision is correct. I hope we don't turn the IETF into a voting > organisation, if we do then the whole process of providing a vote would be > different from what we do today. > > Hesham > >> -----Original Message----- >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >> Sent: Saturday, June 02, 2007 9:28 AM >> To: Narayanan, Vidya >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Basavaraj Patil >> Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: >> DS-MIP6 - Consensuscall to close issue 93 >> >> Hi Vidya, Rai, >> >> On 2007-06-02 00:13 Narayanan, Vidya said the following: >>> FWIW, I had also supported going with Option 1 for DS-MIP6. >> Of course that matters, Vidya, but the more important thing here >> is that it's pretty clear to me that there is *no* rough consensus >> present. >> >> Please don't manufacture one when there isn't one; if there >> really isn't one, do another call for discussion and/or show >> of hands, and if the group is deadlocked, use 3929. >> >> I can't accept this pronouncement of a consensus, rough or not, >> in the group, neither from my observation of the discussion or >> from the count. >> >> >> Henrik >> >> >>> Vidya >>> >>>> -----Original Message----- >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>>> Sent: Friday, June 01, 2007 2:36 PM >>>> To: Levkowetz >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 >>>> - Consensus call to close issue 93 >>>> >>>> >>>> >>>> Vijay D. - Option 4 originally and then changed to Option 2 >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 >>>> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - >>>> Option 1 (Interpreted) >>>> >>>> So we have a sort of a tie if you strictly go by count. >>>> If I were to express my own opinion (non-chair-hat), I would >>>> go with option 1 as well for the current DS-MIP6 proposal >>>> (aligned with my earlier email that if and when GRE is >>>> planned for use, another UDP port can be reserved... But for >>>> now option 1). That would break any deadlock issues. >>>> >>>> Or the other way is to let the chairs decide what is the >>>> sense of the discussion on the ML and from the perspective of >>>> the charter/scope and urgency of this protocol. And from this >>>> angle as well, I would stick by my conclusion, i.e option 1. >>>> >>>> -Raj >>>> >>>> >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" >>>> wrote: >>>> >>>>> Hi Raj, >>>>> >>>>> On 2007-06-01 21:46 Basavaraj Patil said the following: >>>>>> So after an extensive discussion on this topic which spun >>>> off into a >>>>>> discussion about the need/use for GRE, I would like to >> summarize >>>>>> where we are with the options that we have. >>>>>> >>>>>> Conclusion was that for DS-MIP6, Option 1 which is : " >> Parse the >>>>>> protocol header following the UDP header" is good enough. >>>>> Could you give us an indication of who preferred which >> option? You >>>>> seem to be very clear about the outcome, while it was far >>>> from obvious >>>>> to me that the counts turned out to support above conclusion... >>>>> >>>>> >>>>> Henrik >>>>> >>>>>> So it implies no changes to the current text in the >>>> DS-MIP6 I-D w.r.t >>>>>> this issue are needed. >>>>>> >>>>>> >>>>>> It was pointed out that in the future if GRE was >> determined as a >>>>>> protocol that needs to be supported as well either for >>>> MIP6, NEMO or >>>>>> PMIP6 then it would be specified in the appropriate WG and >>>> a UDP port >>>>>> reserved for the same. In such a case it would >> essentially be the >>>>>> equivalent of option 2 in the choices list (below). >>>>>> >>>>>> At this time, the need for GRE especially in the scope >> of DS-MIP6 >>>>>> which is primarily MIP6 and NEMO is not proven. Hence >> we will move >>>>>> forward with Option 1 and close this issue. >>>>>> >>>>>> -Raj >>>>>> >>>>>> >>>>>> >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" >>>> wrote: >>>>>>> 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 Sat Jun 02 07:04: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 1HuRPh-0006lP-JC; Sat, 02 Jun 2007 07:04:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuRPf-0006V0-IF; Sat, 02 Jun 2007 07:04:51 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuRPe-00047f-Mr; Sat, 02 Jun 2007 07:04:51 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070602110447.UJUG25724.omta05sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Sat, 2 Jun 2007 11:04:47 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta07sl.mx.bigpond.com with ESMTP id <20070602110447.WQAP4756.oaamta07sl.mx.bigpond.com@PC20005>; Sat, 2 Jun 2007 11:04:47 +0000 From: "Hesham Soliman" To: "'Henrik Levkowetz'" Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensuscall to close issue 93 Date: Sat, 2 Jun 2007 21:04:42 +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: <4661435A.2040505@levkowetz.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acek/wdV5Mb77tH2Swi5l/2MLoVHTgABj9NA Message-Id: <20070602110447.WQAP4756.oaamta07sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 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 > No, I'm not looking for a vote. I'm looking for consensus on how to > handle the issue. And I don't see any consensus on how to handle the > issue here. => The issue was raised against an existing solution, if there is no support in the WG (6 people against and 5 for it) then clearly there is no agreement that there is an issue to begin with. What are you suggesting we do? If there is no support for the perceived issue then naturally it's rejected. I don't think anyone is changing their mind if we ask the same question again in the space of two weeks... If a 6:5 or 5:4 means no concensus to you, then I'm surprised that you accepted the same numbers as concensus on other issues, like the mapped address one or issue 93. Should we repeat all those questions again? Hesham > > > Henrik > > > We've always asked for concencus to > > change anything > > in the draft. The numbers that Raj sent clearly indicate > that there is no > > concensus to change the draft. 5:4 is not concensus. > Therefore, I think > > Raj's decision is correct. I hope we don't turn the IETF > into a voting > > organisation, if we do then the whole process of providing > a vote would be > > different from what we do today. > > > > Hesham > > > >> -----Original Message----- > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > >> Sent: Saturday, June 02, 2007 9:28 AM > >> To: Narayanan, Vidya > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Basavaraj Patil > >> Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: > >> DS-MIP6 - Consensuscall to close issue 93 > >> > >> Hi Vidya, Rai, > >> > >> On 2007-06-02 00:13 Narayanan, Vidya said the following: > >>> FWIW, I had also supported going with Option 1 for DS-MIP6. > >> Of course that matters, Vidya, but the more important thing here > >> is that it's pretty clear to me that there is *no* rough consensus > >> present. > >> > >> Please don't manufacture one when there isn't one; if there > >> really isn't one, do another call for discussion and/or show > >> of hands, and if the group is deadlocked, use 3929. > >> > >> I can't accept this pronouncement of a consensus, rough or not, > >> in the group, neither from my observation of the discussion or > >> from the count. > >> > >> > >> Henrik > >> > >> > >>> Vidya > >>> > >>>> -----Original Message----- > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >>>> Sent: Friday, June 01, 2007 2:36 PM > >>>> To: Levkowetz > >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List > >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 > >>>> - Consensus call to close issue 93 > >>>> > >>>> > >>>> > >>>> Vijay D. - Option 4 originally and then changed to Option 2 > >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 > >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 > >>>> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 > >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - > >>>> Option 1 (Interpreted) > >>>> > >>>> So we have a sort of a tie if you strictly go by count. > >>>> If I were to express my own opinion (non-chair-hat), I would > >>>> go with option 1 as well for the current DS-MIP6 proposal > >>>> (aligned with my earlier email that if and when GRE is > >>>> planned for use, another UDP port can be reserved... But for > >>>> now option 1). That would break any deadlock issues. > >>>> > >>>> Or the other way is to let the chairs decide what is the > >>>> sense of the discussion on the ML and from the perspective of > >>>> the charter/scope and urgency of this protocol. And from this > >>>> angle as well, I would stick by my conclusion, i.e option 1. > >>>> > >>>> -Raj > >>>> > >>>> > >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" > >>>> wrote: > >>>> > >>>>> Hi Raj, > >>>>> > >>>>> On 2007-06-01 21:46 Basavaraj Patil said the following: > >>>>>> So after an extensive discussion on this topic which spun > >>>> off into a > >>>>>> discussion about the need/use for GRE, I would like to > >> summarize > >>>>>> where we are with the options that we have. > >>>>>> > >>>>>> Conclusion was that for DS-MIP6, Option 1 which is : " > >> Parse the > >>>>>> protocol header following the UDP header" is good enough. > >>>>> Could you give us an indication of who preferred which > >> option? You > >>>>> seem to be very clear about the outcome, while it was far > >>>> from obvious > >>>>> to me that the counts turned out to support above conclusion... > >>>>> > >>>>> > >>>>> Henrik > >>>>> > >>>>>> So it implies no changes to the current text in the > >>>> DS-MIP6 I-D w.r.t > >>>>>> this issue are needed. > >>>>>> > >>>>>> > >>>>>> It was pointed out that in the future if GRE was > >> determined as a > >>>>>> protocol that needs to be supported as well either for > >>>> MIP6, NEMO or > >>>>>> PMIP6 then it would be specified in the appropriate WG and > >>>> a UDP port > >>>>>> reserved for the same. In such a case it would > >> essentially be the > >>>>>> equivalent of option 2 in the choices list (below). > >>>>>> > >>>>>> At this time, the need for GRE especially in the scope > >> of DS-MIP6 > >>>>>> which is primarily MIP6 and NEMO is not proven. Hence > >> we will move > >>>>>> forward with Option 1 and close this issue. > >>>>>> > >>>>>> -Raj > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" > >>>> wrote: > >>>>>>> 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 Sat Jun 02 08:56: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 1HuT9g-0001Ws-KY; Sat, 02 Jun 2007 08:56:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuT9f-0001We-RV; Sat, 02 Jun 2007 08:56: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 1HuT9d-0002V2-Kq; Sat, 02 Jun 2007 08:56:27 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HuT9a-0005rO-TV; Sat, 02 Jun 2007 14:56:22 +0200 Message-ID: <466168F4.6030006@levkowetz.com> Date: Sat, 02 Jun 2007 14:56:20 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensuscall to close issue 93 References: <20070602110447.WQAP4756.oaamta07sl.mx.bigpond.com@PC20005> In-Reply-To: <20070602110447.WQAP4756.oaamta07sl.mx.bigpond.com@PC20005> X-Enigmail-Version: 0.95.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Hesham@elevatemobile.com, nemo@ietf.org, mip6@ietf.org, basavaraj.patil@nsn.com, jari.arkko@piuha.net, 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: e8a67952aa972b528dd04570d58ad8fe 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: , Content-Type: multipart/mixed; boundary="===============0510515746==" Errors-To: mip6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0510515746== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig60DA3BA4127C81A830F7DE97" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig60DA3BA4127C81A830F7DE97 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2007-06-02 13:04 Hesham Soliman said the following: >> No, I'm not looking for a vote. I'm looking for consensus on how to >> handle the issue. And I don't see any consensus on how to handle the >> issue here. >=20 > The issue was raised against an existing solution, if there is no suppo= rt > in the WG (6 people against and 5 for it) then clearly there is no agre= ement > that there is an issue to begin with. I think this is incorrect; that we don't agree on a solution doesn't mean there isn't an issue. But if you want to ask the list if they think this is a non-issue, go right ahead. > What are you suggesting we do? If > there is no support for the perceived issue then naturally it's rejecte= d. I > don't think anyone is changing their mind if we ask the same question a= gain > in the space of two weeks... I saw several people change position during the discussion, which is of course the benefit of having a discussion in the first place -- as various aspects of a question is illuminated, people get a clearer view of the tradeofs, and hopefully align in a rough consensus. > If a 6:5 or 5:4 means no concensus to you, then I'm surprised that you > accepted the same numbers as concensus on other issues, like the mapped= > address one or issue 93. Should we repeat all those questions again?=20 If you have counts of those issues that indicate that there was no consensus (and 6:5 or 5:4 isn't even rough consensus as far as I can tell) then I think that would be the right thing to do. However, my memory of the other discussions isn't that they were as inconclusive as this one. Henrik --------------enig60DA3BA4127C81A830F7DE97 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFGYWj1eVhrtTJkXCMRAsChAJ0RLZkJbDPdwvMbgJhnIdXay+zLpACg03se YAFXrJav4gEmhEQvoBQGnKg= =Qg+R -----END PGP SIGNATURE----- --------------enig60DA3BA4127C81A830F7DE97-- --===============0510515746== 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 --===============0510515746==-- From mip6-bounces@ietf.org Sat Jun 02 09:50: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 1HuTzh-00033P-HG; Sat, 02 Jun 2007 09:50:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuTzf-00032u-FQ; Sat, 02 Jun 2007 09:50:11 -0400 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuTzb-0004Fw-0H; Sat, 02 Jun 2007 09:50:11 -0400 Received: from oaamta02sl.mx.bigpond.com ([124.191.178.123]) by omta02sl.mx.bigpond.com with ESMTP id <20070602135003.CADD10557.omta02sl.mx.bigpond.com@oaamta02sl.mx.bigpond.com>; Sat, 2 Jun 2007 13:50:03 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta02sl.mx.bigpond.com with ESMTP id <20070602135003.TSTQ7229.oaamta02sl.mx.bigpond.com@PC20005>; Sat, 2 Jun 2007 13:50:03 +0000 From: "Hesham Soliman" To: "'Henrik Levkowetz'" Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensuscall to close issue 93 Date: Sat, 2 Jun 2007 23:49: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: <466168F4.6030006@levkowetz.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcelFkpunItFNvAiTm+yh3L/+AxHTwABbZgw Message-Id: <20070602135003.TSTQ7229.oaamta02sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 > > The issue was raised against an existing solution, if > there is no support > > in the WG (6 people against and 5 for it) then clearly > there is no agreement > > that there is an issue to begin with. > > I think this is incorrect; that we don't agree on a solution doesn't > mean there isn't an issue. But if you want to ask the list if they > think this is a non-issue, go right ahead. => We already did that, it's implicit in the question for a choice between keeping things as they are (i.e. it's not an issue that we need to solve) Vs 3 other options (or 2 workable options because option 4 doesn't work). > > I saw several people change position during the discussion, which is > of course the benefit of having a discussion in the first place -- as > various aspects of a question is illuminated, people get a clearer > view of the tradeofs, and hopefully align in a rough consensus. => Several people? I saw one. > > > If a 6:5 or 5:4 means no concensus to you, then I'm > surprised that you > > accepted the same numbers as concensus on other issues, > like the mapped > > address one or issue 93. Should we repeat all those > questions again? > > If you have counts of those issues that indicate that there was no > consensus (and 6:5 or 5:4 isn't even rough consensus as far as I can > tell) then I think that would be the right thing to do. => I agree that 6:5, 5:4 or 4:3 is not a concensus. To me that means there is no concensus to change the draft. Of course the figures for the mapped address were sent to the list, it was 5:4 for the change, you have those figures too. So if we re-open an issue for this reason then we have to be consistent and re-open all issues. However, my > memory of the other discussions isn't that they were as inconclusive > as this one. => You can check Raj's email on the mapped address issue yourself, it was another 5:4. I don't remember the exact number on issue 93. I assume you're not considering that a valid concensus either, we would agree on that. Hesham > > > Henrik > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Jun 02 10:20: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 1HuUSX-0002Re-81; Sat, 02 Jun 2007 10:20:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuUSV-0002RX-1M for mip6@ietf.org; Sat, 02 Jun 2007 10:19:59 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuUSU-0001Kr-K3 for mip6@ietf.org; Sat, 02 Jun 2007 10:19:59 -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 l52EJt307091; Sat, 2 Jun 2007 14:19:55 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: Sat, 2 Jun 2007 09:19:51 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C5B@zrc2hxm2.corp.nortel.com> In-Reply-To: <20070602034813.ZDSI1743.oaamta04sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcejsVbfS40lMgyLQl23peLZkTLpugAFaWnwAAugWzAAAgC4oAAEMlsgAADb+qAAF/QpWgAA+4EwABSW1dAAAvek8A== References: <6FC4416DDE56C44DA0AEE67BC7CA437114A725CF@zrc2hxm2.corp.nortel.com> <20070602034813.ZDSI1743.oaamta04sl.mx.bigpond.com@PC20005> From: "Ahmad Muhanna" To: "Hesham Soliman" , "Basavaraj Patil" , "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 Hesham, Please see comments inline. Regards, Ahmad > > > > Concern No. 3: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > 2. We eliminated the use of the generic notification =20 > > sequence number > > > which may be limited in here. As a=20 > matter of fact, why do we need > that > > > if the new=20 > functionality is going to define all the > needed formats >=20 > and > > > details. > > > > > > You can always overwrite the draft-haley in your document. > > > > [Ahmad] > > Well, my understanding is that we will end up with two >=20 > sequence number > fields, one in the generic notification=20 > message and another in the > revocation message. Is not that=20 > right? If so, why do we need to have > two? >=20 > =3D> Why can't you use the one in draft-haley? This is a=20 > revocation message, it's removing the binding completely, why=20 > does it need its own seq number?=20 [Ahmad] seq. # is used to match the binding revocation ack to the outstanding revocation Indication. The Binding Revocation for IPv6 Mobility draft allows a mobility entity to request a BRA in many cases. Right? >=20 > > > > Concern No. 4: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >> If this messaging mechanism is really generic in the=20 > full sense, > >> how anyone expect that one byte of status=20 > is enough to > address all > >> possible status for all the=20 > possible functionalities that > could ever > >> be=20 > masked/encapsulated using this generic messaging mechanism.=20 > In > >> other words, I believe that the status should be=20 > moved from the=20 >=20 > =3D> I completely disagree with your premise above. I think 255=20 > is plenty. If a specific message needs more than 255 then it=20 [Ahmad] which specific message we are talking about here. Probably I am missing something. > can add its own status. I don't know why you'd need that in this case. >=20 > > >> Generic notification message header to the specific >=20 > message, where it > > >> is more relevant. For example,=20 > what the following status > has to do > >> with revocation=20 > mechanism, for example: "130 Insufficient > resources". >=20 > =3D> You don't *have* to use every generic error code, you can=20 > use/define the ones that are relevant to you. >=20 > Hesham >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Jun 02 10:25: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 1HuUXn-0002yX-3p; Sat, 02 Jun 2007 10:25:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuUXm-0002yR-0l for mip6@ietf.org; Sat, 02 Jun 2007 10:25:26 -0400 Received: from omta03sl.mx.bigpond.com ([144.140.92.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuUXj-00029X-IX for mip6@ietf.org; Sat, 02 Jun 2007 10:25:25 -0400 Received: from oaamta03sl.mx.bigpond.com ([124.191.178.123]) by omta03sl.mx.bigpond.com with ESMTP id <20070602142520.KANN28147.omta03sl.mx.bigpond.com@oaamta03sl.mx.bigpond.com>; Sat, 2 Jun 2007 14:25:20 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta03sl.mx.bigpond.com with ESMTP id <20070602142520.ONHG1809.oaamta03sl.mx.bigpond.com@PC20005>; Sat, 2 Jun 2007 14:25:20 +0000 From: "Hesham Soliman" To: "'Ahmad Muhanna'" , "'Basavaraj Patil'" , "'Brian Haley'" Subject: RE: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Date: Sun, 3 Jun 2007 00:25: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 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C5B@zrc2hxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcejsVbfS40lMgyLQl23peLZkTLpugAFaWnwAAugWzAAAgC4oAAEMlsgAADb+qAAF/QpWgAA+4EwABSW1dAAAvek8AATadSg Message-Id: <20070602142520.ONHG1809.oaamta03sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 > > => Why can't you use the one in draft-haley? This is a > > revocation message, it's removing the binding completely, why > > does it need its own seq number? > > [Ahmad] > seq. # is used to match the binding revocation ack to the outstanding > revocation Indication. The Binding Revocation for IPv6 Mobility draft > allows a mobility entity to request a BRA in many cases. Right? => That's fine but you can use a generic seq no for that. The one in draft-haley. you don't need to define another one in your option. All you need is a number tracked by both sides, it doesn't have to be specific to your option inside the header. > > > > > > > > > Concern No. 4: > > > ============== > > > >> If this messaging mechanism is really generic in the > > full sense, > >> how anyone expect that one byte of status > > is enough to > address all > >> possible status for all the > > possible functionalities that > could ever > >> be > > masked/encapsulated using this generic messaging mechanism. > > In > >> other words, I believe that the status should be > > moved from the > > > > => I completely disagree with your premise above. I think 255 > > is plenty. If a specific message needs more than 255 then it > > [Ahmad] > which specific message we are talking about here. Probably I > am missing > something. => I was responding to the claim that 1 byte of status is not enough. Anyway, even if we do agree that 1 byte is not enough, that's something you can add as a comment on draft-haley. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Jun 02 10:33: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 1HuUfw-0007zM-IO; Sat, 02 Jun 2007 10:33:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuUfv-0007zH-DI for mip6@ietf.org; Sat, 02 Jun 2007 10:33:51 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuUfu-0003iK-5W for mip6@ietf.org; Sat, 02 Jun 2007 10:33:51 -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 l52EXl618609; Sat, 2 Jun 2007 14:33:47 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: Sat, 2 Jun 2007 09:33:42 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C5E@zrc2hxm2.corp.nortel.com> In-Reply-To: <20070602142520.ONHG1809.oaamta03sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcejsVbfS40lMgyLQl23peLZkTLpugAFaWnwAAugWzAAAgC4oAAEMlsgAADb+qAAF/QpWgAA+4EwABSW1dAAAvek8AATadSgAAAjeLA= References: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C5B@zrc2hxm2.corp.nortel.com> <20070602142520.ONHG1809.oaamta03sl.mx.bigpond.com@PC20005> From: "Ahmad Muhanna" To: "Hesham Soliman" , "Basavaraj Patil" , "Brian Haley" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 Hesham, Please see comment inline. Regards, Ahmad >=20 > > > =3D> Why can't you use the one in draft-haley? This is a =20 > > > revocation message, it's removing the binding completely,=20 > why > > does it need its own seq number?=20 > > > > [Ahmad] > > seq. # is used to match the binding revocation ack to the=20 > outstanding > revocation Indication. The Binding Revocation=20 > for IPv6 Mobility draft > allows a mobility entity to=20 > request a BRA in many cases. Right? >=20 > =3D> That's fine but you can use a generic seq no for that. The=20 > one in draft-haley. > you don't need to define another one in your option. All you=20 > need is a number tracked by both sides, it doesn't have to be=20 > specific to your option inside the header. >=20 > > > > > > > > > > > > > Concern No. 4: > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > >> If this messaging mechanism is really generic in=20 > the > > full sense, > >> how anyone expect that one byte of=20 > status > > is enough to > address all > >> possible status=20 > for all the > > possible functionalities that > could ever =20 > > >> be > > masked/encapsulated using this generic messaging=20 > mechanism.=20 > > > In > >> other words, I believe that the status should=20 > be > > moved from the > > > > =3D> I completely disagree=20 > with your premise above. I think 255 > > is plenty. If a=20 > specific message needs more than 255 then it > > [Ahmad] >=20 > which specific message we are talking about here. Probably I =20 > > am missing > something. >=20 > =3D> I was responding to the claim that 1 byte of status is not = enough. > Anyway, even if we do agree that 1 byte is not enough, that's=20 > something you can add as a comment on draft-haley. [Ahmad] That is good. I already proposed a slight modification to the generic container mechanism introduced by draft-haley on a different thread, could you please take a look when you have a chance. Many thanks. >=20 > Hesham >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Jun 02 14:31: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 1HuYNb-0007Wm-Is; Sat, 02 Jun 2007 14:31:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuYNa-0007We-GF; Sat, 02 Jun 2007 14:31:10 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuYNZ-0004yQ-Mj; Sat, 02 Jun 2007 14:31:10 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 02 Jun 2007 11:31:09 -0700 X-IronPort-AV: i="4.16,376,1175497200"; d="scan'208"; a="158001314:sNHT62434512" 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 l52IV9FD027924; Sat, 2 Jun 2007 11:31:09 -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 l52IUx20001398; Sat, 2 Jun 2007 18:31:04 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); Sat, 2 Jun 2007 11:30:59 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Jun 2007 11:30:58 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , "'Henrik Levkowetz'" References: <4661435A.2040505@levkowetz.com> <20070602110447.WQAP4756.oaamta07sl.mx.bigpond.com@PC20005> Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 -Consensuscall to close issue 93 Date: Sat, 2 Jun 2007 11:30:58 -0700 Message-ID: <03ad01c7a544$2a3abc40$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: Acek/wdV5Mb77tH2Swi5l/2MLoVHTgABj9NAAA5PM6A= In-Reply-To: <20070602110447.WQAP4756.oaamta07sl.mx.bigpond.com@PC20005> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 02 Jun 2007 18:30:58.0947 (UTC) FILETIME=[2A4E1D30:01C7A544] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10499; t=1180809069; x=1181673069; 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]=20Re=3A=20[nemo]=20Summary=20and=20conclusion= 20of=3A=20DS-MIP6=20-Consensuscall=20to=20close=20issue=2093 |Sender:=20; bh=ZX95+1EJN2ReVbiehUtwKNP51Q+oywffF2Ho65TL8U8=; b=Avc1g8S/IzGLh0nagHrQteLCtnyouanvQudM0GKEIftc7oRNpm4FWlEHjLrLpmgnD+eo6UdV q6ALVufJJWgkcfEo8hsxQJYZkJ9VE79dxzr58cyDwdM8COHXHZ/fr3JQ; 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: 8cb9b411340046bf4080a729180a0672 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 I understand the need to complete the DSMIP6 as early as possible and I appreciate the Chair's position to close this issue soon. I really like to see that as well. I also believe, IMO, that there is a proper justification in asking for Option#3. Its for a simple TLV header, qualifier in UDP for the payload packet. Many reasons, examples, protocol conventions including 3519's way of dealing with the exact same issue, lack of resaved port numbers, opening multiple port numbers if we were to extend it later, and many other reasons were mentioned and against the one solid reason of extra-4 byte overhead. We don't have turn this to a voting machine, if we see the need for this request with certain flexibility. Now, w.r.t the voting, I though Pascal did mention the need for a supporting new encapsulation mode and off course he also wanted this work to close ASAP and that leaves it in a ambiguous vote. And if I interpret Vijay's emails correctly, his preference is for Option#4 and his second preference is for option#3. He can speak up. And, we missed Alessio Casati's preference on this issue, he did support option#3. So with Jouni Korhonen, he did state that "I prefer more future proof extensibility over slight performance hit thus I prefer the 4 bytes header like in 3519". I also interpret Yoshi Tsuda's vote in favour of option#3. If this is not rough consensus, atleast, there is sufficient interest to discuss this issue further and proper conclude. My 2c. Regards Sri > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Saturday, June 02, 2007 4:05 AM > To: 'Henrik Levkowetz' > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: > DS-MIP6 -Consensuscall to close issue 93 > > > > No, I'm not looking for a vote. I'm looking for consensus > on how to > > handle the issue. And I don't see any consensus on how to > handle the > > issue here. > > => The issue was raised against an existing solution, if > there is no support > in the WG (6 people against and 5 for it) then clearly there > is no agreement > that there is an issue to begin with. What are you suggesting > we do? If > there is no support for the perceived issue then naturally > it's rejected. I > don't think anyone is changing their mind if we ask the same > question again > in the space of two weeks... > > If a 6:5 or 5:4 means no concensus to you, then I'm surprised that you > accepted the same numbers as concensus on other issues, like > the mapped > address one or issue 93. Should we repeat all those questions again? > > Hesham > > > > > > > Henrik > > > > > We've always asked for concencus to > > > change anything > > > in the draft. The numbers that Raj sent clearly indicate > > that there is no > > > concensus to change the draft. 5:4 is not concensus. > > Therefore, I think > > > Raj's decision is correct. I hope we don't turn the IETF > > into a voting > > > organisation, if we do then the whole process of providing > > a vote would be > > > different from what we do today. > > > > > > Hesham > > > > > >> -----Original Message----- > > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > >> Sent: Saturday, June 02, 2007 9:28 AM > > >> To: Narayanan, Vidya > > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Basavaraj Patil > > >> Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: > > >> DS-MIP6 - Consensuscall to close issue 93 > > >> > > >> Hi Vidya, Rai, > > >> > > >> On 2007-06-02 00:13 Narayanan, Vidya said the following: > > >>> FWIW, I had also supported going with Option 1 for DS-MIP6. > > >> Of course that matters, Vidya, but the more important thing here > > >> is that it's pretty clear to me that there is *no* > rough consensus > > >> present. > > >> > > >> Please don't manufacture one when there isn't one; if there > > >> really isn't one, do another call for discussion and/or show > > >> of hands, and if the group is deadlocked, use 3929. > > >> > > >> I can't accept this pronouncement of a consensus, rough or not, > > >> in the group, neither from my observation of the discussion or > > >> from the count. > > >> > > >> > > >> Henrik > > >> > > >> > > >>> Vidya > > >>> > > >>>> -----Original Message----- > > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > >>>> Sent: Friday, June 01, 2007 2:36 PM > > >>>> To: Levkowetz > > >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 > > >>>> - Consensus call to close issue 93 > > >>>> > > >>>> > > >>>> > > >>>> Vijay D. - Option 4 originally and then changed to Option 2 > > >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 > > >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 > > >>>> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 > > >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - > > >>>> Option 1 (Interpreted) > > >>>> > > >>>> So we have a sort of a tie if you strictly go by count. > > >>>> If I were to express my own opinion (non-chair-hat), I would > > >>>> go with option 1 as well for the current DS-MIP6 proposal > > >>>> (aligned with my earlier email that if and when GRE is > > >>>> planned for use, another UDP port can be reserved... But for > > >>>> now option 1). That would break any deadlock issues. > > >>>> > > >>>> Or the other way is to let the chairs decide what is the > > >>>> sense of the discussion on the ML and from the perspective of > > >>>> the charter/scope and urgency of this protocol. And from this > > >>>> angle as well, I would stick by my conclusion, i.e option 1. > > >>>> > > >>>> -Raj > > >>>> > > >>>> > > >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" > > >>>> wrote: > > >>>> > > >>>>> Hi Raj, > > >>>>> > > >>>>> On 2007-06-01 21:46 Basavaraj Patil said the following: > > >>>>>> So after an extensive discussion on this topic which spun > > >>>> off into a > > >>>>>> discussion about the need/use for GRE, I would like to > > >> summarize > > >>>>>> where we are with the options that we have. > > >>>>>> > > >>>>>> Conclusion was that for DS-MIP6, Option 1 which is : " > > >> Parse the > > >>>>>> protocol header following the UDP header" is good enough. > > >>>>> Could you give us an indication of who preferred which > > >> option? You > > >>>>> seem to be very clear about the outcome, while it was far > > >>>> from obvious > > >>>>> to me that the counts turned out to support above > conclusion... > > >>>>> > > >>>>> > > >>>>> Henrik > > >>>>> > > >>>>>> So it implies no changes to the current text in the > > >>>> DS-MIP6 I-D w.r.t > > >>>>>> this issue are needed. > > >>>>>> > > >>>>>> > > >>>>>> It was pointed out that in the future if GRE was > > >> determined as a > > >>>>>> protocol that needs to be supported as well either for > > >>>> MIP6, NEMO or > > >>>>>> PMIP6 then it would be specified in the appropriate WG and > > >>>> a UDP port > > >>>>>> reserved for the same. In such a case it would > > >> essentially be the > > >>>>>> equivalent of option 2 in the choices list (below). > > >>>>>> > > >>>>>> At this time, the need for GRE especially in the scope > > >> of DS-MIP6 > > >>>>>> which is primarily MIP6 and NEMO is not proven. Hence > > >> we will move > > >>>>>> forward with Option 1 and close this issue. > > >>>>>> > > >>>>>> -Raj > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" > > >>>> wrote: > > >>>>>>> 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 Jun 02 18:30: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 1Huc7I-000468-EY; Sat, 02 Jun 2007 18:30:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huc7G-00045u-7y; Sat, 02 Jun 2007 18:30:34 -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 1Huc7E-0000zK-F6; Sat, 02 Jun 2007 18:30:34 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1Huc7B-0003sI-Ka; Sun, 03 Jun 2007 00:30:29 +0200 Message-ID: <4661EF82.90605@levkowetz.com> Date: Sun, 03 Jun 2007 00:30:26 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensuscall to close issue 93 References: <20070602135003.TSTQ7229.oaamta02sl.mx.bigpond.com@PC20005> In-Reply-To: <20070602135003.TSTQ7229.oaamta02sl.mx.bigpond.com@PC20005> X-Enigmail-Version: 0.95.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Hesham@elevatemobile.com, nemo@ietf.org, mip6@ietf.org, basavaraj.patil@nsn.com, jari.arkko@piuha.net, 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: 9a2be21919e71dc6faef12b370c4ecf5 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: , Content-Type: multipart/mixed; boundary="===============1258820380==" Errors-To: mip6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1258820380== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBD4DC49EE93C846EF069B92D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBD4DC49EE93C846EF069B92D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2007-06-02 15:49 Hesham Soliman said the following: >>> The issue was raised against an existing solution, if=20 >> there is no support >>> in the WG (6 people against and 5 for it) then clearly=20 >> there is no agreement >>> that there is an issue to begin with. >> I think this is incorrect; that we don't agree on a solution doesn't >> mean there isn't an issue. But if you want to ask the list if they >> think this is a non-issue, go right ahead. >=20 > We already did that, it's implicit in the question for a choice between= > keeping things as they are (i.e. it's not an issue that we need to solv= e) Vs > 3 other options (or 2 workable options because option 4 doesn't work). I think here we have a fundamental disagrement. If I understand your reasoning right, then you are saying that in a case when the WG doesn't have consensus on an issue, whatever is written in a document is going to be the resolution. I'm saying that if the working group doesn't have consensus on an issue, it doesn't matter what the document says; the document cannot go forward with either of the discussed solutions if the WG doesn't have rough consensus for one of them. Maybe you're focussing more on what is going to be changed in the document right now, rather on closing the issue; while I'm focussing on resolving the issue, and the text of the document at the point when it can be sent for publication, rather than focussing on what happens to the document text right now? >> I saw several people change position during the discussion, which is >> of course the benefit of having a discussion in the first place -- as >> various aspects of a question is illuminated, people get a clearer >> view of the tradeofs, and hopefully align in a rough consensus. >=20 > Several people? I saw one. And I saw several. Does arguing about this lead anywhere? >>> If a 6:5 or 5:4 means no concensus to you, then I'm=20 >> surprised that you >>> accepted the same numbers as concensus on other issues,=20 >> like the mapped >>> address one or issue 93. Should we repeat all those=20 >> questions again?=20 >> >> If you have counts of those issues that indicate that there was no >> consensus (and 6:5 or 5:4 isn't even rough consensus as far as I can >> tell) then I think that would be the right thing to do. =20 >=20 > I agree that 6:5, 5:4 or 4:3 is not a concensus. To me that means there= > is no concensus to change the draft. Of course the figures for the mapp= ed > address were sent to the list, it was 5:4 for the change, you have thos= e > figures too. So if we re-open an issue for this reason then we have to = be > consistent and re-open all issues.=20 >=20 > However, my >> memory of the other discussions isn't that they were as inconclusive >> as this one. >=20 > You can check Raj's email on the mapped address issue yourself, it was > another 5:4. I don't remember the exact number on issue 93. I assume yo= u're > not considering that a valid concensus either, we would agree on that. >=20 > Hesham >=20 >=20 >=20 >> >> Henrik >> >> >> >=20 >=20 >=20 --------------enigBD4DC49EE93C846EF069B92D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFGYe+DeVhrtTJkXCMRAtpvAJ4xVKO0JM+Syataeg/jzYRGnE50fQCfWdQh J9DwnPJs15VIYKhgfFKJrlo= =AjRj -----END PGP SIGNATURE----- --------------enigBD4DC49EE93C846EF069B92D-- --===============1258820380== 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 --===============1258820380==-- From mip6-bounces@ietf.org Sat Jun 02 18:47: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 1HucNG-0004rR-C5; Sat, 02 Jun 2007 18:47:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HucNE-0004qv-W2; Sat, 02 Jun 2007 18:47:04 -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 1HucND-000506-69; Sat, 02 Jun 2007 18:47:04 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HucNB-0004Wm-1G; Sun, 03 Jun 2007 00:47:01 +0200 Message-ID: <4661F364.9000200@levkowetz.com> Date: Sun, 03 Jun 2007 00:47:00 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 -Consensuscall to close issue 93 References: <4661435A.2040505@levkowetz.com> <20070602110447.WQAP4756.oaamta07sl.mx.bigpond.com@PC20005> <03ad01c7a544$2a3abc40$d4f6200a@amer.cisco.com> In-Reply-To: <03ad01c7a544$2a3abc40$d4f6200a@amer.cisco.com> X-Enigmail-Version: 0.95.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: sgundave@cisco.com, nemo@ietf.org, 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: fe105289edd72640d9f392da880eefa2 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-06-02 20:30 Sri Gundavelli said the following: ... > Now, w.r.t the voting, I though Pascal did mention the need > for a supporting new encapsulation mode and off course he > also wanted this work to close ASAP and that leaves it in > a ambiguous vote. And if I interpret Vijay's emails correctly, > his preference is for Option#4 and his second preference is > for option#3. He can speak up. And, we missed Alessio Casati's > preference on this issue, he did support option#3. So with > Jouni Korhonen, he did state that "I prefer more future proof > extensibility over slight performance hit thus I prefer the > 4 bytes header like in 3519". I also interpret Yoshi Tsuda's > vote in favour of option#3. So if I count this correctly, we have Option 3 9 counts (+ Vijay's 2nd pref) Option 1 5 counts Option 2 2 counts Option 4 1 count > If this is not rough consensus, atleast, there is sufficient > interest to discuss this issue further and proper conclude. I agree. Henrik > My 2c. > > Regards > Sri > > > > >> -----Original Message----- >> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >> Sent: Saturday, June 02, 2007 4:05 AM >> To: 'Henrik Levkowetz' >> Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' >> Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: >> DS-MIP6 -Consensuscall to close issue 93 >> >> >> > No, I'm not looking for a vote. I'm looking for consensus >> on how to >> > handle the issue. And I don't see any consensus on how to >> handle the >> > issue here. >> >> => The issue was raised against an existing solution, if >> there is no support >> in the WG (6 people against and 5 for it) then clearly there >> is no agreement >> that there is an issue to begin with. What are you suggesting >> we do? If >> there is no support for the perceived issue then naturally >> it's rejected. I >> don't think anyone is changing their mind if we ask the same >> question again >> in the space of two weeks... >> >> If a 6:5 or 5:4 means no concensus to you, then I'm surprised that you >> accepted the same numbers as concensus on other issues, like >> the mapped >> address one or issue 93. Should we repeat all those questions again? >> >> Hesham >> >> > >> > >> > Henrik >> > >> > > We've always asked for concencus to >> > > change anything >> > > in the draft. The numbers that Raj sent clearly indicate >> > that there is no >> > > concensus to change the draft. 5:4 is not concensus. >> > Therefore, I think >> > > Raj's decision is correct. I hope we don't turn the IETF >> > into a voting >> > > organisation, if we do then the whole process of providing >> > a vote would be >> > > different from what we do today. >> > > >> > > Hesham >> > > >> > >> -----Original Message----- >> > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >> > >> Sent: Saturday, June 02, 2007 9:28 AM >> > >> To: Narayanan, Vidya >> > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Basavaraj Patil >> > >> Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: >> > >> DS-MIP6 - Consensuscall to close issue 93 >> > >> >> > >> Hi Vidya, Rai, >> > >> >> > >> On 2007-06-02 00:13 Narayanan, Vidya said the following: >> > >>> FWIW, I had also supported going with Option 1 for DS-MIP6. >> > >> Of course that matters, Vidya, but the more important thing here >> > >> is that it's pretty clear to me that there is *no* >> rough consensus >> > >> present. >> > >> >> > >> Please don't manufacture one when there isn't one; if there >> > >> really isn't one, do another call for discussion and/or show >> > >> of hands, and if the group is deadlocked, use 3929. >> > >> >> > >> I can't accept this pronouncement of a consensus, rough or not, >> > >> in the group, neither from my observation of the discussion or >> > >> from the count. >> > >> >> > >> >> > >> Henrik >> > >> >> > >> >> > >>> Vidya >> > >>> >> > >>>> -----Original Message----- >> > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> > >>>> Sent: Friday, June 01, 2007 2:36 PM >> > >>>> To: Levkowetz >> > >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List >> > >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 >> > >>>> - Consensus call to close issue 93 >> > >>>> >> > >>>> >> > >>>> >> > >>>> Vijay D. - Option 4 originally and then changed to Option 2 >> > >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 >> > >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 >> > >>>> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 >> > >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - >> > >>>> Option 1 (Interpreted) >> > >>>> >> > >>>> So we have a sort of a tie if you strictly go by count. >> > >>>> If I were to express my own opinion (non-chair-hat), I would >> > >>>> go with option 1 as well for the current DS-MIP6 proposal >> > >>>> (aligned with my earlier email that if and when GRE is >> > >>>> planned for use, another UDP port can be reserved... But for >> > >>>> now option 1). That would break any deadlock issues. >> > >>>> >> > >>>> Or the other way is to let the chairs decide what is the >> > >>>> sense of the discussion on the ML and from the perspective of >> > >>>> the charter/scope and urgency of this protocol. And from this >> > >>>> angle as well, I would stick by my conclusion, i.e option 1. >> > >>>> >> > >>>> -Raj >> > >>>> >> > >>>> >> > >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" >> > >>>> wrote: >> > >>>> >> > >>>>> Hi Raj, >> > >>>>> >> > >>>>> On 2007-06-01 21:46 Basavaraj Patil said the following: >> > >>>>>> So after an extensive discussion on this topic which spun >> > >>>> off into a >> > >>>>>> discussion about the need/use for GRE, I would like to >> > >> summarize >> > >>>>>> where we are with the options that we have. >> > >>>>>> >> > >>>>>> Conclusion was that for DS-MIP6, Option 1 which is : " >> > >> Parse the >> > >>>>>> protocol header following the UDP header" is good enough. >> > >>>>> Could you give us an indication of who preferred which >> > >> option? You >> > >>>>> seem to be very clear about the outcome, while it was far >> > >>>> from obvious >> > >>>>> to me that the counts turned out to support above >> conclusion... >> > >>>>> >> > >>>>> >> > >>>>> Henrik >> > >>>>> >> > >>>>>> So it implies no changes to the current text in the >> > >>>> DS-MIP6 I-D w.r.t >> > >>>>>> this issue are needed. >> > >>>>>> >> > >>>>>> >> > >>>>>> It was pointed out that in the future if GRE was >> > >> determined as a >> > >>>>>> protocol that needs to be supported as well either for >> > >>>> MIP6, NEMO or >> > >>>>>> PMIP6 then it would be specified in the appropriate WG and >> > >>>> a UDP port >> > >>>>>> reserved for the same. In such a case it would >> > >> essentially be the >> > >>>>>> equivalent of option 2 in the choices list (below). >> > >>>>>> >> > >>>>>> At this time, the need for GRE especially in the scope >> > >> of DS-MIP6 >> > >>>>>> which is primarily MIP6 and NEMO is not proven. Hence >> > >> we will move >> > >>>>>> forward with Option 1 and close this issue. >> > >>>>>> >> > >>>>>> -Raj >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" >> > >>>> wrote: >> > >>>>>>> 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 Sat Jun 02 22:37: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 1HufyG-0004R8-DI; Sat, 02 Jun 2007 22:37:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HufyF-0004R0-GV; Sat, 02 Jun 2007 22:37:31 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HufyE-00008M-IP; Sat, 02 Jun 2007 22:37:31 -0400 Received: from oaamta04sl.mx.bigpond.com ([124.191.178.123]) by omta04sl.mx.bigpond.com with ESMTP id <20070603023727.EALO28583.omta04sl.mx.bigpond.com@oaamta04sl.mx.bigpond.com>; Sun, 3 Jun 2007 02:37:27 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta04sl.mx.bigpond.com with ESMTP id <20070603023726.DFMV1743.oaamta04sl.mx.bigpond.com@PC20005>; Sun, 3 Jun 2007 02:37:26 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , "'Henrik Levkowetz'" Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 -Consensuscall to close issue 93 Date: Sun, 3 Jun 2007 12:37: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 In-Reply-To: <03ad01c7a544$2a3abc40$d4f6200a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acek/wdV5Mb77tH2Swi5l/2MLoVHTgABj9NAAA5PM6AAEj1mkA== Message-Id: <20070603023726.DFMV1743.oaamta04sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b 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, Pascal's email was not sent in private and we don't need an interpretation. He's alive and well and he didn't object to Raj's conclusion. He clearly said that we should let the draft move as is. I believe other people who are also alive and well can speak for themselves if they were misrepresented..... I look forward to people expressing that they were misrepresnted by the chairs. I don't think it's useful for you or Henrik to recount on their behalf. Hesham > I understand the need to complete the DSMIP6 as early as > possible and I appreciate the Chair's position to close > this issue soon. I really like to see that as well. I also > believe, IMO, that there is a proper justification in asking > for Option#3. Its for a simple TLV header, qualifier in UDP > for the payload packet. Many reasons, examples, protocol > conventions including 3519's way of dealing with the exact > same issue, lack of resaved port numbers, opening multiple > port numbers if we were to extend it later, and many other > reasons were mentioned and against the one solid reason of > extra-4 byte overhead. We don't have turn this to a voting > machine, if we see the need for this request with certain > flexibility. > > Now, w.r.t the voting, I though Pascal did mention the need > for a supporting new encapsulation mode and off course he > also wanted this work to close ASAP and that leaves it in > a ambiguous vote. And if I interpret Vijay's emails correctly, > his preference is for Option#4 and his second preference is > for option#3. He can speak up. And, we missed Alessio Casati's > preference on this issue, he did support option#3. So with > Jouni Korhonen, he did state that "I prefer more future proof > extensibility over slight performance hit thus I prefer the > 4 bytes header like in 3519". I also interpret Yoshi Tsuda's > vote in favour of option#3. > > If this is not rough consensus, atleast, there is sufficient > interest to discuss this issue further and proper conclude. > My 2c. > > Regards > Sri > > > > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Saturday, June 02, 2007 4:05 AM > > To: 'Henrik Levkowetz' > > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > > Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: > > DS-MIP6 -Consensuscall to close issue 93 > > > > > > > No, I'm not looking for a vote. I'm looking for consensus > > on how to > > > handle the issue. And I don't see any consensus on how to > > handle the > > > issue here. > > > > => The issue was raised against an existing solution, if > > there is no support > > in the WG (6 people against and 5 for it) then clearly there > > is no agreement > > that there is an issue to begin with. What are you suggesting > > we do? If > > there is no support for the perceived issue then naturally > > it's rejected. I > > don't think anyone is changing their mind if we ask the same > > question again > > in the space of two weeks... > > > > If a 6:5 or 5:4 means no concensus to you, then I'm > surprised that you > > accepted the same numbers as concensus on other issues, like > > the mapped > > address one or issue 93. Should we repeat all those > questions again? > > > > Hesham > > > > > > > > > > > Henrik > > > > > > > We've always asked for concencus to > > > > change anything > > > > in the draft. The numbers that Raj sent clearly indicate > > > that there is no > > > > concensus to change the draft. 5:4 is not concensus. > > > Therefore, I think > > > > Raj's decision is correct. I hope we don't turn the IETF > > > into a voting > > > > organisation, if we do then the whole process of providing > > > a vote would be > > > > different from what we do today. > > > > > > > > Hesham > > > > > > > >> -----Original Message----- > > > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > > >> Sent: Saturday, June 02, 2007 9:28 AM > > > >> To: Narayanan, Vidya > > > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Basavaraj Patil > > > >> Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: > > > >> DS-MIP6 - Consensuscall to close issue 93 > > > >> > > > >> Hi Vidya, Rai, > > > >> > > > >> On 2007-06-02 00:13 Narayanan, Vidya said the following: > > > >>> FWIW, I had also supported going with Option 1 for DS-MIP6. > > > >> Of course that matters, Vidya, but the more > important thing here > > > >> is that it's pretty clear to me that there is *no* > > rough consensus > > > >> present. > > > >> > > > >> Please don't manufacture one when there isn't one; if there > > > >> really isn't one, do another call for discussion and/or show > > > >> of hands, and if the group is deadlocked, use 3929. > > > >> > > > >> I can't accept this pronouncement of a consensus, > rough or not, > > > >> in the group, neither from my observation of the > discussion or > > > >> from the count. > > > >> > > > >> > > > >> Henrik > > > >> > > > >> > > > >>> Vidya > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > >>>> Sent: Friday, June 01, 2007 2:36 PM > > > >>>> To: Levkowetz > > > >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > > >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion > of: DS-MIP6 > > > >>>> - Consensus call to close issue 93 > > > >>>> > > > >>>> > > > >>>> > > > >>>> Vijay D. - Option 4 originally and then changed to > Option 2 > > > >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - > Option 3 > > > >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 > > > >>>> (Interpreted) George T. - Option 1 Mohamed Khalil > - Option 3 > > > >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - > > > >>>> Option 1 (Interpreted) > > > >>>> > > > >>>> So we have a sort of a tie if you strictly go by count. > > > >>>> If I were to express my own opinion > (non-chair-hat), I would > > > >>>> go with option 1 as well for the current DS-MIP6 proposal > > > >>>> (aligned with my earlier email that if and when GRE is > > > >>>> planned for use, another UDP port can be > reserved... But for > > > >>>> now option 1). That would break any deadlock issues. > > > >>>> > > > >>>> Or the other way is to let the chairs decide what is the > > > >>>> sense of the discussion on the ML and from the > perspective of > > > >>>> the charter/scope and urgency of this protocol. > And from this > > > >>>> angle as well, I would stick by my conclusion, i.e > option 1. > > > >>>> > > > >>>> -Raj > > > >>>> > > > >>>> > > > >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" > > > >>>> wrote: > > > >>>> > > > >>>>> Hi Raj, > > > >>>>> > > > >>>>> On 2007-06-01 21:46 Basavaraj Patil said the following: > > > >>>>>> So after an extensive discussion on this topic > which spun > > > >>>> off into a > > > >>>>>> discussion about the need/use for GRE, I would like to > > > >> summarize > > > >>>>>> where we are with the options that we have. > > > >>>>>> > > > >>>>>> Conclusion was that for DS-MIP6, Option 1 which is : " > > > >> Parse the > > > >>>>>> protocol header following the UDP header" is good enough. > > > >>>>> Could you give us an indication of who preferred which > > > >> option? You > > > >>>>> seem to be very clear about the outcome, while it was far > > > >>>> from obvious > > > >>>>> to me that the counts turned out to support above > > conclusion... > > > >>>>> > > > >>>>> > > > >>>>> Henrik > > > >>>>> > > > >>>>>> So it implies no changes to the current text in the > > > >>>> DS-MIP6 I-D w.r.t > > > >>>>>> this issue are needed. > > > >>>>>> > > > >>>>>> > > > >>>>>> It was pointed out that in the future if GRE was > > > >> determined as a > > > >>>>>> protocol that needs to be supported as well either for > > > >>>> MIP6, NEMO or > > > >>>>>> PMIP6 then it would be specified in the > appropriate WG and > > > >>>> a UDP port > > > >>>>>> reserved for the same. In such a case it would > > > >> essentially be the > > > >>>>>> equivalent of option 2 in the choices list (below). > > > >>>>>> > > > >>>>>> At this time, the need for GRE especially in the scope > > > >> of DS-MIP6 > > > >>>>>> which is primarily MIP6 and NEMO is not proven. Hence > > > >> we will move > > > >>>>>> forward with Option 1 and close this issue. > > > >>>>>> > > > >>>>>> -Raj > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" > > > >>>> wrote: > > > >>>>>>> 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 Jun 02 22:39: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 1Hug0J-0004jQ-RR; Sat, 02 Jun 2007 22:39:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hug0I-0004jH-GH; Sat, 02 Jun 2007 22:39:38 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hug0I-0000Au-1S; Sat, 02 Jun 2007 22:39:38 -0400 Received: from oaamta01sl.mx.bigpond.com ([124.191.178.123]) by omta01sl.mx.bigpond.com with ESMTP id <20070603023931.HJFZ14178.omta01sl.mx.bigpond.com@oaamta01sl.mx.bigpond.com>; Sun, 3 Jun 2007 02:39:31 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta01sl.mx.bigpond.com with ESMTP id <20070603023927.EBSR5805.oaamta01sl.mx.bigpond.com@PC20005>; Sun, 3 Jun 2007 02:39:27 +0000 From: "Hesham Soliman" To: "'Henrik Levkowetz'" Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensuscall to close issue 93 Date: Sun, 3 Jun 2007 12:39:22 +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: <4661EF82.90605@levkowetz.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcelZaMZ1GjnMAPeR8CP2YMuCQnO2wAIoR4Q Message-Id: <20070603023927.EBSR5805.oaamta01sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 Henrik, Like I said, if you want to go by your interepretation then I'll ask the chairs to reopen the other issues. I won't accept selectivity on where to apply those rules. I'll wait for the chairs/AD's decision on this. Hesham > > We already did that, it's implicit in the question for a > choice between > > keeping things as they are (i.e. it's not an issue that we > need to solve) Vs > > 3 other options (or 2 workable options because option 4 > doesn't work). > > I think here we have a fundamental disagrement. > > If I understand your reasoning right, then you are saying that in a > case when the WG doesn't have consensus on an issue, whatever is > written in a document is going to be the resolution. > > I'm saying that if the working group doesn't have consensus > on an issue, > it doesn't matter what the document says; the document > cannot go forward > with either of the discussed solutions if the WG doesn't have rough > consensus for one of them. > > Maybe you're focussing more on what is going to be changed in the > document right now, rather on closing the issue; while I'm > focussing on > resolving the issue, and the text of the document at the > point when it > can be sent for publication, rather than focussing on what happens to > the document text right now? > > >> I saw several people change position during the > discussion, which is > >> of course the benefit of having a discussion in the first > place -- as > >> various aspects of a question is illuminated, people get a clearer > >> view of the tradeofs, and hopefully align in a rough consensus. > > > > Several people? I saw one. > > And I saw several. Does arguing about this lead anywhere? > > >>> If a 6:5 or 5:4 means no concensus to you, then I'm > >> surprised that you > >>> accepted the same numbers as concensus on other issues, > >> like the mapped > >>> address one or issue 93. Should we repeat all those > >> questions again? > >> > >> If you have counts of those issues that indicate that there was no > >> consensus (and 6:5 or 5:4 isn't even rough consensus as > far as I can > >> tell) then I think that would be the right thing to do. > > > > I agree that 6:5, 5:4 or 4:3 is not a concensus. To me > that means there > > is no concensus to change the draft. Of course the figures > for the mapped > > address were sent to the list, it was 5:4 for the change, > you have those > > figures too. So if we re-open an issue for this reason > then we have to be > > consistent and re-open all issues. > > > > However, my > >> memory of the other discussions isn't that they were as > inconclusive > >> as this one. > > > > You can check Raj's email on the mapped address issue > yourself, it was > > another 5:4. I don't remember the exact number on issue > 93. I assume you're > > not considering that a valid concensus either, we would > agree on that. > > > > Hesham > > > > > > > >> > >> Henrik > >> > >> > >> > > > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jun 03 01:33: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 1Huiir-0008HA-E9; Sun, 03 Jun 2007 01:33:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huiiq-0008Gz-3C; Sun, 03 Jun 2007 01:33:48 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Huiip-0006x0-83; Sun, 03 Jun 2007 01:33:48 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 02 Jun 2007 22:33:42 -0700 X-IronPort-AV: i="4.16,377,1175497200"; d="scan'208"; a="158088286:sNHT74196198" 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 l535XgMa005748; Sat, 2 Jun 2007 22:33:42 -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 l535XgaI024812; Sun, 3 Jun 2007 05:33: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); Sat, 2 Jun 2007 22:33:41 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Jun 2007 22:33:40 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , "'Henrik Levkowetz'" References: <03ad01c7a544$2a3abc40$d4f6200a@amer.cisco.com> <20070603023726.DFMV1743.oaamta04sl.mx.bigpond.com@PC20005> Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6-Consensuscall to close issue 93 Date: Sat, 2 Jun 2007 22:33:39 -0700 Message-ID: <03d301c7a5a0$bddc4bb0$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: Acek/wdV5Mb77tH2Swi5l/2MLoVHTgABj9NAAA5PM6AAEj1mkAAGMOxQ In-Reply-To: <20070603023726.DFMV1743.oaamta04sl.mx.bigpond.com@PC20005> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 03 Jun 2007 05:33:41.0019 (UTC) FILETIME=[BE58CEB0:01C7A5A0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13357; t=1180848822; x=1181712822; 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]=20Re=3A=20[nemo]=20Summary=20and=20conclusion= 20of=3A=20DS-MIP6-Consensuscall=20to=20close=20issue=2093 |Sender:=20; bh=jNJQLgPTRGT/UU9rID0tre1ZyUs1sqPVxLDvEfzs8Io=; b=Am0+ykkaknRAeX1R/lQfIMnXE2ay/N32/GkQC2FTLCgOpj0sGfBMnsi5PRXQV4jfrJnqeo6E nKvfY13jPgPZwt5Ch2CQ+d1wxsXxCcXK6TQ2Aviwhn3FqEtV0zq7aRc1; 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: 73f7847c44628482de9d5f1018acf469 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, Fine. Let them speak out. I will just say, there is sufficient interest to close this issue properly. Rest, I will leave it to the chairs and to the authors of this draft to ensure the draft reflects the WG consensus, in the right spirit. Regards Sri > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Saturday, June 02, 2007 7:37 PM > To: 'Sri Gundavelli'; 'Henrik Levkowetz' > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: > DS-MIP6-Consensuscall to close issue 93 > > Sri, > > Pascal's email was not sent in private and we don't need an > interpretation. > He's alive and well and he didn't object to Raj's conclusion. > He clearly > said that we should let the draft move as is. I believe other > people who are > also alive and well can speak for themselves if they were > misrepresented..... > > I look forward to people expressing that they were > misrepresnted by the > chairs. I don't think it's useful for you or Henrik to > recount on their > behalf. > > Hesham > > > I understand the need to complete the DSMIP6 as early as > > possible and I appreciate the Chair's position to close > > this issue soon. I really like to see that as well. I also > > believe, IMO, that there is a proper justification in asking > > for Option#3. Its for a simple TLV header, qualifier in UDP > > for the payload packet. Many reasons, examples, protocol > > conventions including 3519's way of dealing with the exact > > same issue, lack of resaved port numbers, opening multiple > > port numbers if we were to extend it later, and many other > > reasons were mentioned and against the one solid reason of > > extra-4 byte overhead. We don't have turn this to a voting > > machine, if we see the need for this request with certain > > flexibility. > > > > Now, w.r.t the voting, I though Pascal did mention the need > > for a supporting new encapsulation mode and off course he > > also wanted this work to close ASAP and that leaves it in > > a ambiguous vote. And if I interpret Vijay's emails correctly, > > his preference is for Option#4 and his second preference is > > for option#3. He can speak up. And, we missed Alessio Casati's > > preference on this issue, he did support option#3. So with > > Jouni Korhonen, he did state that "I prefer more future proof > > extensibility over slight performance hit thus I prefer the > > 4 bytes header like in 3519". I also interpret Yoshi Tsuda's > > vote in favour of option#3. > > > > If this is not rough consensus, atleast, there is sufficient > > interest to discuss this issue further and proper conclude. > > My 2c. > > > > Regards > > Sri > > > > > > > > > > > -----Original Message----- > > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > > Sent: Saturday, June 02, 2007 4:05 AM > > > To: 'Henrik Levkowetz' > > > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > > > Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: > > > DS-MIP6 -Consensuscall to close issue 93 > > > > > > > > > > No, I'm not looking for a vote. I'm looking for consensus > > > on how to > > > > handle the issue. And I don't see any consensus on how to > > > handle the > > > > issue here. > > > > > > => The issue was raised against an existing solution, if > > > there is no support > > > in the WG (6 people against and 5 for it) then clearly there > > > is no agreement > > > that there is an issue to begin with. What are you suggesting > > > we do? If > > > there is no support for the perceived issue then naturally > > > it's rejected. I > > > don't think anyone is changing their mind if we ask the same > > > question again > > > in the space of two weeks... > > > > > > If a 6:5 or 5:4 means no concensus to you, then I'm > > surprised that you > > > accepted the same numbers as concensus on other issues, like > > > the mapped > > > address one or issue 93. Should we repeat all those > > questions again? > > > > > > Hesham > > > > > > > > > > > > > > > Henrik > > > > > > > > > We've always asked for concencus to > > > > > change anything > > > > > in the draft. The numbers that Raj sent clearly indicate > > > > that there is no > > > > > concensus to change the draft. 5:4 is not concensus. > > > > Therefore, I think > > > > > Raj's decision is correct. I hope we don't turn the IETF > > > > into a voting > > > > > organisation, if we do then the whole process of providing > > > > a vote would be > > > > > different from what we do today. > > > > > > > > > > Hesham > > > > > > > > > >> -----Original Message----- > > > > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > > > >> Sent: Saturday, June 02, 2007 9:28 AM > > > > >> To: Narayanan, Vidya > > > > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; > Basavaraj Patil > > > > >> Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: > > > > >> DS-MIP6 - Consensuscall to close issue 93 > > > > >> > > > > >> Hi Vidya, Rai, > > > > >> > > > > >> On 2007-06-02 00:13 Narayanan, Vidya said the following: > > > > >>> FWIW, I had also supported going with Option 1 > for DS-MIP6. > > > > >> Of course that matters, Vidya, but the more > > important thing here > > > > >> is that it's pretty clear to me that there is *no* > > > rough consensus > > > > >> present. > > > > >> > > > > >> Please don't manufacture one when there isn't one; if there > > > > >> really isn't one, do another call for discussion > and/or show > > > > >> of hands, and if the group is deadlocked, use 3929. > > > > >> > > > > >> I can't accept this pronouncement of a consensus, > > rough or not, > > > > >> in the group, neither from my observation of the > > discussion or > > > > >> from the count. > > > > >> > > > > >> > > > > >> Henrik > > > > >> > > > > >> > > > > >>> Vidya > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > >>>> Sent: Friday, June 01, 2007 2:36 PM > > > > >>>> To: Levkowetz > > > > >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > > > >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion > > of: DS-MIP6 > > > > >>>> - Consensus call to close issue 93 > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> Vijay D. - Option 4 originally and then changed to > > Option 2 > > > > >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - > > Option 3 > > > > >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 > > > > >>>> (Interpreted) George T. - Option 1 Mohamed Khalil > > - Option 3 > > > > >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - > > > > >>>> Option 1 (Interpreted) > > > > >>>> > > > > >>>> So we have a sort of a tie if you strictly go by count. > > > > >>>> If I were to express my own opinion > > (non-chair-hat), I would > > > > >>>> go with option 1 as well for the current DS-MIP6 > proposal > > > > >>>> (aligned with my earlier email that if and when GRE is > > > > >>>> planned for use, another UDP port can be > > reserved... But for > > > > >>>> now option 1). That would break any deadlock issues. > > > > >>>> > > > > >>>> Or the other way is to let the chairs decide what is the > > > > >>>> sense of the discussion on the ML and from the > > perspective of > > > > >>>> the charter/scope and urgency of this protocol. > > And from this > > > > >>>> angle as well, I would stick by my conclusion, i.e > > option 1. > > > > >>>> > > > > >>>> -Raj > > > > >>>> > > > > >>>> > > > > >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" > > > > >>>> wrote: > > > > >>>> > > > > >>>>> Hi Raj, > > > > >>>>> > > > > >>>>> On 2007-06-01 21:46 Basavaraj Patil said the following: > > > > >>>>>> So after an extensive discussion on this topic > > which spun > > > > >>>> off into a > > > > >>>>>> discussion about the need/use for GRE, I would like to > > > > >> summarize > > > > >>>>>> where we are with the options that we have. > > > > >>>>>> > > > > >>>>>> Conclusion was that for DS-MIP6, Option 1 which is : " > > > > >> Parse the > > > > >>>>>> protocol header following the UDP header" is > good enough. > > > > >>>>> Could you give us an indication of who preferred which > > > > >> option? You > > > > >>>>> seem to be very clear about the outcome, while > it was far > > > > >>>> from obvious > > > > >>>>> to me that the counts turned out to support above > > > conclusion... > > > > >>>>> > > > > >>>>> > > > > >>>>> Henrik > > > > >>>>> > > > > >>>>>> So it implies no changes to the current text in the > > > > >>>> DS-MIP6 I-D w.r.t > > > > >>>>>> this issue are needed. > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> It was pointed out that in the future if GRE was > > > > >> determined as a > > > > >>>>>> protocol that needs to be supported as well either for > > > > >>>> MIP6, NEMO or > > > > >>>>>> PMIP6 then it would be specified in the > > appropriate WG and > > > > >>>> a UDP port > > > > >>>>>> reserved for the same. In such a case it would > > > > >> essentially be the > > > > >>>>>> equivalent of option 2 in the choices list (below). > > > > >>>>>> > > > > >>>>>> At this time, the need for GRE especially in the scope > > > > >> of DS-MIP6 > > > > >>>>>> which is primarily MIP6 and NEMO is not proven. Hence > > > > >> we will move > > > > >>>>>> forward with Option 1 and close this issue. > > > > >>>>>> > > > > >>>>>> -Raj > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" > > > > >>>> wrote: > > > > >>>>>>> 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 Sun Jun 03 02:37: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 1HujiU-0005vc-Gy; Sun, 03 Jun 2007 02:37:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HujiT-0005vR-BQ; Sun, 03 Jun 2007 02:37:29 -0400 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HujiS-0002am-Bm; Sun, 03 Jun 2007 02:37:29 -0400 Received: from oaamta02sl.mx.bigpond.com ([124.191.178.123]) by omta02sl.mx.bigpond.com with ESMTP id <20070603063725.JLNX10557.omta02sl.mx.bigpond.com@oaamta02sl.mx.bigpond.com>; Sun, 3 Jun 2007 06:37:25 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta02sl.mx.bigpond.com with ESMTP id <20070603063724.WTKD7229.oaamta02sl.mx.bigpond.com@PC20005>; Sun, 3 Jun 2007 06:37:24 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , "'Henrik Levkowetz'" Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6-Consensuscall to close issue 93 Date: Sun, 3 Jun 2007 16:37:18 +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: <03d301c7a5a0$bddc4bb0$d4f6200a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acek/wdV5Mb77tH2Swi5l/2MLoVHTgABj9NAAA5PM6AAEj1mkAAGMOxQAAJXzCA= Message-Id: <20070603063724.WTKD7229.oaamta02sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e 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 That's fine with me. Hesham > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Sunday, June 03, 2007 3:34 PM > To: 'Hesham Soliman'; 'Henrik Levkowetz' > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: > DS-MIP6-Consensuscall to close issue 93 > > Hesham, > > Fine. Let them speak out. I will just say, there is sufficient > interest to close this issue properly. Rest, I will leave it to > the chairs and to the authors of this draft to ensure the draft > reflects the WG consensus, in the right spirit. > > Regards > Sri > > > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Saturday, June 02, 2007 7:37 PM > > To: 'Sri Gundavelli'; 'Henrik Levkowetz' > > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > > Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: > > DS-MIP6-Consensuscall to close issue 93 > > > > Sri, > > > > Pascal's email was not sent in private and we don't need an > > interpretation. > > He's alive and well and he didn't object to Raj's conclusion. > > He clearly > > said that we should let the draft move as is. I believe other > > people who are > > also alive and well can speak for themselves if they were > > misrepresented..... > > > > I look forward to people expressing that they were > > misrepresnted by the > > chairs. I don't think it's useful for you or Henrik to > > recount on their > > behalf. > > > > Hesham > > > > > I understand the need to complete the DSMIP6 as early as > > > possible and I appreciate the Chair's position to close > > > this issue soon. I really like to see that as well. I also > > > believe, IMO, that there is a proper justification in asking > > > for Option#3. Its for a simple TLV header, qualifier in UDP > > > for the payload packet. Many reasons, examples, protocol > > > conventions including 3519's way of dealing with the exact > > > same issue, lack of resaved port numbers, opening multiple > > > port numbers if we were to extend it later, and many other > > > reasons were mentioned and against the one solid reason of > > > extra-4 byte overhead. We don't have turn this to a voting > > > machine, if we see the need for this request with certain > > > flexibility. > > > > > > Now, w.r.t the voting, I though Pascal did mention the need > > > for a supporting new encapsulation mode and off course he > > > also wanted this work to close ASAP and that leaves it in > > > a ambiguous vote. And if I interpret Vijay's emails correctly, > > > his preference is for Option#4 and his second preference is > > > for option#3. He can speak up. And, we missed Alessio Casati's > > > preference on this issue, he did support option#3. So with > > > Jouni Korhonen, he did state that "I prefer more future proof > > > extensibility over slight performance hit thus I prefer the > > > 4 bytes header like in 3519". I also interpret Yoshi Tsuda's > > > vote in favour of option#3. > > > > > > If this is not rough consensus, atleast, there is sufficient > > > interest to discuss this issue further and proper conclude. > > > My 2c. > > > > > > Regards > > > Sri > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > > > Sent: Saturday, June 02, 2007 4:05 AM > > > > To: 'Henrik Levkowetz' > > > > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > > > > Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: > > > > DS-MIP6 -Consensuscall to close issue 93 > > > > > > > > > > > > > No, I'm not looking for a vote. I'm looking for consensus > > > > on how to > > > > > handle the issue. And I don't see any consensus on how to > > > > handle the > > > > > issue here. > > > > > > > > => The issue was raised against an existing solution, if > > > > there is no support > > > > in the WG (6 people against and 5 for it) then clearly there > > > > is no agreement > > > > that there is an issue to begin with. What are you suggesting > > > > we do? If > > > > there is no support for the perceived issue then naturally > > > > it's rejected. I > > > > don't think anyone is changing their mind if we ask the same > > > > question again > > > > in the space of two weeks... > > > > > > > > If a 6:5 or 5:4 means no concensus to you, then I'm > > > surprised that you > > > > accepted the same numbers as concensus on other issues, like > > > > the mapped > > > > address one or issue 93. Should we repeat all those > > > questions again? > > > > > > > > Hesham > > > > > > > > > > > > > > > > > > > Henrik > > > > > > > > > > > We've always asked for concencus to > > > > > > change anything > > > > > > in the draft. The numbers that Raj sent clearly indicate > > > > > that there is no > > > > > > concensus to change the draft. 5:4 is not concensus. > > > > > Therefore, I think > > > > > > Raj's decision is correct. I hope we don't turn the IETF > > > > > into a voting > > > > > > organisation, if we do then the whole process of > providing > > > > > a vote would be > > > > > > different from what we do today. > > > > > > > > > > > > Hesham > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > > > > >> Sent: Saturday, June 02, 2007 9:28 AM > > > > > >> To: Narayanan, Vidya > > > > > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; > > Basavaraj Patil > > > > > >> Subject: Re: [Mip6] Re: [nemo] Summary and > conclusion of: > > > > > >> DS-MIP6 - Consensuscall to close issue 93 > > > > > >> > > > > > >> Hi Vidya, Rai, > > > > > >> > > > > > >> On 2007-06-02 00:13 Narayanan, Vidya said the following: > > > > > >>> FWIW, I had also supported going with Option 1 > > for DS-MIP6. > > > > > >> Of course that matters, Vidya, but the more > > > important thing here > > > > > >> is that it's pretty clear to me that there is *no* > > > > rough consensus > > > > > >> present. > > > > > >> > > > > > >> Please don't manufacture one when there isn't > one; if there > > > > > >> really isn't one, do another call for discussion > > and/or show > > > > > >> of hands, and if the group is deadlocked, use 3929. > > > > > >> > > > > > >> I can't accept this pronouncement of a consensus, > > > rough or not, > > > > > >> in the group, neither from my observation of the > > > discussion or > > > > > >> from the count. > > > > > >> > > > > > >> > > > > > >> Henrik > > > > > >> > > > > > >> > > > > > >>> Vidya > > > > > >>> > > > > > >>>> -----Original Message----- > > > > > >>>> From: Basavaraj Patil > [mailto:basavaraj.patil@nsn.com] > > > > > >>>> Sent: Friday, June 01, 2007 2:36 PM > > > > > >>>> To: Levkowetz > > > > > >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > > > > >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion > > > of: DS-MIP6 > > > > > >>>> - Consensus call to close issue 93 > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> Vijay D. - Option 4 originally and then changed to > > > Option 2 > > > > > >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - > > > Option 3 > > > > > >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 > > > > > >>>> (Interpreted) George T. - Option 1 Mohamed Khalil > > > - Option 3 > > > > > >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 > Pascal T. - > > > > > >>>> Option 1 (Interpreted) > > > > > >>>> > > > > > >>>> So we have a sort of a tie if you strictly go > by count. > > > > > >>>> If I were to express my own opinion > > > (non-chair-hat), I would > > > > > >>>> go with option 1 as well for the current DS-MIP6 > > proposal > > > > > >>>> (aligned with my earlier email that if and > when GRE is > > > > > >>>> planned for use, another UDP port can be > > > reserved... But for > > > > > >>>> now option 1). That would break any deadlock issues. > > > > > >>>> > > > > > >>>> Or the other way is to let the chairs decide > what is the > > > > > >>>> sense of the discussion on the ML and from the > > > perspective of > > > > > >>>> the charter/scope and urgency of this protocol. > > > And from this > > > > > >>>> angle as well, I would stick by my conclusion, i.e > > > option 1. > > > > > >>>> > > > > > >>>> -Raj > > > > > >>>> > > > > > >>>> > > > > > >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" > > > > > >>>> wrote: > > > > > >>>> > > > > > >>>>> Hi Raj, > > > > > >>>>> > > > > > >>>>> On 2007-06-01 21:46 Basavaraj Patil said the > following: > > > > > >>>>>> So after an extensive discussion on this topic > > > which spun > > > > > >>>> off into a > > > > > >>>>>> discussion about the need/use for GRE, I > would like to > > > > > >> summarize > > > > > >>>>>> where we are with the options that we have. > > > > > >>>>>> > > > > > >>>>>> Conclusion was that for DS-MIP6, Option 1 > which is : " > > > > > >> Parse the > > > > > >>>>>> protocol header following the UDP header" is > > good enough. > > > > > >>>>> Could you give us an indication of who > preferred which > > > > > >> option? You > > > > > >>>>> seem to be very clear about the outcome, while > > it was far > > > > > >>>> from obvious > > > > > >>>>> to me that the counts turned out to support above > > > > conclusion... > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> Henrik > > > > > >>>>> > > > > > >>>>>> So it implies no changes to the current text in the > > > > > >>>> DS-MIP6 I-D w.r.t > > > > > >>>>>> this issue are needed. > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> It was pointed out that in the future if GRE was > > > > > >> determined as a > > > > > >>>>>> protocol that needs to be supported as well > either for > > > > > >>>> MIP6, NEMO or > > > > > >>>>>> PMIP6 then it would be specified in the > > > appropriate WG and > > > > > >>>> a UDP port > > > > > >>>>>> reserved for the same. In such a case it would > > > > > >> essentially be the > > > > > >>>>>> equivalent of option 2 in the choices list (below). > > > > > >>>>>> > > > > > >>>>>> At this time, the need for GRE especially > in the scope > > > > > >> of DS-MIP6 > > > > > >>>>>> which is primarily MIP6 and NEMO is not > proven. Hence > > > > > >> we will move > > > > > >>>>>> forward with Option 1 and close this issue. > > > > > >>>>>> > > > > > >>>>>> -Raj > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" > > > > > >>>> wrote: > > > > > >>>>>>> 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 Sun Jun 03 04:48: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 1Hull8-00019G-EB; Sun, 03 Jun 2007 04:48:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hull6-000190-OS; Sun, 03 Jun 2007 04:48:20 -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 1Hull5-0007YV-GR; Sun, 03 Jun 2007 04:48:20 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1Hull0-00029M-Vp; Sun, 03 Jun 2007 10:48:15 +0200 Message-ID: <4662804D.6010708@levkowetz.com> Date: Sun, 03 Jun 2007 10:48:13 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 -Consensuscall to close issue 93 References: <20070603023726.DFMV1743.oaamta04sl.mx.bigpond.com@PC20005> In-Reply-To: <20070603023726.DFMV1743.oaamta04sl.mx.bigpond.com@PC20005> X-Enigmail-Version: 0.95.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: Hesham@elevatemobile.com, sgundave@cisco.com, nemo@ietf.org, 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: a1dc446dc7ac353b90b60743d0e479e3 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , '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 Hesham, On 2007-06-03 04:37 Hesham Soliman said the following: > Sri, > > Pascal's email was not sent in private and we don't need an interpretation. > He's alive and well and he didn't object to Raj's conclusion. He clearly > said that we should let the draft move as is. I believe other people who are > also alive and well can speak for themselves if they were > misrepresented..... > > I look forward to people expressing that they were misrepresnted by the > chairs. I don't think it's useful for you or Henrik to recount on their > behalf. As you said about Pascal's email, the mails were sent to the list, not in private. If a review of the list shows substantially more expressions of preference than were noticed by the chairs, this seems to me to be a matter which I *do* think it's useful to point out by showing a strawman recount. I don't think you want the chair to misrepresent what people have expressed on the list? Henrik > Hesham > >> I understand the need to complete the DSMIP6 as early as >> possible and I appreciate the Chair's position to close >> this issue soon. I really like to see that as well. I also >> believe, IMO, that there is a proper justification in asking >> for Option#3. Its for a simple TLV header, qualifier in UDP >> for the payload packet. Many reasons, examples, protocol >> conventions including 3519's way of dealing with the exact >> same issue, lack of resaved port numbers, opening multiple >> port numbers if we were to extend it later, and many other >> reasons were mentioned and against the one solid reason of >> extra-4 byte overhead. We don't have turn this to a voting >> machine, if we see the need for this request with certain >> flexibility. >> >> Now, w.r.t the voting, I though Pascal did mention the need >> for a supporting new encapsulation mode and off course he >> also wanted this work to close ASAP and that leaves it in >> a ambiguous vote. And if I interpret Vijay's emails correctly, >> his preference is for Option#4 and his second preference is >> for option#3. He can speak up. And, we missed Alessio Casati's >> preference on this issue, he did support option#3. So with >> Jouni Korhonen, he did state that "I prefer more future proof >> extensibility over slight performance hit thus I prefer the >> 4 bytes header like in 3519". I also interpret Yoshi Tsuda's >> vote in favour of option#3. >> >> If this is not rough consensus, atleast, there is sufficient >> interest to discuss this issue further and proper conclude. >> My 2c. >> >> Regards >> Sri >> >> >> >> >>> -----Original Message----- >>> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >>> Sent: Saturday, June 02, 2007 4:05 AM >>> To: 'Henrik Levkowetz' >>> Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' >>> Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: >>> DS-MIP6 -Consensuscall to close issue 93 >>> >>> >>> > No, I'm not looking for a vote. I'm looking for consensus >>> on how to >>> > handle the issue. And I don't see any consensus on how to >>> handle the >>> > issue here. >>> >>> => The issue was raised against an existing solution, if >>> there is no support >>> in the WG (6 people against and 5 for it) then clearly there >>> is no agreement >>> that there is an issue to begin with. What are you suggesting >>> we do? If >>> there is no support for the perceived issue then naturally >>> it's rejected. I >>> don't think anyone is changing their mind if we ask the same >>> question again >>> in the space of two weeks... >>> >>> If a 6:5 or 5:4 means no concensus to you, then I'm >> surprised that you >>> accepted the same numbers as concensus on other issues, like >>> the mapped >>> address one or issue 93. Should we repeat all those >> questions again? >>> Hesham >>> >>> > >>> > >>> > Henrik >>> > >>> > > We've always asked for concencus to >>> > > change anything >>> > > in the draft. The numbers that Raj sent clearly indicate >>> > that there is no >>> > > concensus to change the draft. 5:4 is not concensus. >>> > Therefore, I think >>> > > Raj's decision is correct. I hope we don't turn the IETF >>> > into a voting >>> > > organisation, if we do then the whole process of providing >>> > a vote would be >>> > > different from what we do today. >>> > > >>> > > Hesham >>> > > >>> > >> -----Original Message----- >>> > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >>> > >> Sent: Saturday, June 02, 2007 9:28 AM >>> > >> To: Narayanan, Vidya >>> > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Basavaraj Patil >>> > >> Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: >>> > >> DS-MIP6 - Consensuscall to close issue 93 >>> > >> >>> > >> Hi Vidya, Rai, >>> > >> >>> > >> On 2007-06-02 00:13 Narayanan, Vidya said the following: >>> > >>> FWIW, I had also supported going with Option 1 for DS-MIP6. >>> > >> Of course that matters, Vidya, but the more >> important thing here >>> > >> is that it's pretty clear to me that there is *no* >>> rough consensus >>> > >> present. >>> > >> >>> > >> Please don't manufacture one when there isn't one; if there >>> > >> really isn't one, do another call for discussion and/or show >>> > >> of hands, and if the group is deadlocked, use 3929. >>> > >> >>> > >> I can't accept this pronouncement of a consensus, >> rough or not, >>> > >> in the group, neither from my observation of the >> discussion or >>> > >> from the count. >>> > >> >>> > >> >>> > >> Henrik >>> > >> >>> > >> >>> > >>> Vidya >>> > >>> >>> > >>>> -----Original Message----- >>> > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>> > >>>> Sent: Friday, June 01, 2007 2:36 PM >>> > >>>> To: Levkowetz >>> > >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List >>> > >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion >> of: DS-MIP6 >>> > >>>> - Consensus call to close issue 93 >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> Vijay D. - Option 4 originally and then changed to >> Option 2 >>> > >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - >> Option 3 >>> > >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 >>> > >>>> (Interpreted) George T. - Option 1 Mohamed Khalil >> - Option 3 >>> > >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - >>> > >>>> Option 1 (Interpreted) >>> > >>>> >>> > >>>> So we have a sort of a tie if you strictly go by count. >>> > >>>> If I were to express my own opinion >> (non-chair-hat), I would >>> > >>>> go with option 1 as well for the current DS-MIP6 proposal >>> > >>>> (aligned with my earlier email that if and when GRE is >>> > >>>> planned for use, another UDP port can be >> reserved... But for >>> > >>>> now option 1). That would break any deadlock issues. >>> > >>>> >>> > >>>> Or the other way is to let the chairs decide what is the >>> > >>>> sense of the discussion on the ML and from the >> perspective of >>> > >>>> the charter/scope and urgency of this protocol. >> And from this >>> > >>>> angle as well, I would stick by my conclusion, i.e >> option 1. >>> > >>>> >>> > >>>> -Raj >>> > >>>> >>> > >>>> >>> > >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" >>> > >>>> wrote: >>> > >>>> >>> > >>>>> Hi Raj, >>> > >>>>> >>> > >>>>> On 2007-06-01 21:46 Basavaraj Patil said the following: >>> > >>>>>> So after an extensive discussion on this topic >> which spun >>> > >>>> off into a >>> > >>>>>> discussion about the need/use for GRE, I would like to >>> > >> summarize >>> > >>>>>> where we are with the options that we have. >>> > >>>>>> >>> > >>>>>> Conclusion was that for DS-MIP6, Option 1 which is : " >>> > >> Parse the >>> > >>>>>> protocol header following the UDP header" is good enough. >>> > >>>>> Could you give us an indication of who preferred which >>> > >> option? You >>> > >>>>> seem to be very clear about the outcome, while it was far >>> > >>>> from obvious >>> > >>>>> to me that the counts turned out to support above >>> conclusion... >>> > >>>>> >>> > >>>>> >>> > >>>>> Henrik >>> > >>>>> >>> > >>>>>> So it implies no changes to the current text in the >>> > >>>> DS-MIP6 I-D w.r.t >>> > >>>>>> this issue are needed. >>> > >>>>>> >>> > >>>>>> >>> > >>>>>> It was pointed out that in the future if GRE was >>> > >> determined as a >>> > >>>>>> protocol that needs to be supported as well either for >>> > >>>> MIP6, NEMO or >>> > >>>>>> PMIP6 then it would be specified in the >> appropriate WG and >>> > >>>> a UDP port >>> > >>>>>> reserved for the same. In such a case it would >>> > >> essentially be the >>> > >>>>>> equivalent of option 2 in the choices list (below). >>> > >>>>>> >>> > >>>>>> At this time, the need for GRE especially in the scope >>> > >> of DS-MIP6 >>> > >>>>>> which is primarily MIP6 and NEMO is not proven. Hence >>> > >> we will move >>> > >>>>>> forward with Option 1 and close this issue. >>> > >>>>>> >>> > >>>>>> -Raj >>> > >>>>>> >>> > >>>>>> >>> > >>>>>> >>> > >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" >>> > >>>> wrote: >>> > >>>>>>> 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 Sun Jun 03 04:52: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 1Hulow-0003e1-3O; Sun, 03 Jun 2007 04:52:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hulou-0003cc-Ph; Sun, 03 Jun 2007 04:52:16 -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 1Hulou-0007uQ-A7; Sun, 03 Jun 2007 04:52:16 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1Hulos-0002T1-JV; Sun, 03 Jun 2007 10:52:14 +0200 Message-ID: <4662813D.4070301@levkowetz.com> Date: Sun, 03 Jun 2007 10:52:13 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensuscall to close issue 93 References: <20070603023927.EBSR5805.oaamta01sl.mx.bigpond.com@PC20005> In-Reply-To: <20070603023927.EBSR5805.oaamta01sl.mx.bigpond.com@PC20005> X-Enigmail-Version: 0.95.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: Hesham@elevatemobile.com, nemo@ietf.org, 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: c83ccb5cc10e751496398f1233ca9c3a 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, On 2007-06-03 04:39 Hesham Soliman said the following: > Henrik, > > Like I said, if you want to go by your interepretation then I'll ask the > chairs to reopen the other issues. I won't accept selectivity on where to > apply those rules. Certainly. But we should also have indications of preference which reasonably well match what has been sent to the list. With the mis-tally of people's expressed preference in the latest case, the first thing to do would maybe be to go over the list material in the other cases, and see if maybe the list showed a consensus even if the chair's tally didn't show one? Henrik > I'll wait for the chairs/AD's decision on this. > > Hesham > >>> We already did that, it's implicit in the question for a >> choice between >>> keeping things as they are (i.e. it's not an issue that we >> need to solve) Vs >>> 3 other options (or 2 workable options because option 4 >> doesn't work). >> >> I think here we have a fundamental disagrement. >> >> If I understand your reasoning right, then you are saying that in a >> case when the WG doesn't have consensus on an issue, whatever is >> written in a document is going to be the resolution. >> >> I'm saying that if the working group doesn't have consensus >> on an issue, >> it doesn't matter what the document says; the document >> cannot go forward >> with either of the discussed solutions if the WG doesn't have rough >> consensus for one of them. >> >> Maybe you're focussing more on what is going to be changed in the >> document right now, rather on closing the issue; while I'm >> focussing on >> resolving the issue, and the text of the document at the >> point when it >> can be sent for publication, rather than focussing on what happens to >> the document text right now? >> >>>> I saw several people change position during the >> discussion, which is >>>> of course the benefit of having a discussion in the first >> place -- as >>>> various aspects of a question is illuminated, people get a clearer >>>> view of the tradeofs, and hopefully align in a rough consensus. >>> Several people? I saw one. >> And I saw several. Does arguing about this lead anywhere? >> >>>>> If a 6:5 or 5:4 means no concensus to you, then I'm >>>> surprised that you >>>>> accepted the same numbers as concensus on other issues, >>>> like the mapped >>>>> address one or issue 93. Should we repeat all those >>>> questions again? >>>> >>>> If you have counts of those issues that indicate that there was no >>>> consensus (and 6:5 or 5:4 isn't even rough consensus as >> far as I can >>>> tell) then I think that would be the right thing to do. >>> I agree that 6:5, 5:4 or 4:3 is not a concensus. To me >> that means there >>> is no concensus to change the draft. Of course the figures >> for the mapped >>> address were sent to the list, it was 5:4 for the change, >> you have those >>> figures too. So if we re-open an issue for this reason >> then we have to be >>> consistent and re-open all issues. >>> >>> However, my >>>> memory of the other discussions isn't that they were as >> inconclusive >>>> as this one. >>> You can check Raj's email on the mapped address issue >> yourself, it was >>> another 5:4. I don't remember the exact number on issue >> 93. I assume you're >>> not considering that a valid concensus either, we would >> agree on that. >>> Hesham >>> >>> >>> >>>> Henrik >>>> >>>> >>>> >>> >>> >> > > > > _______________________________________________ > 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 Sun Jun 03 05:33:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HumSc-0000D9-Jl; Sun, 03 Jun 2007 05:33:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HumSa-0000D1-MH; Sun, 03 Jun 2007 05:33:16 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HumSZ-0006HF-80; Sun, 03 Jun 2007 05:33:16 -0400 Received: from oaamta06sl.mx.bigpond.com ([124.191.178.123]) by omta01sl.mx.bigpond.com with ESMTP id <20070603093312.RUDZ14178.omta01sl.mx.bigpond.com@oaamta06sl.mx.bigpond.com>; Sun, 3 Jun 2007 09:33:12 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta06sl.mx.bigpond.com with ESMTP id <20070603093311.TXWH28187.oaamta06sl.mx.bigpond.com@PC20005>; Sun, 3 Jun 2007 09:33:11 +0000 From: "Hesham Soliman" To: "'Henrik Levkowetz'" Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 -Consensuscall to close issue 93 Date: Sun, 3 Jun 2007 19:33:07 +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: <4662804D.6010708@levkowetz.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acelu/AolsNYhhfvQaSiQvxKe5aVagABdvjw Message-Id: <20070603093311.TXWH28187.oaamta06sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , '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 > > > > Pascal's email was not sent in private and we don't need > an interpretation. > > He's alive and well and he didn't object to Raj's > conclusion. He clearly > > said that we should let the draft move as is. I believe > other people who are > > also alive and well can speak for themselves if they were > > misrepresented..... > > > > I look forward to people expressing that they were > misrepresnted by the > > chairs. I don't think it's useful for you or Henrik to > recount on their > > behalf. > > As you said about Pascal's email, the mails were sent to the list, > not in private. If a review of the list shows substantially more > expressions of preference than were noticed by the chairs, this > seems to me to be a matter which I *do* think it's useful to point > out by showing a strawman recount. I don't think you want the chair > to misrepresent what people have expressed on the list? => No of course I don't want that, hence my statement above. But these people are on the list and they know whether they were misrepresented or not. For the last few weeks (and since Raj sent his last email a couple of days ago) no one seemed to complain, so let them speak for themselves. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jun 03 05:46: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 1HumfO-00022C-1c; Sun, 03 Jun 2007 05:46:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HumfM-000203-0f; Sun, 03 Jun 2007 05:46:28 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HumfL-00081V-7Z; Sun, 03 Jun 2007 05:46:27 -0400 Received: from oaamta08sl.mx.bigpond.com ([124.191.178.123]) by omta04sl.mx.bigpond.com with ESMTP id <20070603094620.QIID28583.omta04sl.mx.bigpond.com@oaamta08sl.mx.bigpond.com>; Sun, 3 Jun 2007 09:46:20 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta08sl.mx.bigpond.com with ESMTP id <20070603094620.VFNS16336.oaamta08sl.mx.bigpond.com@PC20005>; Sun, 3 Jun 2007 09:46:20 +0000 From: "Hesham Soliman" To: "'Henrik Levkowetz'" Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensuscall to close issue 93 Date: Sun, 3 Jun 2007 19:46:15 +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: <4662813D.4070301@levkowetz.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcelvH1r/tKr49MiROSAHTzsPD3LRAABc3jw Message-Id: <20070603094620.VFNS16336.oaamta08sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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 > > Like I said, if you want to go by your interepretation > then I'll ask the > > chairs to reopen the other issues. I won't accept > selectivity on where to > > apply those rules. > > Certainly. > > But we should also have indications of preference which > reasonably well > match what has been sent to the list. With the mis-tally of people's > expressed preference in the latest case, the first thing to do would > maybe be to go over the list material in the other cases, and see if > maybe the list showed a consensus even if the chair's tally didn't > show one? => I'm not sure what you mean by "going over the list material in the other cases" but I'm more than happy for the chair or AD to review the concensus threads for all those issues and include known opionions from the DT people. Actually, some people were counted despite not sending a peep about the issue to the list (not only during the concensus call but in general). So, yes a review is fine with me as long as we're consistent; regardless of the outcome. I was ok with things as is because at least it was consistent. The question is whether we want to keep delaying things to do this or just go with the decisions that were already made. Personally, I prefer less delays and going with the decisions already made (and you know too well that I didn't agree with some of the outcomes), but if you're objecting to the way all these decisions are made and the chairs grant a review of all those issues then I'm fine with that too. As I said earlier, the only thing that doesn't make sense is to change the rules for one issue. Hesham > > > Henrik > > > I'll wait for the chairs/AD's decision on this. > > > > Hesham > > > >>> We already did that, it's implicit in the question for a > >> choice between > >>> keeping things as they are (i.e. it's not an issue that we > >> need to solve) Vs > >>> 3 other options (or 2 workable options because option 4 > >> doesn't work). > >> > >> I think here we have a fundamental disagrement. > >> > >> If I understand your reasoning right, then you are saying > that in a > >> case when the WG doesn't have consensus on an issue, whatever is > >> written in a document is going to be the resolution. > >> > >> I'm saying that if the working group doesn't have consensus > >> on an issue, > >> it doesn't matter what the document says; the document > >> cannot go forward > >> with either of the discussed solutions if the WG doesn't > have rough > >> consensus for one of them. > >> > >> Maybe you're focussing more on what is going to be changed in the > >> document right now, rather on closing the issue; while I'm > >> focussing on > >> resolving the issue, and the text of the document at the > >> point when it > >> can be sent for publication, rather than focussing on > what happens to > >> the document text right now? > >> > >>>> I saw several people change position during the > >> discussion, which is > >>>> of course the benefit of having a discussion in the first > >> place -- as > >>>> various aspects of a question is illuminated, people > get a clearer > >>>> view of the tradeofs, and hopefully align in a rough consensus. > >>> Several people? I saw one. > >> And I saw several. Does arguing about this lead anywhere? > >> > >>>>> If a 6:5 or 5:4 means no concensus to you, then I'm > >>>> surprised that you > >>>>> accepted the same numbers as concensus on other issues, > >>>> like the mapped > >>>>> address one or issue 93. Should we repeat all those > >>>> questions again? > >>>> > >>>> If you have counts of those issues that indicate that > there was no > >>>> consensus (and 6:5 or 5:4 isn't even rough consensus as > >> far as I can > >>>> tell) then I think that would be the right thing to do. > >>> I agree that 6:5, 5:4 or 4:3 is not a concensus. To me > >> that means there > >>> is no concensus to change the draft. Of course the figures > >> for the mapped > >>> address were sent to the list, it was 5:4 for the change, > >> you have those > >>> figures too. So if we re-open an issue for this reason > >> then we have to be > >>> consistent and re-open all issues. > >>> > >>> However, my > >>>> memory of the other discussions isn't that they were as > >> inconclusive > >>>> as this one. > >>> You can check Raj's email on the mapped address issue > >> yourself, it was > >>> another 5:4. I don't remember the exact number on issue > >> 93. I assume you're > >>> not considering that a valid concensus either, we would > >> agree on that. > >>> Hesham > >>> > >>> > >>> > >>>> Henrik > >>>> > >>>> > >>>> > >>> > >>> > >> > > > > > > > > _______________________________________________ > > 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 Sun Jun 03 11:56:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HusQt-0006Eu-4p; Sun, 03 Jun 2007 11:55:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HusQr-0006Eh-70; Sun, 03 Jun 2007 11:55:53 -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 1HusQp-0007Io-Ic; Sun, 03 Jun 2007 11:55:53 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HusQh-0000rw-C4; Sun, 03 Jun 2007 17:55:43 +0200 Message-ID: <4662E47D.4000509@levkowetz.com> Date: Sun, 03 Jun 2007 17:55:41 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensuscall to close issue 93 References: <20070603094620.VFNS16336.oaamta08sl.mx.bigpond.com@PC20005> In-Reply-To: <20070603094620.VFNS16336.oaamta08sl.mx.bigpond.com@PC20005> X-Enigmail-Version: 0.95.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: Hesham@elevatemobile.com, nemo@ietf.org, 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: 538aad3a3c4f01d8b6a6477ca4248793 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, On 2007-06-03 11:46 Hesham Soliman said the following: > >>> Like I said, if you want to go by your interepretation >> then I'll ask the >>> chairs to reopen the other issues. I won't accept >> selectivity on where to >>> apply those rules. >> Certainly. >> >> But we should also have indications of preference which >> reasonably well >> match what has been sent to the list. With the mis-tally of people's >> expressed preference in the latest case, the first thing to do would >> maybe be to go over the list material in the other cases, and see if >> maybe the list showed a consensus even if the chair's tally didn't >> show one? > > I'm not sure what you mean by "going over the list material in the other > cases" but I'm more than happy for the chair or AD to review the concensus > threads for all those issues and include known opionions from the DT people. Right. > Actually, some people were counted despite not sending a peep about the > issue to the list (not only during the concensus call but in general). So, > yes a review is fine with me as long as we're consistent; regardless of the > outcome. I was ok with things as is because at least it was consistent. The > question is whether we want to keep delaying things to do this or just go > with the decisions that were already made. I don't particularly want to delay things, but swiftly producing a document which doesn't reflect the lists viewpoint on how the issues should be resolved doesn't seem like a good idea either -- in the worst case, it would lead to a requirement to do a -bis document immediately, which I would see as a rather larger delay... > Personally, I prefer less delays and going with the decisions already made > (and you know too well that I didn't agree with some of the outcomes), but > if you're objecting to the way all these decisions are made and the chairs > grant a review of all those issues then I'm fine with that too. As I said > earlier, the only thing that doesn't make sense is to change the rules for > one issue. I agree with this. Henrik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jun 03 12:03: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 1HusXx-0004B5-KZ; Sun, 03 Jun 2007 12:03:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HusXv-0004At-Qj for mip6@ietf.org; Sun, 03 Jun 2007 12:03:11 -0400 Received: from mail-v023.telia.se ([81.236.34.23] helo=teliasonera.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HusXt-0008GG-Op for mip6@ietf.org; Sun, 03 Jun 2007 12:03:11 -0400 Received: from sehan002bb.han.telia.se (sehan002bb.han.telia.se [131.115.18.153]) by mail2.han.telia.se (BorderWare Infinity Mail Firewall) with ESMTP id BA33392B0804FEF5; Sun, 3 Jun 2007 18:03:08 +0200 (CEST) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Jun 2007 18:03:08 +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] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Date: Sun, 3 Jun 2007 18:03:07 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301F26848@SEHAN021MB.tcad.telia.se> In-Reply-To: <4660AB79.3050204@levkowetz.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: AcekpIBbRCsCHjPiRqqZdKEXwwgxrABVBg6Q References: <4660AB79.3050204@levkowetz.com> From: To: , X-OriginalArrivalTime: 03 Jun 2007 16:03:08.0150 (UTC) FILETIME=[AD4FA960:01C7A5F8] Received-SPF: none X-Spam-Score: 0.2 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 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 I think I expressed my preference for option 3. Cheers, Jouni > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > Sent: Saturday, June 02, 2007 2:28 AM > To: Basavaraj Patil > Cc: nemo@ietf.org; Mobile IPv6 Mailing List > Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6=20 > - Consensus call to close issue 93 >=20 >=20 >=20 >=20 > On 2007-06-01 23:36 Basavaraj Patil said the following: > >=20 > > Vijay D. - Option 4 originally and then changed to Option 2=20 > Hesham -=20 > > Option 1 Sri Gundavelli - Option 3 Kent - Option 3 Ahmad Muhanna -=20 > > Option 3 Alex Petrescu - Option 1 (Interpreted) George T. -=20 > Option 1=20 > > Mohamed Khalil - Option 3 Markku Ala-V - Option 2 Henrik L.=20 > - Option 3=20 > > Pascal T. - Option 1 (Interpreted) > >=20 > > So we have a sort of a tie if you strictly go by count. >=20 > No, if we strictly go by the above count, there's no tie: >=20 > Option 3 5 counts > Option 1 4 counts > Option 2 2 counts >=20 > > If I were to express my own opinion (non-chair-hat), I=20 > would go with=20 > > option 1 as well for the current DS-MIP6 proposal (aligned with my=20 > > earlier email that if and when GRE is planned for use, another UDP=20 > > port can be reserved... But for now option 1). That would break any=20 > > deadlock issues. >=20 > That would be credible if you'd said that before pronouncing=20 > a consensus for option 1. Now it doesn't. >=20 > > Or the other way is to let the chairs decide what is the=20 > sense of the=20 > > discussion on the ML and from the perspective of the=20 > charter/scope and=20 > > urgency of this protocol. And from this angle as well, I=20 > would stick=20 > > by my conclusion, i.e option 1. >=20 > That was my original reason for asking for the count --=20 > having followed the discussion, my perception was *very*=20 > different, and there wasn't a consensus for 1 in the sense of=20 > the discussion. >=20 >=20 > Henrik >=20 >=20 > > -Raj > >=20 > >=20 > > On 6/1/07 3:52 PM, "ext Henrik Levkowetz"=20 > wrote: > >=20 > >> Hi Raj, > >> > >> On 2007-06-01 21:46 Basavaraj Patil said the following: > >>> So after an extensive discussion on this topic which spun=20 > off into a=20 > >>> discussion about the need/use for GRE, I would like to summarize=20 > >>> where we are with the options that we have. > >>> > >>> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the=20 > >>> protocol header following the UDP header" is good enough. > >> Could you give us an indication of who preferred which=20 > option? You=20 > >> seem to be very clear about the outcome, while it was far from=20 > >> obvious to me that the counts turned out to support above=20 > conclusion... > >> > >> > >> Henrik > >> > >>> So it implies no changes to the current text in the DS-MIP6 I-D=20 > >>> w.r.t this issue are needed. > >>> > >>> > >>> It was pointed out that in the future if GRE was determined as a=20 > >>> protocol that needs to be supported as well either for=20 > MIP6, NEMO or=20 > >>> PMIP6 then it would be specified in the appropriate WG and a UDP=20 > >>> port reserved for the same. In such a case it would=20 > essentially be=20 > >>> the equivalent of option 2 in the choices list (below). > >>> > >>> At this time, the need for GRE especially in the scope of DS-MIP6=20 > >>> which is primarily MIP6 and NEMO is not proven. Hence we=20 > will move=20 > >>> forward with Option 1 and close this issue. > >>> > >>> -Raj > >>> > >>> > >>> > >>> On 5/8/07 4:16 PM, "ext Basavaraj Patil"=20 > wrote: > >>> > >>>> Hello, > >>>> > >>>> The DS-MIP6 I-D=20 > still has=20 > >>>> issue 93 open. This was discussed at IETF68. Vijay presented 4=20 > >>>> 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=20 > forward with the=20 > >>>> I-D. At the meeting itself, I got the sense that option=20 > 3 was the=20 > >>>> one that had the least impact and easy to implement. > >>>> > >>>> Please consider this email as a consensus call for issue 93. The=20 > >>>> problem and choices are as follows (based on Vijay's slides): > >>>> > >>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal.=20 > >>>> 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=20 > >>>> protocol being encapsulated in the UDP header. > >>>> > >>>> Choices are: > >>>> 1. Parse the protocol header following the UDP header 2.=20 > 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=20 > type message" > >>>> 4. Encapsulated protocol header type is indicated in the=20 > BU message > >>>> > >>>> Pros and cons of these choices are in the slides that were=20 > >>>> presented at IETF68 (see URL above). > >>>> > >>>> Please provide your opinions and comments by May 15th, 07 on the=20 > >>>> MIP6 mailing list. > >>>> > >>>> -Raj > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jun 03 21:35: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 1Hv1Td-0002RD-Ef; Sun, 03 Jun 2007 21:35:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv1Tc-0002R8-6o for mip6@ietf.org; Sun, 03 Jun 2007 21:35:20 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv1Tb-0008KF-G8 for mip6@ietf.org; Sun, 03 Jun 2007 21:35:20 -0400 Received: from ep_ms5_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JJ300FYE8ETCT@mailout1.samsung.com> for mip6@ietf.org; Mon, 04 Jun 2007 10:35:17 +0900 (KST) Received: from ep_spt03 (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 <0JJ300G8B8ETQW@ms5.samsung.com> for mip6@ietf.org; Mon, 04 Jun 2007 10:35:17 +0900 (KST) Content-return: prohibited Date: Mon, 04 Jun 2007 01:35:17 +0000 (GMT) From: Heejin Jang Subject: Re: RE: [Mip6] I-D ACTION:draft-ietf-mip6-hiopt-03.txt To: "Premec, Domagoj" , Kilian.Weniger@eu.panasonic.com Message-id: <12633907.1277591180920917487.JavaMail.weblogic@ep_ml28> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20070604013517485@heejin.jang X-MTR: 20070604013517485@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: 14582b0692e7f70ce7111d04db3781c8 Cc: "mip6@ietf.org" 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="===============1444457525==" Errors-To: mip6-bounces@ietf.org --===============1444457525== Content-return: prohibited Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 SGksIERvbWFnb2ouDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudC4NCiANCkEgZmV3IGRheXMgYWdv LCBJIGFuc3dlcmVkIGFzIGZvbGxvd3MgZm9yIEtpbGlhbidzIHF1ZXN0aW9uIGluIE1MLg0KIA0K S2lsaWFuJ3MgUT4gV2hhdCBzaG91bGQgdGhlIERIQ1Agc2VydmVyIGRvIGlmIHRoZSBNSVA2IHJl bGF5IGFnZW50IG9wdGlvbiBjb250YWlucyBtdWx0aXBsZSBzdWItb3B0aW9ucyBhbmQgb25lIG9m IHRoZSBzdWItb3B0aW9ucyBtYXRjaGVzIHRoZSBOQUkncyByZWFsbSB3aGVyZWFzIGFub3RoZXIg b25lIGRvZXMgbm90PyBUaGlzIHNpdHVhdGlvbiBjYW4gaGFwcGVuIGlmIHRoZSBBQUFIIHNlbmRz IGhvbWUgbmV0d29yayBpbmZvcm1hdGlvbiBmb3IgbXV0bGlwbGUgTVNQcyB0byB0aGUgTkFTIChl LmcuLCBmb3IgaG9tZSBNU1AvTVNBIGFuZCBvdGhlciBNU1BzIHdpdGggdHJ1c3QgcmVsYXRpb25z aGlwIHRvIE1TQSkuIFNob3VsZCB0aGUgc2VydmVyIHJlc3BvbmQgd2l0aCBtdWx0aXBsZSBIb21l IE5ldHdvcmsgSW5mb3JtYXRpb24gU3ViLW9wdGlvbnM/DQogDQpIZWVqaW4ncyBBPiBBIERIQ1Ag c2VydmVyIGV4dHJhY3RzIG9ubHkgdGhlIGF2YWlsYWJsZSBIQSBpbmZvIGFtb25nIHRoZSBpbmZv IHByaXZpZGVkIGJ5IE5BUyAoZmluYWxseSBmcm9tIEFBQSkgYW5kIGluY2x1ZGVzIHRoZW0gaW4g YSBzaW5nbGUgSG9tZSBOZXR3b3JrIGluZm9ybWF0aW9uIG9wdGlvbiB3aXRoIG11bHRpcGxlIHN1 Yi1vcHRpb25zLiBJZiB0aGUgc2VydmVyIGhhcyBubyBpbmZvIGZvciB0aGUgc3BlY2lmaWVkIGlk LXR5cGUgaW4gSG9tZSBOZXR3b3JrLCB0aGVuIGl0IHJlcGxpZXMgd2l0aCBvcHQtbGVuPTAgaW4g YSBIb21lIE5ldHdvcmsgSW5mb3JtYXRpb24gb3B0aW9uLg0KIA0KSW4gbXkgYW5zd2VyLCAiYSBz aW5nbGUgSG9tZSBOZXR3b3JrIGluZm9ybWF0aW9uIG9wdGlvbiB3aXRoIG11bHRpcGxlIHN1Yi1v cHRpb25zIiBtZWFucyBwZXIgZWFjaCBhIHNpbmdsZSBIb21lIE5ldHdvcmsgSWRlbnRpZmllciBv cHRpb24uIFRoYXQgaXMsIHRoZSBudW1iZXIgb2YgSE4gSW5mb3JtYXRpb24gb3B0aW9uIGluIHRo ZSByZXBseSBpcyB0aGUgc2FtZSBhcyB0aGUgbnVtYmVyIG9mIEhOIEluZm9ybWF0aW9uIG9wdGlv biBpbiB0aGUgcmVxdWVzdCwgYW5kIHRoZSAiaWQtdHlwZSIgd2lsbCBiZSBhZGRlZCBpbiBhbiBI TiBpbmZvcm1hdGlvbiBvcHRpb24gZm9yIG1hcHBpbmcgZm9yIGVhY2ggb3B0aW9uLiBXZSBmaXhl ZCB0aGlzIGFuZCB0aGUgbmV4dCB2ZXJzaW9uIHdpbGwgY292ZXIgdGhpcy4NClRoYW5rcy4NCiAN Ci0gQmVzdCBSZWdhcmVkcywgDQpIZWVqaW4NCg0KLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tLS0NClNlbmRlciA6IFByZW1lYywgRG9tYWdvajxkb21hZ29qLnByZW1lY0BzaWVtZW5zLmNv bT4NCkRhdGUgICA6IDIwMDctMDYtMDEgMDA6NTYNClRpdGxlICA6IFJFOiBbTWlwNl0gSS1EIEFD VElPTjpkcmFmdC1pZXRmLW1pcDYtaGlvcHQtMDMudHh0DQoNCkhpIEhlZWppbiwNCg0KSSBoYXZl IGEgY2xhcmlmaWNhdGlvbiBxdWVzdGlvbjogaWYgdGhlIE1OIHJlcXVlc3RzIGluZm9ybWF0aW9u IGFib3V0IHNldmVyYWwgdGFyZ2V0IG5ldHdvcmtzIGl0IHdpbGwgaW5jbHVkZSBzZXZlcmFsIEhv bWUgTmV0d29yayBJZGVudGlmaWVyIG9wdGlvbnMuIFRoZSBmb2xsb3dpbmcgdGV4dCANCg0KPiAg IE11bHRpcGxlIHN1Yi1vcHRpb25zIG1heSBleGlzdCBpbiBhIEhvbWUgTmV0d29yayBJbmZvcm1h dGlvbiBvcHRpb24NCj4gICB0byBjYXJyeSBtb3JlIHRoYW4gb25lIGhvbWUgaW5mb3JtYXRpb24u DQoNCmxlYXZlcyBpbXByZXNzaW9uIHRoYXQgdGhlIHJlc3BvbnNlIG1lc3NhZ2UgY29udGFpbnMg b25seSBvbmUgSG9tZSBOZXR3b3JrIEluZm9ybWF0aW9uIG9wdGlvbiB3aGljaCBjYXJyaWVzIHRo ZSBhZGRyZXNzZXMsIHByZWZpeGVzIGFuZC9vciBGUUROcyBvZiBhbGwgdGFyZ2V0IG5ldHdvcmtz LiBJIGNvdWxkIGJlIHdyb25nLCBidXQgSSBjb3VsZG4mIzM5O3QgZmluZCBhbnkgdGV4dCB0aGF0 IGlzIHNwZWNpZmljIGFib3V0IHRoaXMuIA0KDQpJZiB0aGUgaW5mb3JtYXRpb24gYWJvdXQgbXVs dGlwbGUgdGFyZ2V0IG5ldHdvcmtzIGlzIGNhcnJpZWQgaW4gYSBzaW5nbGUgSG9tZSBOZXR3b3Jr IEluZm9ybWF0aW9uIG9wdGlvbiwgdGhlIE1OIG1heSBub3QgYmUgYWJsZSB0byBtYXRjaCB0aGUg aW5mbyBmcm9tIHRoZSBIb21lIE5ldHdvcmsgSW5mb3JtYXRpb24gb3B0aW9uIHRvIGEgcGFydGlj dWxhciB0YXJnZXQgbmV0d29yay4gRm9yIGV4YW1wbGUsIHRoZSBNTiBtYXkgYXNrIGZvciBpbmZv bWF0aW9uIGFib3V0IG9wZXJhdG9yMS5jb20gYW5kIG9wZXJhdG9yMi5jb20sIGFuZCB0aGUgSG9t ZSBOZXR3b3JrIEluZm9ybWF0aW9uIG9wdGlvbiBtYXkgY29udGFpbiB0aGUgaG9tZSBzdWJuZXQg cHJlZml4IGFuZCB0aGUgRlFETi4gSG93IHdvdWxkIHRoZSBNTiBrbm93IGlmIGJvdGggc3Vib3B0 aW9ucyBjYXJyeSBpbmZvcm1hdGlvbiBhYm91dCBvcGVyYXRvcjEuY29tIG9yIGlmIHN1Ym5ldCBi ZWxvbmdzIHRvIG9wZXJhdG9yMSBhbmQgRlFETiB0byBvcGVyYXRvciAyPw0KDQp0aGFua3MNCmRv bWFnb2oNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEludGVybmV0 LURyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOkludGVybmV0LURyYWZ0c0BpZXRmLm9yZ10gDQo+IFNl bnQ6IDE2LiBzdmliYW5qIDIwMDcgMjE6NTANCj4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0K PiBDYzogbWlwNkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbTWlwNl0gSS1EIEFDVElPTjpkcmFmdC1p ZXRmLW1pcDYtaGlvcHQtMDMudHh0IA0KPiANCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZh aWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgDQo+IEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4N Cj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTW9iaWxpdHkgZm9yIElQdjYgV29y a2luZyANCj4gR3JvdXAgb2YgdGhlIElFVEYuDQo+IA0KPiAgICAgVGl0bGUgICAgICAgIDogREhD UCBPcHRpb24gZm9yIEhvbWUgSW5mb3JtYXRpb24gDQo+IERpc2NvdmVyeSBpbiBNSVB2Ng0KPiAg ICAgQXV0aG9yKHMpICAgIDogSC4gSmFuZywgZXQgYWwuDQo+ICAgICBGaWxlbmFtZSAgICA6IGRy YWZ0LWlldGYtbWlwNi1oaW9wdC0wMy50eHQNCj4gICAgIFBhZ2VzICAgICAgICA6IDE5DQo+ICAg ICBEYXRlICAgICAgICA6IDIwMDctNS0xNg0KPiAgICAgDQo+IFRoaXMgZHJhZnQgZGVmaW5lcyBh IERIQ1AtYmFzZWQgc2NoZW1lIHRvIGVuYWJsZSBkeW5hbWljIGRpc2NvdmVyeSBvZg0KPiAgICBN b2JpbGUgSVB2NiBob21lIGFnZW50IGFkZHJlc3MsIGhvbWUgYWdlbnQgRlFETiBhbmQgaG9tZSAN Cj4gc3VibmV0LiAgTmV3DQo+ICAgIERIQ1Agb3B0aW9ucyBhcmUgZGVmaW5lZCB0byBjYXJyeSB0 aGUgaW5mb3JtYXRpb24gZnJvbSBhIA0KPiBESENQIHNlcnZlcg0KPiAgICB0byB0aGUgREhDUCBj bGllbnQgcnVubmluZyBvbiB0aGUgbW9iaWxlIG5vZGUuDQo+IA0KPiBBIFVSTCBmb3IgdGhpcyBJ bnRlcm5ldC1EcmFmdCBpczoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtaWV0Zi1taXA2LWhpb3B0LTAzLnR4dA0KPiANCj4gVG8gcmVtb3ZlIHlvdXJzZWxmIGZy b20gdGhlIEktRCBBbm5vdW5jZW1lbnQgbGlzdCwgc2VuZCBhIA0KPiBtZXNzYWdlIHRvIGktZC1h bm5vdW5jZS1yZXF1ZXN0QGlldGYub3JnIHdpdGggdGhlIHdvcmQgDQo+IHVuc3Vic2NyaWJlIGlu IHRoZSBib2R5IG9mIHRoZSBtZXNzYWdlLiANCj4gWW91IGNhbiBhbHNvIHZpc2l0IGh0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL0ktRC1hbm5vdW5jZQ0KPiB0byBjaGFuZ2Ug eW91ciBzdWJzY3JpcHRpb24gc2V0dGluZ3MuDQo+IA0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFs c28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAuIExvZ2luIA0KPiB3aXRoIHRoZSB1c2VybmFt ZSAiYW5vbnltb3VzIiBhbmQgYSBwYXNzd29yZCBvZiB5b3VyIGUtbWFpbCANCj4gYWRkcmVzcy4g QWZ0ZXIgbG9nZ2luZyBpbiwgdHlwZSAiY2QgaW50ZXJuZXQtZHJhZnRzIiBhbmQgdGhlbiANCj4g ImdldCBkcmFmdC1pZXRmLW1pcDYtaGlvcHQtMDMudHh0Ii4NCj4gDQo+IEEgbGlzdCBvZiBJbnRl cm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMgY2FuIGJlIGZvdW5kIGluIA0KPiBodHRwOi8vd3d3Lmll dGYub3JnL3NoYWRvdy5odG1sIG9yIA0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93 LXNpdGVzLnR4dA0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGNhbiBhbHNvIGJlIG9idGFpbmVkIGJ5 IGUtbWFpbC4NCj4gDQo+IFNlbmQgYSBtZXNzYWdlIHRvOg0KPiAgICAgbWFpbHNlcnZAaWV0Zi5v cmcuDQo+IEluIHRoZSBib2R5IHR5cGU6DQo+ICAgICAiRklMRSAvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtbWlwNi1oaW9wdC0wMy50eHQiLg0KPiAgICAgDQo+IE5PVEU6ICAgIFRoZSBtYWls IHNlcnZlciBhdCBpZXRmLm9yZyBjYW4gcmV0dXJuIHRoZSBkb2N1bWVudCBpbg0KPiAgICAgTUlN RS1lbmNvZGVkIGZvcm0gYnkgdXNpbmcgdGhlICJtcGFjayIgdXRpbGl0eS4gIFRvIHVzZSB0aGlz DQo+ICAgICBmZWF0dXJlLCBpbnNlcnQgdGhlIGNvbW1hbmQgIkVOQ09ESU5HIG1pbWUiIGJlZm9y ZSB0aGUgIkZJTEUiDQo+ICAgICBjb21tYW5kLiAgVG8gZGVjb2RlIHRoZSByZXNwb25zZShzKSwg eW91IHdpbGwgbmVlZCAibXVucGFjayIgb3INCj4gICAgIGEgTUlNRS1jb21wbGlhbnQgbWFpbCBy ZWFkZXIuICBEaWZmZXJlbnQgTUlNRS1jb21wbGlhbnQgDQo+IG1haWwgcmVhZGVycw0KPiAgICAg ZXhoaWJpdCBkaWZmZXJlbnQgYmVoYXZpb3IsIGVzcGVjaWFsbHkgd2hlbiBkZWFsaW5nIHdpdGgN Cj4gICAgICJtdWx0aXBhcnQiIE1JTUUgbWVzc2FnZXMgKGkuZS4gZG9jdW1lbnRzIHdoaWNoIGhh dmUgYmVlbiBzcGxpdA0KPiAgICAgdXAgaW50byBtdWx0aXBsZSBtZXNzYWdlcyksIHNvIGNoZWNr IHlvdXIgbG9jYWwgZG9jdW1lbnRhdGlvbiBvbg0KPiAgICAgaG93IHRvIG1hbmlwdWxhdGUgdGhl c2UgbWVzc2FnZXMuDQo+IA0KPiBCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBh IE1JTUUgY29tcGxpYW50IG1haWwgDQo+IHJlYWRlciBpbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0 aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSANCj4gdmVyc2lvbiBvZiB0aGUgSW50ZXJuZXQtRHJh ZnQuDQo+IA0KDQoNCg== --===============1444457525== 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 --===============1444457525==-- From mip6-bounces@ietf.org Mon Jun 04 04:11: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 1Hv7f6-0004pI-GR; Mon, 04 Jun 2007 04:11:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv7f5-0004oy-AG; Mon, 04 Jun 2007 04:11:35 -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 1Hv7ew-0003LO-U1; Mon, 04 Jun 2007 04:11:35 -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 l548BCd9032495; Mon, 4 Jun 2007 11:11:24 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 11:11:05 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 11:11:05 +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 Date: Mon, 4 Jun 2007 11:11:04 +0300 Message-ID: <58357EDC7884E24BAD684C1B2D91F96D059F8A78@trebe101.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call toclose issue 93 Thread-Index: AceklOi6J29uFhCIEdyx6wARJNUNiAB6oiUw References: <46608721.1030902@levkowetz.com> From: To: , X-OriginalArrivalTime: 04 Jun 2007 08:11:05.0066 (UTC) FILETIME=[E5D9C4A0:01C7A67F] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: nemo@ietf.org, mip6@ietf.org Subject: [Mip6] RE: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call toclose 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 Hi, Just to clarify my position on this issue, my preference was option 1 for now but reserve option 2 for extending the protocol to support e.g. GRE later if seen necessary. Cheers, Markku=20 >-----Original Message----- >From: ext Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 >Sent: 02 June, 2007 00:36 >To: Levkowetz >Cc: nemo@ietf.org; Mobile IPv6 Mailing List >Subject: Re: [nemo] Summary and conclusion of: DS-MIP6 -=20 >Consensus call toclose issue 93 > > > >Vijay D. - Option 4 originally and then changed to Option 2=20 >Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3=20 >Ahmad Muhanna - Option 3 Alex Petrescu - Option 1=20 >(Interpreted) George T. - Option 1 Mohamed Khalil - Option 3=20 >Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. -=20 >Option 1 (Interpreted) > >So we have a sort of a tie if you strictly go by count. >If I were to express my own opinion (non-chair-hat), I would=20 >go with option 1 as well for the current DS-MIP6 proposal=20 >(aligned with my earlier email that if and when GRE is planned=20 >for use, another UDP port can be reserved... But for now=20 >option 1). That would break any deadlock issues. > >Or the other way is to let the chairs decide what is the sense=20 >of the discussion on the ML and from the perspective of the=20 >charter/scope and urgency of this protocol. And from this=20 >angle as well, I would stick by my conclusion, i.e option 1. > >-Raj > > >On 6/1/07 3:52 PM, "ext Henrik Levkowetz" wrote: > >> Hi Raj, >>=20 >> On 2007-06-01 21:46 Basavaraj Patil said the following: >>> So after an extensive discussion on this topic which spun=20 >off into a=20 >>> discussion about the need/use for GRE, I would like to summarize=20 >>> where we are with the options that we have. >>>=20 >>> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the=20 >>> protocol header following the UDP header" is good enough. >>=20 >> Could you give us an indication of who preferred which option? You=20 >> seem to be very clear about the outcome, while it was far=20 >from obvious=20 >> to me that the counts turned out to support above conclusion... >>=20 >>=20 >> Henrik >>=20 >>> So it implies no changes to the current text in the DS-MIP6=20 >I-D w.r.t=20 >>> this issue are needed. >>>=20 >>>=20 >>> It was pointed out that in the future if GRE was determined as a=20 >>> protocol that needs to be supported as well either for=20 >MIP6, NEMO or=20 >>> PMIP6 then it would be specified in the appropriate WG and=20 >a UDP port=20 >>> reserved for the same. In such a case it would essentially be the=20 >>> equivalent of option 2 in the choices list (below). >>>=20 >>> At this time, the need for GRE especially in the scope of DS-MIP6=20 >>> which is primarily MIP6 and NEMO is not proven. Hence we will move=20 >>> forward with Option 1 and close this issue. >>>=20 >>> -Raj >>>=20 >>>=20 >>>=20 >>> On 5/8/07 4:16 PM, "ext Basavaraj Patil"=20 > wrote: >>>=20 >>>> Hello, >>>>=20 >>>> The DS-MIP6 I-D =20 >still has=20 >>>> issue 93 open. This was discussed at IETF68. Vijay presented 4=20 >>>> 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 was the=20 >>>> 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=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=20 >>>> 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.)=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 on the=20 >>>> MIP6 mailing list. >>>>=20 >>>> -Raj >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> 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 Mon Jun 04 04:32: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 1Hv7z5-0006r9-WC; Mon, 04 Jun 2007 04:32:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv7z4-0006r3-EO for mip6@ietf.org; Mon, 04 Jun 2007 04:32:14 -0400 Received: from mxs1.siemens.at ([194.138.12.131] helo=atvies1zqx.siemens.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv7z1-0001Cf-0P for mip6@ietf.org; Mon, 04 Jun 2007 04:32:14 -0400 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by atvies1zqx.siemens.at with ESMTP id l548Vi7R001709; Mon, 4 Jun 2007 10:31: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 l548Vct5028821; Mon, 4 Jun 2007 10:31:43 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 10:30:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: [Mip6] I-D ACTION:draft-ietf-mip6-hiopt-03.txt Date: Mon, 4 Jun 2007 10:30:55 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD6802241AA5@zagh223a.ww300.siemens.net> In-Reply-To: <12633907.1277591180920917487.JavaMail.weblogic@ep_ml28> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Mip6] I-D ACTION:draft-ietf-mip6-hiopt-03.txt Thread-Index: AcemSLlRilt1QvRZSoGA6fhIww1bwAAN0Qkg References: <12633907.1277591180920917487.JavaMail.weblogic@ep_ml28> From: "Premec, Domagoj" To: , X-OriginalArrivalTime: 04 Jun 2007 08:30:57.0174 (UTC) FILETIME=[AC670360:01C7A682] 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::070604103144-6ED2CBB0-6A57A4E6/0-0/0-15 X-purgate-size: 7115/0 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 Heejin, > In my answer, "a single Home Network information option with=20 > multiple sub-options" means per each a single Home Network=20 > Identifier option. OK, I misunderstood this sentence, I thought that there will be a total = of 1 HN information option in the response. > That is, the number of HN Information=20 > option in the reply is the same as the number of HN=20 > Information option in the request, and the "id-type" will be=20 > added in an HN information option for mapping for each=20 > option. We fixed this and the next version will cover this. Mobile node can include several HN Identifier options with the same = id-tpye (1) in its request. In this case including the id-type in an HN = information option will not be enough to enable the matching. One = possibility may be to require that the HN information options appear in = the same order as HN Identifier options and that the matching is based = on the sequential order of options. thanks domagoj > -----Original Message----- > From: Heejin Jang [mailto:heejin.jang@samsung.com]=20 > Sent: 04. lipanj 2007 03:35 > To: Premec, Domagoj; Kilian.Weniger@eu.panasonic.com > Cc: mip6@ietf.org > Subject: Re: RE: [Mip6] I-D ACTION:draft-ietf-mip6-hiopt-03.txt >=20 > Hi, Domagoj. > Thanks for your comment. > =20 > A few days ago, I answered as follows for Kilian's question in ML. > =20 > Kilian's Q> What should the DHCP server do if the MIP6 relay=20 > agent option contains multiple sub-options and one of the=20 > sub-options matches the NAI's realm whereas another one does=20 > not? This situation can happen if the AAAH sends home network=20 > information for mutliple MSPs to the NAS (e.g., for home=20 > MSP/MSA and other MSPs with trust relationship to MSA).=20 > Should the server respond with multiple Home Network=20 > Information Sub-options? > =20 > Heejin's A> A DHCP server extracts only the available HA info=20 > among the info privided by NAS (finally from AAA) and=20 > includes them in a single Home Network information option=20 > with multiple sub-options. If the server has no info for the=20 > specified id-type in Home Network, then it replies with=20 > opt-len=3D0 in a Home Network Information option. > =20 > In my answer, "a single Home Network information option with=20 > multiple sub-options" means per each a single Home Network=20 > Identifier option. That is, the number of HN Information=20 > option in the reply is the same as the number of HN=20 > Information option in the request, and the "id-type" will be=20 > added in an HN information option for mapping for each=20 > option. We fixed this and the next version will cover this. > Thanks. > =20 > - Best Regareds, > Heejin >=20 > ------- Original Message ------- > Sender : Premec, Domagoj > Date : 2007-06-01 00:56 > Title : RE: [Mip6] I-D ACTION:draft-ietf-mip6-hiopt-03.txt >=20 > Hi Heejin, >=20 > I have a clarification question: if the MN requests=20 > information about several target networks it will include=20 > several Home Network Identifier options. The following text=20 >=20 > > Multiple sub-options may exist in a Home Network=20 > Information option > > to carry more than one home information. >=20 > leaves impression that the response message contains only one=20 > Home Network Information option which carries the addresses,=20 > prefixes and/or FQDNs of all target networks. I could be=20 > wrong, but I couldn't find any text that is specific about this.=20 >=20 > If the information about multiple target networks is carried=20 > in a single Home Network Information option, the MN may not=20 > be able to match the info from the Home Network Information=20 > option to a particular target network. For example, the MN=20 > may ask for infomation about operator1.com and operator2.com,=20 > and the Home Network Information option may contain the home=20 > subnet prefix and the FQDN. How would the MN know if both=20 > suboptions carry information about operator1.com or if subnet=20 > belongs to operator1 and FQDN to operator 2? >=20 > thanks > domagoj >=20 >=20 > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > 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 > > 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 Group of=20 > > 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 > > =20 > > This draft defines a DHCP-based scheme to enable dynamic=20 > discovery of > > Mobile IPv6 home agent address, home agent FQDN and home=20 > subnet. =20 > > New > > DHCP options are defined to carry the information from a DHCP=20 > > 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=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-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". > > =20 > > 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=20 > > 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. > >=20 >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 04 15:52: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 1HvIb6-0005xh-GL; Mon, 04 Jun 2007 15:52:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIZV-0003fO-FU; Mon, 04 Jun 2007 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HvIZV-0002fd-1X; Mon, 04 Jun 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 CC240175FE; Mon, 4 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HvIZ0-0002iG-Ig; Mon, 04 Jun 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: Mon, 04 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-integrated-dhc-04.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 : MIP6-bootstrapping for the Integrated Scenario Author(s) : K. Chowdhury, A. Yegin Filename : draft-ietf-mip6-bootstrapping-integrated-dhc-04.txt Pages : 18 Date : 2007-6-4 Mobile IPv6 bootstrapping can be categorized into two primary scenarios, the split scenario and the integrated scenario. In the split scenario, the mobile node's mobility service is authorized by a different service authorizer than the network access authorizer. In the the integrated scenario, the mobile node's mobility service is authorized by the same service authorizer as the network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-04.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-integrated-dhc-04.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-integrated-dhc-04.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-6-4142747.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-bootstrapping-integrated-dhc-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-4142747.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 Mon Jun 04 16:59: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 1HvJe9-0002XZ-Om; Mon, 04 Jun 2007 16:59:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJe8-0002X3-Bv; Mon, 04 Jun 2007 16:59:24 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvJe7-0006v2-Or; Mon, 04 Jun 2007 16:59: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: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 -Consensuscall to close issue 93 Date: Mon, 4 Jun 2007 13:59:22 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 -Consensuscall to close issue 93 thread-index: Acek/wdV5Mb77tH2Swi5l/2MLoVHTgABj9NAAHlQ1DA= References: <20070602110447.WQAP4756.oaamta07sl.mx.bigpond.com@PC20005> From: "Vijay Devarapalli" To: "Hesham Soliman" , "Henrik Levkowetz" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc 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, =20 > =3D> The issue was raised against an existing solution, if=20 > there is no support > in the WG (6 people against and 5 for it) then clearly there=20 > is no agreement > that there is an issue to begin with. What are you suggesting=20 > we do?=20 I disagree with this. It is an open issue. Just because it is already there in the draft does not mean it gets to stay in the draft. 6:5 means we don't have a good way forward. It does not mean that there is no issue and the existing solution should stay in the draft. Vijay If > there is no support for the perceived issue then naturally=20 > it's rejected. I > don't think anyone is changing their mind if we ask the same=20 > question again > in the space of two weeks... >=20 > If a 6:5 or 5:4 means no concensus to you, then I'm surprised that you > accepted the same numbers as concensus on other issues, like=20 > the mapped > address one or issue 93. Should we repeat all those questions again?=20 >=20 > Hesham >=20 > >=20 > >=20 > > Henrik > >=20 > > > We've always asked for concencus to > > > change anything=20 > > > in the draft. The numbers that Raj sent clearly indicate=20 > > that there is no > > > concensus to change the draft. 5:4 is not concensus.=20 > > Therefore, I think > > > Raj's decision is correct. I hope we don't turn the IETF=20 > > into a voting > > > organisation, if we do then the whole process of providing=20 > > a vote would be > > > different from what we do today.=20 > > >=20 > > > Hesham=20 > > >=20 > > >> -----Original Message----- > > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > > >> Sent: Saturday, June 02, 2007 9:28 AM > > >> To: Narayanan, Vidya > > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Basavaraj Patil > > >> Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of:=20 > > >> DS-MIP6 - Consensuscall to close issue 93 > > >> > > >> Hi Vidya, Rai, > > >> > > >> On 2007-06-02 00:13 Narayanan, Vidya said the following: > > >>> FWIW, I had also supported going with Option 1 for DS-MIP6.=20 > > >> Of course that matters, Vidya, but the more important thing here > > >> is that it's pretty clear to me that there is *no*=20 > rough consensus > > >> present. > > >> > > >> Please don't manufacture one when there isn't one; if there > > >> really isn't one, do another call for discussion and/or show > > >> of hands, and if the group is deadlocked, use 3929. > > >> > > >> I can't accept this pronouncement of a consensus, rough or not, > > >> in the group, neither from my observation of the discussion or > > >> from the count. > > >> > > >> > > >> Henrik > > >> > > >> > > >>> Vidya=20 > > >>> > > >>>> -----Original Message----- > > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > > >>>> Sent: Friday, June 01, 2007 2:36 PM > > >>>> To: Levkowetz > > >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6=20 > > >>>> - Consensus call to close issue 93 > > >>>> > > >>>> > > >>>> > > >>>> Vijay D. - Option 4 originally and then changed to Option 2=20 > > >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3=20 > > >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1=20 > > >>>> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3=20 > > >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. -=20 > > >>>> Option 1 (Interpreted) > > >>>> > > >>>> So we have a sort of a tie if you strictly go by count. > > >>>> If I were to express my own opinion (non-chair-hat), I would=20 > > >>>> go with option 1 as well for the current DS-MIP6 proposal=20 > > >>>> (aligned with my earlier email that if and when GRE is=20 > > >>>> planned for use, another UDP port can be reserved... But for=20 > > >>>> now option 1). That would break any deadlock issues. > > >>>> > > >>>> Or the other way is to let the chairs decide what is the=20 > > >>>> sense of the discussion on the ML and from the perspective of=20 > > >>>> the charter/scope and urgency of this protocol. And from this=20 > > >>>> angle as well, I would stick by my conclusion, i.e option 1. > > >>>> > > >>>> -Raj > > >>>> > > >>>> > > >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz"=20 > > >>>> wrote: > > >>>> > > >>>>> Hi Raj, > > >>>>> > > >>>>> On 2007-06-01 21:46 Basavaraj Patil said the following: > > >>>>>> So after an extensive discussion on this topic which spun=20 > > >>>> off into a=20 > > >>>>>> discussion about the need/use for GRE, I would like to=20 > > >> summarize=20 > > >>>>>> where we are with the options that we have. > > >>>>>> > > >>>>>> Conclusion was that for DS-MIP6, Option 1 which is : "=20 > > >> Parse the=20 > > >>>>>> protocol header following the UDP header" is good enough. > > >>>>> Could you give us an indication of who preferred which=20 > > >> option? You=20 > > >>>>> seem to be very clear about the outcome, while it was far=20 > > >>>> from obvious=20 > > >>>>> to me that the counts turned out to support above=20 > conclusion... > > >>>>> > > >>>>> > > >>>>> Henrik > > >>>>> > > >>>>>> So it implies no changes to the current text in the=20 > > >>>> DS-MIP6 I-D w.r.t=20 > > >>>>>> this issue are needed. > > >>>>>> > > >>>>>> > > >>>>>> It was pointed out that in the future if GRE was=20 > > >> determined as a=20 > > >>>>>> protocol that needs to be supported as well either for=20 > > >>>> MIP6, NEMO or=20 > > >>>>>> PMIP6 then it would be specified in the appropriate WG and=20 > > >>>> a UDP port=20 > > >>>>>> reserved for the same. In such a case it would=20 > > >> essentially be the=20 > > >>>>>> equivalent of option 2 in the choices list (below). > > >>>>>> > > >>>>>> At this time, the need for GRE especially in the scope=20 > > >> of DS-MIP6=20 > > >>>>>> which is primarily MIP6 and NEMO is not proven. Hence=20 > > >> we will move=20 > > >>>>>> forward with Option 1 and close this issue. > > >>>>>> > > >>>>>> -Raj > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil"=20 > > >>>> wrote: > > >>>>>>> Hello, > > >>>>>>> > > >>>>>>> The DS-MIP6 I-D =20 > > >>>> still has=20 > > >>>>>>> issue 93 open. This was discussed at IETF68. Vijay=20 > > presented 4=20 > > >>>>>>> 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=20 > > >>>> with the=20 > > >>>>>>> I-D. At the meeting itself, I got the sense that=20 > > >> option 3 was the=20 > > >>>>>>> one that had the least impact and easy to implement. > > >>>>>>> > > >>>>>>> Please consider this email as a consensus call for=20 > > >> issue 93. The=20 > > >>>>>>> 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=20 > > >>>>>>> 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=20 > > >>>>>>> protocol being encapsulated in the UDP header. > > >>>>>>> > > >>>>>>> Choices are: > > >>>>>>> 1. Parse the protocol header following the UDP header 2.=20 > > >>>> Reserve a=20 > > >>>>>>> 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.)=20 > > >>>>>>> 3. One reserved UDP port and a DS-MIP6 "tunnel=20 > type message" > > >>>>>>> 4. Encapsulated protocol header type is indicated in the=20 > > >>>> BU message > > >>>>>>> Pros and cons of these choices are in the slides that=20 > > >>>> were presented=20 > > >>>>>>> at IETF68 (see URL above). > > >>>>>>> > > >>>>>>> Please provide your opinions and comments by May 15th,=20 > > >> 07 on the=20 > > >>>>>>> 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 > > >>>> > > >> > > >=20 > > >=20 > > >=20 > >=20 >=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 From mip6-bounces@ietf.org Mon Jun 04 17:04: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 1HvJjF-0006UC-TY; Mon, 04 Jun 2007 17:04:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJjE-0006U7-B6 for mip6@ietf.org; Mon, 04 Jun 2007 17:04:40 -0400 Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvJjD-0007Y8-Nq for mip6@ietf.org; Mon, 04 Jun 2007 17:04:40 -0400 Received: from smtp1.fc.hp.com (smtp.fc.hp.com [15.15.136.127]) by atlrel7.hp.com (Postfix) with ESMTP id 3B35535332; Mon, 4 Jun 2007 17:04:10 -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 51E4E142F3F; Mon, 4 Jun 2007 21:04:05 +0000 (UTC) Message-ID: <46647E44.6030000@hp.com> Date: Mon, 04 Jun 2007 17:04:04 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.10 (X11/20070403) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [Mip6] Consensus call: Make I-D draft-haley-mip6-mh-signaling-02.txt a WG doc References: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C3F@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C3F@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: 1e467ff145ef391eb7b594ef62b8301f Cc: Mobile IPv6 Mailing List , ext 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, Ahmad, Sri and I have talked off-line about how to go forward with draft-haley and support draft-muhanna better. We've come to the following conclusion (someone update if I got this wrong). Draft-haley will define a Generic Notification Message (GNM) which is a new MH type, and also define two new sub-types - one for Signaling Request, one for Signaling Reply (or some wording like that). The structures would look something like this: Generic Notification Message (w/MH message pieces, MH Type TBD) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Proto | Header Len | MH Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | GNM Type/Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In essence, the message is just a container to transport notification messages between mobility entities. They we'd define two Sub-types with the same semantics of the current messages in draft-haley: Signaling Request (GNM Type TBD): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number |A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signaling Reply (GNM Type TBD): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This would give someone that wants to use the semantics of the Signaling Messages an easy framework for implentation (sequencing, retransmission, etc). All they would have to do is define a mobility option with their data to go "inside". Ahmad would define a new GNM Sub-type for revocation, and whatever structures and options to go with it. I'll update draft-haley with these changes if there are no objections. Thanks to Ahmad for the suggestions. -Brian Ahmad Muhanna wrote: > Hello, > > My understanding that the scope of draft-haley is as follows: > > o A generic container which can be used to communicate multiple > functionalities while preserving the MH types. > o Introduce a Generic Notification Messages and Generic Notification > mechanism > that can be used to communicate several common notification event(s) > between > the HA and the MN. > > Having said that, I would like to propose a small change to the current > Draft-haley revision 02 which would hopefully enrich and enhance the > draft. > > The following summarize the proposed changes: > ============================================= > 1. Define the first two bytes, of the current generic notification > message, and call them , for example, Generic Mobility Container, > GMC, or XYZ. > > 2. The Generic Mobility Container is 2 bytes length and can have up > to 64k > different values which we can call, for example, GMC Type. i.e. > > Generic Notification Request message, Generic Notification Ack, > Binding Revocation Indication message, Binding Revocation Ack, > etc. > > 3. Every common functionality defines its own messages and mechanism > including its own mechanism as fits the need of the specified > functionality. > > 4. Any functionality, e.g. Generic Notification, may define the use > of any MH option inside its own messages or define new ones. > > Here is the format, let us use the Generic Notification and Binding > Revocation as examples: > > 1. Generic Mobility Container Message > ===================================== > This Signaling Generic Mobility Container Message uses the MH Type value > (TBD). > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | GMC Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Message Data . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 2. Generic Notification > ======================= > > Let us assume that this application requires two messages, a Request and > > an acknowledgement. > > 3.1. Generic Notification Request > ================================== > This Generic Notification Request uses a GMC Type of (TBD). > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | GMC Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Generic Notification Request . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 3.2. Generic Notification Ack > ============================== > This Generic Notification Ack uses a GMC Type of (TBD). > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | GMC Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Generic Notification Ack . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 3. Binding Revocation > ====================== > > The following are the revocation messages that are defined by > the Binding Revocation Functionality as specified by the Binding > Revocation for IPv6 Mobility draft. > > 2.1. Binding Revocation Indication > ================================== > > This Binding Revocation Indication uses a GMC Type of (TBD). > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | GMC Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Binding Revocation Indication . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 2.2. Binding Revocation Acknowledgement > ======================================== > This Binding Revocation Acknowledgement uses a GMC Type (TBD). > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | GMC Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Binding Revocation Acknowledgement . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Finally and as a suggestion, I would like to suggest that draft-haley > address two things: > 1. Introducing the Generic Mobility Container, GMC. > 2. Define the Generic Notification Messages and the related Mechanism. > > While the Binding Revocation for IPv6 Mobility draft can define the > Binding > Revocation messages and the binding revocation mechanism. > > > Best Regards, > Ahmad > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Wednesday, May 30, 2007 12:23 PM >> To: Mobile IPv6 Mailing List >> 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 >> >> >> 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 >> > > > _______________________________________________ > 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 Jun 04 17:05: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 1HvJju-0007tt-0V; Mon, 04 Jun 2007 17:05:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJjs-0007qa-Rj; Mon, 04 Jun 2007 17:05:20 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvJjs-0007gl-Fp; Mon, 04 Jun 2007 17:05:20 -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] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Date: Mon, 4 Jun 2007 14:05:19 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 thread-index: AceRtiHFYHRnMf2pEduUrQARJNUNiASz3DPBAJmM6QA= References: From: "Vijay Devarapalli" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" , 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 Raj, This is fine with me. But today we already have option 2. One reserved UDP port for IPv4/v6 and another for ESP encapsulation of DS-MIPv6 tunneled packets.=20 Vijay > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Friday, June 01, 2007 12:47 PM > To: ext Basavaraj Patil; Mobile IPv6 Mailing List; nemo@ietf.org > Subject: [Mip6] Summary and conclusion of: DS-MIP6 -=20 > Consensus call to close issue 93 >=20 >=20 > So after an extensive discussion on this topic which spun off into a > discussion about the need/use for GRE, I would like to=20 > summarize where we > are with the options that we have. >=20 > Conclusion was that for DS-MIP6, Option 1 which is : " Parse=20 > the protocol > header following the UDP header" is good enough. >=20 > So it implies no changes to the current text in the DS-MIP6=20 > I-D w.r.t this > issue are needed. >=20 >=20 > It was pointed out that in the future if GRE was determined=20 > as a protocol > that needs to be supported as well either for MIP6, NEMO or=20 > PMIP6 then it > would be specified in the appropriate WG and a UDP port=20 > reserved for the > same. In such a case it would essentially be the equivalent=20 > of option 2 in > the choices list (below). >=20 > At this time, the need for GRE especially in the scope of=20 > DS-MIP6 which is > primarily MIP6 and NEMO is not proven. Hence we will move forward with > Option 1 and close this issue. >=20 > -Raj >=20 >=20 >=20 > On 5/8/07 4:16 PM, "ext Basavaraj Patil"=20 > wrote: >=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 > > 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 > > 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=20 > 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 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 04 17:19: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 1HvJx6-00041d-UU; Mon, 04 Jun 2007 17:19:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJx5-00041K-EM for mip6@ietf.org; Mon, 04 Jun 2007 17:18:59 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvJx3-00016w-KO for mip6@ietf.org; Mon, 04 Jun 2007 17:18:59 -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] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Date: Mon, 4 Jun 2007 14:18:56 -0700 Message-ID: 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+sACIZQUAACN7JpACJEfuAA1s5dkA== References: <7CCD07160348804497EF29E9EA5560D7024DA0CF@exchtewks2.starentnetworks.com> From: "Vijay Devarapalli" To: "Chowdhury, Kuntal" , "Basavaraj Patil" , "ext Ahmad Muhanna" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 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 would be a mobility option. And that is a clean design, IMHO. Vijay=20 > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 > Sent: Thursday, May 31, 2007 8:01 AM > To: Basavaraj Patil; ext Ahmad Muhanna; mip6@ietf.org > Subject: RE: [Mip6] FW: I-D=20 > ACTION:draft-muhanna-mip6-binding-revocation-00.txt >=20 > Hi Raj, >=20 > 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 >=20 > Embedding a message within another message is not a clean=20 > design, IMHO. > I think the scope of the two documents should be left as is: >=20 > Mh-signaling message: sending opaque TLVs > Revocation message: revoke mobility binding >=20 > -Kuntal >=20 >=20 > > -----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=20 > 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=20 > 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=20 > 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=20 > 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=20 > 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=20 > 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=20 > 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=20 > 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=20 > 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=20 > in Mobile > > > IPv6 > > >>> Specificaion [RFC-3775] and PMIPv6 [PMIP6-SPEC]. =20 > 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=20 > 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=20 > 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=20 > 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=20 > information > of > > > Starent Networks, Corp. The information transmitted may=20 > 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=20 > 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." >=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 Mon Jun 04 17: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 1HvK1e-0005Nw-2Q; Mon, 04 Jun 2007 17:23:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvK1c-0005Nm-IX for mip6@ietf.org; Mon, 04 Jun 2007 17:23:40 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvK1c-00028a-6m for mip6@ietf.org; Mon, 04 Jun 2007 17:23:40 -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] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Date: Mon, 4 Jun 2007 14:23:39 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt thread-index: AcefBjF6PDbVk4yIQouQBdhGOf5ixAAAEJnwAflx2DA= References: <6FC4416DDE56C44DA0AEE67BC7CA43711486145C@zrc2hxm2.corp.nortel.com> From: "Vijay Devarapalli" To: "Ahmad Muhanna" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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, I don't see a need for reserving two mobility header messages for this mechanism. My preference is to use the generic mobility header signaling message (draft-haley-mip6-mh-signaling) and=20 define mobility options to carry the revocation information. You=20 can extend the mobility option as much as you want to indicate=20 the various error codes and the various identifiers used by the mobile node. Vijay > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 > Sent: Monday, May 28, 2007 5:44 AM > To: mip6@ietf.org > Subject: [Mip6] FW: I-D=20 > ACTION:draft-muhanna-mip6-binding-revocation-00.txt >=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=20 > 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]=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 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > 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 > =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=20 > registration > binding, which could have been established using a Client=20 > Mobile IPv6 > or a Proxy Mobile IPv6 signaling. The proposed revocation=20 > 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: > http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding > -revocatio > 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=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-muhanna-mip6-binding-revocation-00.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-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. >=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 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 04 17:33: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 1HvKAh-0003J1-Ou; Mon, 04 Jun 2007 17:33:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvKAf-0003Fl-De for mip6@ietf.org; Mon, 04 Jun 2007 17:33:01 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvK6C-00038b-3k for mip6@ietf.org; Mon, 04 Jun 2007 17:28:24 -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 l54LSJE11490; Mon, 4 Jun 2007 21:28:19 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: Mon, 4 Jun 2007 16:28:18 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114B495EE@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: AcefBjF6PDbVk4yIQouQBdhGOf5ixAAAEJnwAflx2DAAAJkrAA== References: <6FC4416DDE56C44DA0AEE67BC7CA43711486145C@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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 Vijay, Thanks for you suggestion. Brian, Sri, and I (on behalf of muhanna et. Al.) agreed on a generic mechanism that draft-haley will adopt which will preserve the MH Types and at the same time gives flexibility for defining Binding revocation messages. Please take a look at the email Brian just posted few minutes back on the consensus call for adopting draft-haley as a wg document. Hope you would agree with that concept. Thanks again. Regards, Ahmad =20 > -----Original Message----- > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com]=20 > Sent: Monday, June 04, 2007 4:24 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 > Hi Ahmad, >=20 > I don't see a need for reserving two mobility header messages=20 > for this mechanism. My preference is to use the generic=20 > mobility header signaling message=20 > (draft-haley-mip6-mh-signaling) and define mobility options=20 > to carry the revocation information. You can extend the=20 > mobility option as much as you want to indicate the various=20 > error codes and the various identifiers used by the mobile node. >=20 > Vijay >=20 > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: Monday, May 28, 2007 5:44 AM > > To: mip6@ietf.org > > Subject: [Mip6] FW: I-D > > ACTION:draft-muhanna-mip6-binding-revocation-00.txt > >=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 > > =09 > > 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 Client Mobile=20 > > IPv6 > > or a Proxy Mobile IPv6 signaling. The proposed revocation=20 > > 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: > > http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding > > -revocatio > > 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 > > 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". > > =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=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 04 17:36: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 1HvKDe-00012T-En; Mon, 04 Jun 2007 17:36:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvKDd-00012O-3t for mip6@ietf.org; Mon, 04 Jun 2007 17:36:05 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvKDc-0003z9-Hv for mip6@ietf.org; Mon, 04 Jun 2007 17:36:05 -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] question on DS-MIPv6 security Date: Mon, 4 Jun 2007 14:36:02 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] question on DS-MIPv6 security thread-index: AcekORQS3FnWSBDKSwKA12zKkyDn+gCtfhcg References: From: "Vijay Devarapalli" To: "Karen E. Nielsen \(AH/LMD\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 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 Karen, The stuff that you cut and pasted from an earlier mail of mine shows reverse tunneled IPsec protected DS-MIPv6 traffic when=20 the mobile node is attached to an IPv4 access network. Nothing=20 about a binding update. If a mobile node chooses to reserve tunnel IPv6 traffic with ESP protection when it is attached to an IPv6 access network, the=20 packet format would be as follows. IPv6 hdr (src=3DMN-IPv6-CoA, dst=3DHA-IPv6)=20 ESP hdr=20 IPv6 (src=3DMN-IPv6-HoA, dst=3DCN)=20 Payload=20 If the same mobile node ends up on an IPv4 access network, the=20 packet format for the same traffic flow will be as follows. IPv4 hdr (src=3DMN-IPv4-CoA, dst=3DHA-IPv4)=20 UDP hdr=20 ESP hdr=20 IPv6 (src=3DMN-IPv6-HoA, dst=3DCN)=20 Payload=20 If the payload traffic does not need ESP tunnel mode protection, then the packet formats would be (when the mobile node is on an=20 IPv6 access network) IPv6 hdr (src=3DMN-IPv6-CoA, dst=3DHA-IPv6)=20 IPv6 (src=3DMN-IPv6-HoA, dst=3DCN)=20 Payload=20 and (when the mobile node is on an IPv4 access network) IPv4 hdr (src=3DMN-IPv4-CoA, dst=3DHA-IPv4)=20 UDP hdr=20 IPv6 (src=3DMN-IPv6-HoA, dst=3DCN)=20 Payload=20 Vijay > -----Original Message----- > From: Karen E. Nielsen (AH/LMD) [mailto:karen.e.nielsen@ericsson.com]=20 > Sent: Friday, June 01, 2007 3:39 AM > To: mip6@ietf.org > Subject: [Mip6] question on DS-MIPv6 security >=20 > Hi,=20 >=20 > A couple of questions to the security model of DS-MIPv6.=20 >=20 > The option for BU protection described below in option 2 in a=20 > mail cut from the archives=20 > seems to say UDP ESP tunnel encapsulation (RFC 3948). Is that=20 > correctly understood and if yes=20 > then why would you need a specific port for this usage in DS-MIPv6 ?=20 >=20 > ******snip*****=20 > To: "Basavaraj Patil" , "ext=20 > Tsirtsis, George" , "Sri=20 > Gundavelli" , "Hesham Soliman" at elevatemobile.com>, , =20 >=20 > Subject: RE: [Mip6] The use of GRE=20 > From: "Vijay Devarapalli" =20 > Date: Wed, 16 May 2007 14:33:59 -0700=20 > Cc:=20 > List-help: >=20 > List-id: mip6.ietf.org=20 > List-post: >=20 > List-subscribe: >,=20 > >=20 > List-unsubscribe:=20 > >,=20 > >=20 > References: =20 > Thread-index:=20 > AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAAa6kGYQAInDPQ=20 > Thread-topic: [Mip6] The use of GRE=20 >=20 > Hello Raj,=20 >=20 > We might actually end up with option 2. I see three reserved=20 > UDP ports with DS-MIPv6 already.=20 >=20 > 1. One UDP port indicating IPv4/IPv6. You parse the IP version=20 > field to figure out whether it is IPv4 or IPv6.=20 > 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=20 > IPv4 hdr (src=3DMN-IPv4-CoA, dst=3DHA-IPv4)=20 > UDP hdr=20 > ESP hdr=20 > IPv6 (src=3DMN-IPv6-HoA, dst=3DCN)=20 > Payload=20 > 3. One reserved UDP port for GRE encapsulation in DS-MIPv6.=20 >=20 > So this is almost option 2. :) Option 2 was one reserved port=20 > per protocol that follows the UDP header.=20 >=20 > Vijay=20 > *********************=20 >=20 > On the other hand, this option is not described in the DS-MIP=20 > draft which only seems to reference the destination=20 > option/routing header versions >=20 > of the BU and not the optional tunneling version from RFC=20 > 4877. I find it a little confusing that optional ways to=20 > transmit BU's are described on the list >=20 > and not in the draft - ?=20 > =20 > Secondly, looking into the destination option/routing header=20 > versions of the BU as described in Section 4.1 of DS-MIP,=20 > then these are described without security >=20 > headers, although they in Section 5 of DS-MIP are said to be=20 > protected using IPSec (as in standard [MIP] modulo RFC 4285).=20 > In this respect, >=20 > I am rather concerned with the processing of the stack:=20 > IPv4 header (src=3DV4ADDR, dst=3DHA_V4ADDR)=20 > UDP header=20 > IPv6 header (src=3DV4CoA, dst=3DHAADDR)=20 > DST-OPT HAO (IPv6 home address)=20 > ESP (transport)=20 > Mobility header BU [IPv4 HAO]=20 >=20 > as the appearance of ESP after a transport header will=20 > require a not very nice processing flow in the stack, unless=20 > IPSec is made to understand >=20 > "IP" headers of form IP-UDP-IP - Has this been discussed or=20 > is it not perceived as a problem by other implementators ?=20 >=20 > I have to admit that I have been away from this list in a=20 > very long time, and yes, I haven't=20 > checked the archives all that way back, but I hope you can, at least,=20 > let me know whether this has been thought through,=20 > and I just haven't grasped the=20 > details yet, or whether these details are still being finalized.=20 >=20 > Thanks,=20 > Karen=20 >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 04 17:40: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 1HvKHe-0004Di-Nk; Mon, 04 Jun 2007 17:40:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvKHd-0004C0-0W for mip6@ietf.org; Mon, 04 Jun 2007 17:40:13 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvKHa-0004bq-Ks for mip6@ietf.org; Mon, 04 Jun 2007 17:40:12 -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] question on DS-MIPv6 security Date: Mon, 4 Jun 2007 14:40:09 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] question on DS-MIPv6 security thread-index: AcekORQS3FnWSBDKSwKA12zKkyDn+gAB9i0wAAC3CqAAAFRBUAABy7MgAKkFmFA= References: <20070601120608.LFMN7523.oaamta05sl.mx.bigpond.com@PC20005> From: "Vijay Devarapalli" To: "Karen E. Nielsen \(AH/LMD\)" , "Hesham Soliman" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 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 Karen, RFC 4877 allows the use of ESP both in transport and tunnel mode protecting the Binding Update. The packet formats are already listed in 4877. The DS-MIPv6 spec shows the introduction of UDP header but only shows the use of ESP transport mode. ESP tunnel mode with UDP header is also possible. It is not however shown explicitly in the DS-MIPv6 specification. Vijay > -----Original Message----- > From: Karen E. Nielsen (AH/LMD) [mailto:karen.e.nielsen@ericsson.com]=20 > Sent: Friday, June 01, 2007 6:03 AM > To: Hesham Soliman; mip6@ietf.org > Subject: RE: [Mip6] question on DS-MIPv6 security >=20 > Hi, > =20 > No, to keep it in IP/IPSec kernel space I guess the options,=20 > as you have discussed on the list, is > specific UDP port for IP-UDP-IP or ESP UDP encapsulation and=20 > the option 2 tunnel BU format. > =20 > I do not want to attempt to reopen this discussion. I have a=20 > better idea about where the spec is now. > Thanks. > =20 > Karen > =20 > =20 >=20 >=20 > ________________________________ >=20 > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: 1. juni 2007 14:06 > To: Karen E. Nielsen (AH/LMD); mip6@ietf.org > Subject: RE: [Mip6] question on DS-MIPv6 security > =09 > =09 > Ah, sure, that's a problem if you do implement this in=20 > user space. What can I say, let's hope NATs disappear! Not=20 > much else we can do about this.=20 > =20 > Hesham >=20 >=20 > ________________________________ >=20 > From: Karen E. Nielsen (AH/LMD)=20 > [mailto:karen.e.nielsen@ericsson.com]=20 > Sent: Friday, June 01, 2007 10:00 PM > To: Hesham Soliman; mip6@ietf.org > Subject: RE: [Mip6] question on DS-MIPv6 security > =09 > =09 > Hi, > =20 > The problem, I see, is the looping from higher=20 > transport layer, UDP, back to IP/IPSec processing.=20 > =20 > With ESP UDP encapsulation=20 > the processing of the full header=20 > IP-UDP-IP-IPSEC is kept in the IP/IPSec layer. > =20 > BR, Karen >=20 >=20 > ________________________________ >=20 > From: Hesham Soliman=20 > [mailto:Hesham@elevatemobile.com]=20 > Sent: 1. juni 2007 13:39 > To: Karen E. Nielsen (AH/LMD); mip6@ietf.org > Subject: RE: [Mip6] question on=20 > DS-MIPv6 security > =09 > =09 > Karen,=20 > =20 > Please ignore option 2 below, we're not=20 > doing this in the draft. This was part of a concensus call=20 > and we're leaving the draft as is today as a result of this call.=20 >=20 >=20 > Secondly, looking into the=20 > destination option/routing header versions of the BU as=20 > described in Section 4.1 of DS-MIP, then these are described=20 > without security >=20 > headers, although they in=20 > Section 5 of DS-MIP are said to be protected using IPSec (as=20 > in standard [MIP] modulo RFC 4285). In this respect, >=20 > I am rather concerned with the=20 > processing of the stack:=20 > IPv4 header (src=3DV4ADDR, dst=3DHA_V4ADDR)=20 > UDP header=20 > IPv6 header (src=3DV4CoA, dst=3DHAADDR)=20 > DST-OPT HAO (IPv6 home address)=20 > ESP (transport)=20 > Mobility header BU [IPv4 HAO]=20 >=20 > as the appearance of ESP after=20 > a transport header will require a not very nice processing=20 > flow in the stack, unless IPSec is made to understand >=20 > "IP" headers of form IP-UDP-IP=20 > - Has this been discussed or is it not perceived as a problem=20 > by other implementators ? =20 >=20 > =3D> I'm not sure I understand=20 > the problem you're seeing above. By the time IPsec gets this=20 > packet there would not be IPv4/UDP headers and it would look=20 > like a normal IPsec protected IPv6 packet.=20 >=20 > Hesham >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 04 17:48: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 1HvKPx-0000hu-5E; Mon, 04 Jun 2007 17:48:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvKPv-0000hc-MX for mip6@ietf.org; Mon, 04 Jun 2007 17:48:47 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvKPv-0005bf-1u for mip6@ietf.org; Mon, 04 Jun 2007 17:48:47 -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] Consensus call: MakeI-D draft-haley-mip6-mh-signaling-02.txt a WG doc Date: Mon, 4 Jun 2007 14:48:46 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Consensus call: MakeI-D draft-haley-mip6-mh-signaling-02.txt a WG doc thread-index: Acem6/zrF+vQgrFNSJCGpQwsl7+MWAABX/sA References: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C3F@zrc2hxm2.corp.nortel.com> <46647E44.6030000@hp.com> From: "Vijay Devarapalli" To: "Brian Haley" , "Basavaraj Patil" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 Cc: Mobile IPv6 Mailing List , ext 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 This is not making sense to me. We have two messages in the=20 current draft, the Mobility Header Signaling Request Message=20 and the Mobility Header Signaling Acknowledgement Message.=20 This is equivalent to the "Signaling request" and "Signaling response" messages below. One has to just define new mobility=20 options that go in the Signaling Request and Signaling=20 Acknowledgement Message.=20 I don't understand why you would want to define "subtype"=20 fields in this message. Please let me know what I am missing. Vijay > -----Original Message----- > From: Brian Haley [mailto:brian.haley@hp.com]=20 > Sent: Monday, June 04, 2007 2:04 PM > To: Basavaraj Patil > Cc: Mobile IPv6 Mailing List; ext Sri Gundavelli > Subject: Re: [Mip6] Consensus call: MakeI-D=20 > draft-haley-mip6-mh-signaling-02.txt a WG doc >=20 > Hi Raj, >=20 > Ahmad, Sri and I have talked off-line about how to go forward with=20 > draft-haley and support draft-muhanna better. We've come to the=20 > following conclusion (someone update if I got this wrong). >=20 > Draft-haley will define a Generic Notification Message (GNM)=20 > which is a=20 > new MH type, and also define two new sub-types - one for Signaling=20 > Request, one for Signaling Reply (or some wording like that). >=20 > The structures would look something like this: >=20 > Generic Notification Message (w/MH message pieces, MH Type TBD) >=20 > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload Proto | Header Len | MH Type | =20 > Reserved | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Checksum | GNM=20 > Type/Sub-Type | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > In essence, the message is just a container to transport notification=20 > messages between mobility entities. >=20 > They we'd define two Sub-types with the same semantics of the current=20 > messages in draft-haley: >=20 > Signaling Request (GNM Type TBD): >=20 > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number |A| Reserved =20 > | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Signaling Reply (GNM Type TBD): >=20 > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | Status | =20 > Reserved | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > This would give someone that wants to use the semantics of=20 > the Signaling=20 > Messages an easy framework for implentation (sequencing,=20 > retransmission,=20 > etc). All they would have to do is define a mobility option=20 > with their=20 > data to go "inside". >=20 > Ahmad would define a new GNM Sub-type for revocation, and whatever=20 > structures and options to go with it. >=20 > I'll update draft-haley with these changes if there are no objections. >=20 > Thanks to Ahmad for the suggestions. >=20 > -Brian >=20 >=20 > Ahmad Muhanna wrote: > > Hello, > > =20 > > My understanding that the scope of draft-haley is as follows: > >=20 > > o A generic container which can be used to communicate multiple=20 > > functionalities while preserving the MH types. > > o Introduce a Generic Notification Messages and Generic=20 > Notification > > mechanism=20 > > that can be used to communicate several common=20 > notification event(s) > > between=20 > > the HA and the MN. > >=20 > > Having said that, I would like to propose a small change to=20 > the current=20 > > Draft-haley revision 02 which would hopefully enrich and enhance the > > draft. > >=20 > > The following summarize the proposed changes: > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 1. Define the first two bytes, of the current generic=20 > notification > > message, and call them , for example, Generic=20 > Mobility Container, > > GMC, or XYZ. > >=20 > > 2. The Generic Mobility Container is 2 bytes length and=20 > can have up > > to 64k > > different values which we can call, for example, GMC=20 > Type. i.e. > >=20 > > Generic Notification Request message, Generic=20 > Notification Ack, > > Binding Revocation Indication message, Binding=20 > Revocation Ack, > > etc. > >=20 > > 3. Every common functionality defines its own messages=20 > and mechanism > > including its own mechanism as fits the need of the specified > > functionality. > >=20 > > 4. Any functionality, e.g. Generic Notification, may=20 > define the use=20 > > of any MH option inside its own messages or define new ones. > >=20 > > Here is the format, let us use the Generic Notification and Binding=20 > > Revocation as examples: > > =20 > > 1. Generic Mobility Container Message=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > > This Signaling Generic Mobility Container Message uses the=20 > MH Type value > > (TBD). > >=20 > >=20 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | GMC Type=20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | =20 > | > > . =20 > . > > . Message Data =20 > . > > . =20 > . > > | =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > >=20 > > 2. Generic Notification > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > Let us assume that this application requires two messages,=20 > a Request and > >=20 > > an acknowledgement. > >=20 > > 3.1. Generic Notification Request > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > This Generic Notification Request uses a GMC Type of (TBD). > >=20 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | GMC Type=20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | =20 > | > > . =20 > . > > . Generic Notification Request =20 > . > > . =20 > . > > | =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > 3.2. Generic Notification Ack > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > This Generic Notification Ack uses a GMC Type of (TBD). > >=20 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | GMC Type=20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | =20 > | > > . =20 > . > > . Generic Notification Ack =20 > . > > . =20 > . > > | =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > =20 > > 3. Binding Revocation > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > The following are the revocation messages that are defined by > > the Binding Revocation Functionality as specified by the Binding > > Revocation for IPv6 Mobility draft. > > =20 > > 2.1. Binding Revocation Indication > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > This Binding Revocation Indication uses a GMC Type of (TBD). > >=20 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | GMC Type=20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | =20 > | > > . =20 > . > > . Binding Revocation Indication =20 > . > > . =20 > . > > | =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > =20 > > 2.2. Binding Revocation Acknowledgement > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > This Binding Revocation Acknowledgement uses a GMC Type (TBD). > >=20 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | GMC Type=20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | =20 > | > > . =20 > . > > . Binding Revocation Acknowledgement =20 > . > > . =20 > . > > | =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > >=20 > > Finally and as a suggestion, I would like to suggest that=20 > draft-haley > > address two things: > > 1. Introducing the Generic Mobility Container, GMC. > > 2. Define the Generic Notification Messages and the related=20 > Mechanism. > >=20 > > While the Binding Revocation for IPv6 Mobility draft can define the > > Binding=20 > > Revocation messages and the binding revocation mechanism. > >=20 > >=20 > > Best Regards, > > Ahmad > >=20 > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > >> Sent: Wednesday, May 30, 2007 12:23 PM > >> To: Mobile IPv6 Mailing List > >> Cc: brian.haley@hp.com; ext Sri Gundavelli > >> Subject: [Mip6] Consensus call: Make I-D=20 > >> draft-haley-mip6-mh-signaling-02.txt a WG doc > >> > >> > >> Hello, > >> > >> At the Prague IETF (IETF68), the MIP6 WG discussed the=20 > following I-D: > >> Mobility Header Signaling Message=20 > >> > >> > >> There was consensus in the meeting to make this a WG=20 > >> document. We would like to obtain consensus on the WG ML=20 > >> prior to making it a WG doc. Please review the I-D and=20 > >> 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=20 > >> following the feedback from the WG members. > >> > >> Abstract of the I-D: > >> This document specifies a new Mobility Header message=20 > type that can > >> be used between a mobile node and home agent to signal an=20 > >> event that > >> requires attention. > >> > >> -Raj > >> > >> > >> _______________________________________________ > >> 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 Mon Jun 04 18:03: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 1HvKdh-0007UN-BZ; Mon, 04 Jun 2007 18:03:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvKdg-0007Tr-QY for mip6@ietf.org; Mon, 04 Jun 2007 18:03:00 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvKdg-00010M-7j for mip6@ietf.org; Mon, 04 Jun 2007 18:03:00 -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 l54M2qp18150; Mon, 4 Jun 2007 22:02: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] Consensus call: MakeI-D draft-haley-mip6-mh-signaling-02.txt a WG doc Date: Mon, 4 Jun 2007 17:02:47 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114B49706@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Consensus call: MakeI-D draft-haley-mip6-mh-signaling-02.txt a WG doc Thread-Index: Acem6/zrF+vQgrFNSJCGpQwsl7+MWAABX/sAAABBmdA= References: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C3F@zrc2hxm2.corp.nortel.com> <46647E44.6030000@hp.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "Brian Haley" , "Basavaraj Patil" X-Spam-Score: 0.0 (/) X-Scan-Signature: 715d0e6950aaebd45af78ef9318d0186 Cc: Mobile IPv6 Mailing List , ext 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, I am not sure why this does not make sense? Is there something specific that you do not like? The suggested mechanism defines a generic container mechanism and at the same time gives the freedom for some notification mechanisms to have its own specifics. Probably taking a look at all the discussion related to this topic would be a good idea. Regards, Ahmad =20 > -----Original Message----- > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com]=20 > Sent: Monday, June 04, 2007 4:49 PM > To: Brian Haley; Basavaraj Patil > Cc: Mobile IPv6 Mailing List; ext Sri Gundavelli > Subject: RE: [Mip6] Consensus call: MakeI-D=20 > draft-haley-mip6-mh-signaling-02.txt a WG doc >=20 > This is not making sense to me. We have two messages in the=20 > current draft, the Mobility Header Signaling Request Message=20 > and the Mobility Header Signaling Acknowledgement Message.=20 > This is equivalent to the "Signaling request" and "Signaling=20 > response" messages below. One has to just define new mobility=20 > options that go in the Signaling Request and Signaling=20 > Acknowledgement Message.=20 >=20 > I don't understand why you would want to define "subtype"=20 > fields in this message. Please let me know what I am missing. >=20 > Vijay >=20 > > -----Original Message----- > > From: Brian Haley [mailto:brian.haley@hp.com] > > Sent: Monday, June 04, 2007 2:04 PM > > To: Basavaraj Patil > > Cc: Mobile IPv6 Mailing List; ext Sri Gundavelli > > Subject: Re: [Mip6] Consensus call: MakeI-D=20 > > draft-haley-mip6-mh-signaling-02.txt a WG doc > >=20 > > Hi Raj, > >=20 > > Ahmad, Sri and I have talked off-line about how to go forward with=20 > > draft-haley and support draft-muhanna better. We've come to the=20 > > following conclusion (someone update if I got this wrong). > >=20 > > Draft-haley will define a Generic Notification Message=20 > (GNM) which is=20 > > a new MH type, and also define two new sub-types - one for=20 > Signaling=20 > > Request, one for Signaling Reply (or some wording like that). > >=20 > > The structures would look something like this: > >=20 > > Generic Notification Message (w/MH message pieces, MH Type TBD) > >=20 > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Payload Proto | Header Len | MH Type | =20 > > Reserved | > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Checksum | GNM=20 > > Type/Sub-Type | > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > In essence, the message is just a container to transport=20 > notification=20 > > messages between mobility entities. > >=20 > > They we'd define two Sub-types with the same semantics of=20 > the current=20 > > messages in draft-haley: > >=20 > > Signaling Request (GNM Type TBD): > >=20 > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Sequence Number |A| Reserved =20 > > | > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > Signaling Reply (GNM Type TBD): > >=20 > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Sequence Number | Status | =20 > > Reserved | > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > This would give someone that wants to use the semantics of the=20 > > Signaling Messages an easy framework for implentation (sequencing,=20 > > retransmission, etc). All they would have to do is define=20 > a mobility=20 > > option with their data to go "inside". > >=20 > > Ahmad would define a new GNM Sub-type for revocation, and whatever=20 > > structures and options to go with it. > >=20 > > I'll update draft-haley with these changes if there are no=20 > objections. > >=20 > > Thanks to Ahmad for the suggestions. > >=20 > > -Brian > >=20 > >=20 > > Ahmad Muhanna wrote: > > > Hello, > > > =20 > > > My understanding that the scope of draft-haley is as follows: > > >=20 > > > o A generic container which can be used to communicate multiple=20 > > > functionalities while preserving the MH types. > > > o Introduce a Generic Notification Messages and Generic > > Notification > > > mechanism=20 > > > that can be used to communicate several common > > notification event(s) > > > between=20 > > > the HA and the MN. > > >=20 > > > Having said that, I would like to propose a small change to > > the current > > > Draft-haley revision 02 which would hopefully enrich and=20 > enhance the=20 > > > draft. > > >=20 > > > The following summarize the proposed changes: > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > 1. Define the first two bytes, of the current generic > > notification > > > message, and call them , for example, Generic > > Mobility Container, > > > GMC, or XYZ. > > >=20 > > > 2. The Generic Mobility Container is 2 bytes length and > > can have up > > > to 64k > > > different values which we can call, for example, GMC > > Type. i.e. > > >=20 > > > Generic Notification Request message, Generic > > Notification Ack, > > > Binding Revocation Indication message, Binding > > Revocation Ack, > > > etc. > > >=20 > > > 3. Every common functionality defines its own messages > > and mechanism > > > including its own mechanism as fits the need of=20 > the specified=20 > > > functionality. > > >=20 > > > 4. Any functionality, e.g. Generic Notification, may > > define the use > > > of any MH option inside its own messages or define=20 > new ones. > > >=20 > > > Here is the format, let us use the Generic Notification=20 > and Binding=20 > > > Revocation as examples: > > > =20 > > > 1. Generic Mobility Container Message=20 > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > This Signaling Generic Mobility Container Message uses the > > MH Type value > > > (TBD). > > >=20 > > >=20 > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | GMC Type=20 > > | > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | =20 > > | > > > . =20 > > . > > > . Message Data =20 > > . > > > . =20 > > . > > > | =20 > > | > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >=20 > > >=20 > > > 2. Generic Notification > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >=20 > > > Let us assume that this application requires two messages, > > a Request and > > >=20 > > > an acknowledgement. > > >=20 > > > 3.1. Generic Notification Request > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > This Generic Notification Request uses a GMC Type of (TBD). > > >=20 > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | GMC Type=20 > > | > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | =20 > > | > > > . =20 > > . > > > . Generic Notification Request =20 > > . > > > . =20 > > . > > > | =20 > > | > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >=20 > > > 3.2. Generic Notification Ack > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > This Generic Notification Ack uses a GMC Type of (TBD). > > >=20 > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | GMC Type=20 > > | > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | =20 > > | > > > . =20 > > . > > > . Generic Notification Ack =20 > > . > > > . =20 > > . > > > | =20 > > | > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > =20 > > > 3. Binding Revocation > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >=20 > > > The following are the revocation messages that are defined by the=20 > > > Binding Revocation Functionality as specified by the Binding=20 > > > Revocation for IPv6 Mobility draft. > > > =20 > > > 2.1. Binding Revocation Indication > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > >=20 > > > This Binding Revocation Indication uses a GMC Type of (TBD). > > >=20 > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | GMC Type=20 > > | > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | =20 > > | > > > . =20 > > . > > > . Binding Revocation Indication =20 > > . > > > . =20 > > . > > > | =20 > > | > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > =20 > > > 2.2. Binding Revocation Acknowledgement=20 > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > This Binding Revocation Acknowledgement uses a GMC Type (TBD). > > >=20 > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | GMC Type=20 > > | > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | =20 > > | > > > . =20 > > . > > > . Binding Revocation Acknowledgement =20 > > . > > > . =20 > > . > > > | =20 > > | > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >=20 > > >=20 > > > Finally and as a suggestion, I would like to suggest that > > draft-haley > > > address two things: > > > 1. Introducing the Generic Mobility Container, GMC. > > > 2. Define the Generic Notification Messages and the related > > Mechanism. > > >=20 > > > While the Binding Revocation for IPv6 Mobility draft can=20 > define the=20 > > > Binding Revocation messages and the binding revocation mechanism. > > >=20 > > >=20 > > > Best Regards, > > > Ahmad > > >=20 > > >> -----Original Message----- > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > >> Sent: Wednesday, May 30, 2007 12:23 PM > > >> To: Mobile IPv6 Mailing List > > >> Cc: brian.haley@hp.com; ext Sri Gundavelli > > >> Subject: [Mip6] Consensus call: Make I-D=20 > > >> draft-haley-mip6-mh-signaling-02.txt a WG doc > > >> > > >> > > >> 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=20 > document. We=20 > > >> would like to obtain consensus on the WG ML prior to=20 > making it a WG=20 > > >> doc. Please review the I-D and indicate if you are in=20 > favor of this=20 > > >> I-D becoming a WG document. > > >> > > >> We will decide after June 10th, 07 the status of this=20 > I-D following=20 > > >> 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=20 > signal an event=20 > > >> that > > >> requires attention. > > >> > > >> -Raj > > >> > > >> > > >> _______________________________________________ > > >> 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 >=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 Mon Jun 04 18:22: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 1HvKwG-0003H4-9L; Mon, 04 Jun 2007 18:22:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvKwF-0003EE-E0 for mip6@ietf.org; Mon, 04 Jun 2007 18:22:11 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvKwC-0005R4-LV for mip6@ietf.org; Mon, 04 Jun 2007 18:22:11 -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] Consensus call: MakeI-D draft-haley-mip6-mh-signaling-02.txt a WG doc Date: Mon, 4 Jun 2007 15:22:07 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Consensus call: MakeI-D draft-haley-mip6-mh-signaling-02.txt a WG doc thread-index: Acem6/zrF+vQgrFNSJCGpQwsl7+MWAABX/sAAABBmdAAAPOgsA== References: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C3F@zrc2hxm2.corp.nortel.com> <46647E44.6030000@hp.com> <6FC4416DDE56C44DA0AEE67BC7CA437114B49706@zrc2hxm2.corp.nortel.com> From: "Vijay Devarapalli" To: "Ahmad Muhanna" , "Brian Haley" , "Basavaraj Patil" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e1884bf469cda400682762c3e8d96c9 Cc: Mobile IPv6 Mailing List , ext 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, I did go through all the emails on this topic.=20 > I am not sure why this does not make sense? Is there=20 > something specific > that you do not like? Not clear why you want to embed some subtypes inside the generic signaling message, whereas you could define mobility options for each specific application of the generic signaling message. Vijay >=20 > The suggested mechanism defines a generic container mechanism=20 > and at the > same time gives the freedom for some notification mechanisms=20 > to have its > own specifics. Probably taking a look at all the discussion related to > this topic would be a good idea. >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com]=20 > > Sent: Monday, June 04, 2007 4:49 PM > > To: Brian Haley; Basavaraj Patil > > Cc: Mobile IPv6 Mailing List; ext Sri Gundavelli > > Subject: RE: [Mip6] Consensus call: MakeI-D=20 > > draft-haley-mip6-mh-signaling-02.txt a WG doc > >=20 > > This is not making sense to me. We have two messages in the=20 > > current draft, the Mobility Header Signaling Request Message=20 > > and the Mobility Header Signaling Acknowledgement Message.=20 > > This is equivalent to the "Signaling request" and "Signaling=20 > > response" messages below. One has to just define new mobility=20 > > options that go in the Signaling Request and Signaling=20 > > Acknowledgement Message.=20 > >=20 > > I don't understand why you would want to define "subtype"=20 > > fields in this message. Please let me know what I am missing. > >=20 > > Vijay > >=20 > > > -----Original Message----- > > > From: Brian Haley [mailto:brian.haley@hp.com] > > > Sent: Monday, June 04, 2007 2:04 PM > > > To: Basavaraj Patil > > > Cc: Mobile IPv6 Mailing List; ext Sri Gundavelli > > > Subject: Re: [Mip6] Consensus call: MakeI-D=20 > > > draft-haley-mip6-mh-signaling-02.txt a WG doc > > >=20 > > > Hi Raj, > > >=20 > > > Ahmad, Sri and I have talked off-line about how to go=20 > forward with=20 > > > draft-haley and support draft-muhanna better. We've come to the=20 > > > following conclusion (someone update if I got this wrong). > > >=20 > > > Draft-haley will define a Generic Notification Message=20 > > (GNM) which is=20 > > > a new MH type, and also define two new sub-types - one for=20 > > Signaling=20 > > > Request, one for Signaling Reply (or some wording like that). > > >=20 > > > The structures would look something like this: > > >=20 > > > Generic Notification Message (w/MH message pieces, MH Type TBD) > > >=20 > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Payload Proto | Header Len | MH Type | =20 > > > Reserved | > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Checksum | GNM=20 > > > Type/Sub-Type | > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >=20 > > > In essence, the message is just a container to transport=20 > > notification=20 > > > messages between mobility entities. > > >=20 > > > They we'd define two Sub-types with the same semantics of=20 > > the current=20 > > > messages in draft-haley: > > >=20 > > > Signaling Request (GNM Type TBD): > > >=20 > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Sequence Number |A| Reserved =20 > > > | > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >=20 > > > Signaling Reply (GNM Type TBD): > > >=20 > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Sequence Number | Status | =20 > > > Reserved | > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >=20 > > > This would give someone that wants to use the semantics of the=20 > > > Signaling Messages an easy framework for implentation=20 > (sequencing,=20 > > > retransmission, etc). All they would have to do is define=20 > > a mobility=20 > > > option with their data to go "inside". > > >=20 > > > Ahmad would define a new GNM Sub-type for revocation, and=20 > whatever=20 > > > structures and options to go with it. > > >=20 > > > I'll update draft-haley with these changes if there are no=20 > > objections. > > >=20 > > > Thanks to Ahmad for the suggestions. > > >=20 > > > -Brian > > >=20 > > >=20 > > > Ahmad Muhanna wrote: > > > > Hello, > > > > =20 > > > > My understanding that the scope of draft-haley is as follows: > > > >=20 > > > > o A generic container which can be used to communicate=20 > multiple=20 > > > > functionalities while preserving the MH types. > > > > o Introduce a Generic Notification Messages and Generic > > > Notification > > > > mechanism=20 > > > > that can be used to communicate several common > > > notification event(s) > > > > between=20 > > > > the HA and the MN. > > > >=20 > > > > Having said that, I would like to propose a small change to > > > the current > > > > Draft-haley revision 02 which would hopefully enrich and=20 > > enhance the=20 > > > > draft. > > > >=20 > > > > The following summarize the proposed changes: > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > 1. Define the first two bytes, of the current generic > > > notification > > > > message, and call them , for example, Generic > > > Mobility Container, > > > > GMC, or XYZ. > > > >=20 > > > > 2. The Generic Mobility Container is 2 bytes length and > > > can have up > > > > to 64k > > > > different values which we can call, for example, GMC > > > Type. i.e. > > > >=20 > > > > Generic Notification Request message, Generic > > > Notification Ack, > > > > Binding Revocation Indication message, Binding > > > Revocation Ack, > > > > etc. > > > >=20 > > > > 3. Every common functionality defines its own messages > > > and mechanism > > > > including its own mechanism as fits the need of=20 > > the specified=20 > > > > functionality. > > > >=20 > > > > 4. Any functionality, e.g. Generic Notification, may > > > define the use > > > > of any MH option inside its own messages or define=20 > > new ones. > > > >=20 > > > > Here is the format, let us use the Generic Notification=20 > > and Binding=20 > > > > Revocation as examples: > > > > =20 > > > > 1. Generic Mobility Container Message=20 > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > This Signaling Generic Mobility Container Message uses the > > > MH Type value > > > > (TBD). > > > >=20 > > > >=20 > > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | GMC Type=20 > > > | > > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | =20 > > > | > > > > . =20 > > > . > > > > . Message Data =20 > > > . > > > > . =20 > > > . > > > > | =20 > > > | > > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >=20 > > > >=20 > > > > 2. Generic Notification > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >=20 > > > > Let us assume that this application requires two messages, > > > a Request and > > > >=20 > > > > an acknowledgement. > > > >=20 > > > > 3.1. Generic Notification Request > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > This Generic Notification Request uses a GMC Type of (TBD). > > > >=20 > > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | GMC Type=20 > > > | > > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | =20 > > > | > > > > . =20 > > > . > > > > . Generic Notification Request =20 > > > . > > > > . =20 > > > . > > > > | =20 > > > | > > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >=20 > > > > 3.2. Generic Notification Ack > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > > This Generic Notification Ack uses a GMC Type of (TBD). > > > >=20 > > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | GMC Type=20 > > > | > > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | =20 > > > | > > > > . =20 > > > . > > > > . Generic Notification Ack =20 > > > . > > > > . =20 > > > . > > > > | =20 > > > | > > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > =20 > > > > 3. Binding Revocation > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >=20 > > > > The following are the revocation messages that are=20 > defined by the=20 > > > > Binding Revocation Functionality as specified by the Binding=20 > > > > Revocation for IPv6 Mobility draft. > > > > =20 > > > > 2.1. Binding Revocation Indication > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >=20 > > > > This Binding Revocation Indication uses a GMC Type of (TBD). > > > >=20 > > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | GMC Type=20 > > > | > > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | =20 > > > | > > > > . =20 > > > . > > > > . Binding Revocation Indication =20 > > > . > > > > . =20 > > > . > > > > | =20 > > > | > > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > =20 > > > > 2.2. Binding Revocation Acknowledgement=20 > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > This Binding Revocation Acknowledgement uses a GMC Type (TBD). > > > >=20 > > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | GMC Type=20 > > > | > > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | =20 > > > | > > > > . =20 > > > . > > > > . Binding Revocation Acknowledgement =20 > > > . > > > > . =20 > > > . > > > > | =20 > > > | > > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >=20 > > > >=20 > > > > Finally and as a suggestion, I would like to suggest that > > > draft-haley > > > > address two things: > > > > 1. Introducing the Generic Mobility Container, GMC. > > > > 2. Define the Generic Notification Messages and the related > > > Mechanism. > > > >=20 > > > > While the Binding Revocation for IPv6 Mobility draft can=20 > > define the=20 > > > > Binding Revocation messages and the binding revocation=20 > mechanism. > > > >=20 > > > >=20 > > > > Best Regards, > > > > Ahmad > > > >=20 > > > >> -----Original Message----- > > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > >> Sent: Wednesday, May 30, 2007 12:23 PM > > > >> To: Mobile IPv6 Mailing List > > > >> Cc: brian.haley@hp.com; ext Sri Gundavelli > > > >> Subject: [Mip6] Consensus call: Make I-D=20 > > > >> draft-haley-mip6-mh-signaling-02.txt a WG doc > > > >> > > > >> > > > >> 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=20 > > document. We=20 > > > >> would like to obtain consensus on the WG ML prior to=20 > > making it a WG=20 > > > >> doc. Please review the I-D and indicate if you are in=20 > > favor of this=20 > > > >> I-D becoming a WG document. > > > >> > > > >> We will decide after June 10th, 07 the status of this=20 > > I-D following=20 > > > >> 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=20 > > signal an event=20 > > > >> that > > > >> requires attention. > > > >> > > > >> -Raj > > > >> > > > >> > > > >> _______________________________________________ > > > >> 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 > >=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 Mon Jun 04 19:09: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 1HvLg9-0007qz-Hu; Mon, 04 Jun 2007 19:09:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvLg8-0007qt-5x for mip6@ietf.org; Mon, 04 Jun 2007 19:09:36 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvLg7-00084V-Hk for mip6@ietf.org; Mon, 04 Jun 2007 19:09:36 -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 l54N9Sg19407; Mon, 4 Jun 2007 23:09:29 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] Consensus call: MakeI-D draft-haley-mip6-mh-signaling-02.txt a WG doc Date: Mon, 4 Jun 2007 18:09:24 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114B4982D@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Consensus call: MakeI-D draft-haley-mip6-mh-signaling-02.txt a WG doc Thread-Index: Acem6/zrF+vQgrFNSJCGpQwsl7+MWAABX/sAAABBmdAAAPOgsAAAdMnQ References: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C3F@zrc2hxm2.corp.nortel.com> <46647E44.6030000@hp.com> <6FC4416DDE56C44DA0AEE67BC7CA437114B49706@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "Brian Haley" , "Basavaraj Patil" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7cb76adb986247703cbb5582da68b5fc Cc: Mobile IPv6 Mailing List , ext 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, Please see comments inline. Regards, Ahmad =20 > Hi Ahmad, >=20 > I did go through all the emails on this topic.=20 >=20 > > I am not sure why this does not make sense? Is there something=20 > > specific that you do not like? >=20 > Not clear why you want to embed some subtypes inside the=20 > generic signaling message, whereas you could define mobility=20 > options for each specific application of the generic=20 > signaling message. [Ahmad] So you are against defining a generic mechanism that is flexible enough to avoid the strict assumption you just stated which requires all applications to fit all of its requirements/scenarios inside a single option. IMO, this is not the best approach that we need to take. Although you/we may think/imagine that the requirement set forth for the signaling request/response message is good enough for all possible applications for now, However, the proposed approach is more flexible and does not have this rigid requirement. On the other hand, we need to remember that an option is just an extension, nothing more nothing less. It is used to communicate a HoA, CoA, an NAI, etc. When it comes to binding revocation, a control signaling mechanism, we may identify more than one of these options to identify the proper action the receiving mobility entity needs to take. Also, different scenarios may require different options. What I mean is, fitting all the scenarios and functionality described in the Binding Revocation for IPv6 Mobility draft in a single option is probably a stretch. Therefore, we need a mechanism which is flexible enough to allow different applications to define its own specifics if necessary and I am not sure why you think that approach is a bad thing! It would be a good idea if you can identify some examples or use cases which shows that the proposed approach is not a good thing to do. Honestly, I do not see a point of objecting a good flexible approach for achieving the same objectives of the draft-haley. >=20 > Vijay >=20 > >=20 > > The suggested mechanism defines a generic container=20 > mechanism and at=20 > > the same time gives the freedom for some notification mechanisms to=20 > > have its own specifics. Probably taking a look at all the=20 > discussion=20 > > related to this topic would be a good idea. > >=20 > > Regards, > > Ahmad > > =20 > >=20 > > > -----Original Message----- > > > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com] > > > Sent: Monday, June 04, 2007 4:49 PM > > > To: Brian Haley; Basavaraj Patil > > > Cc: Mobile IPv6 Mailing List; ext Sri Gundavelli > > > Subject: RE: [Mip6] Consensus call: MakeI-D=20 > > > draft-haley-mip6-mh-signaling-02.txt a WG doc > > >=20 > > > This is not making sense to me. We have two messages in=20 > the current=20 > > > draft, the Mobility Header Signaling Request Message and the=20 > > > Mobility Header Signaling Acknowledgement Message. > > > This is equivalent to the "Signaling request" and "Signaling=20 > > > response" messages below. One has to just define new mobility=20 > > > options that go in the Signaling Request and Signaling=20 > > > Acknowledgement Message. > > >=20 > > > I don't understand why you would want to define "subtype"=20 > > > fields in this message. Please let me know what I am missing. > > >=20 > > > Vijay > > >=20 > > > > -----Original Message----- > > > > From: Brian Haley [mailto:brian.haley@hp.com] > > > > Sent: Monday, June 04, 2007 2:04 PM > > > > To: Basavaraj Patil > > > > Cc: Mobile IPv6 Mailing List; ext Sri Gundavelli > > > > Subject: Re: [Mip6] Consensus call: MakeI-D=20 > > > > draft-haley-mip6-mh-signaling-02.txt a WG doc > > > >=20 > > > > Hi Raj, > > > >=20 > > > > Ahmad, Sri and I have talked off-line about how to go > > forward with > > > > draft-haley and support draft-muhanna better. We've=20 > come to the=20 > > > > following conclusion (someone update if I got this wrong). > > > >=20 > > > > Draft-haley will define a Generic Notification Message > > > (GNM) which is > > > > a new MH type, and also define two new sub-types - one for > > > Signaling > > > > Request, one for Signaling Reply (or some wording like that). > > > >=20 > > > > The structures would look something like this: > > > >=20 > > > > Generic Notification Message (w/MH message pieces, MH Type TBD) > > > >=20 > > > > =20 > > > >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Payload Proto | Header Len | MH Type | =20 > > > > Reserved | > > > > =20 > > > >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Checksum | GNM=20 > > > > Type/Sub-Type | > > > > =20 > > > >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >=20 > > > > In essence, the message is just a container to transport > > > notification > > > > messages between mobility entities. > > > >=20 > > > > They we'd define two Sub-types with the same semantics of > > > the current > > > > messages in draft-haley: > > > >=20 > > > > Signaling Request (GNM Type TBD): > > > >=20 > > > > =20 > > > >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Sequence Number |A| Reserved =20 > > > > | > > > > =20 > > > >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >=20 > > > > Signaling Reply (GNM Type TBD): > > > >=20 > > > > =20 > > > >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Sequence Number | Status | =20 > > > > Reserved | > > > > =20 > > > >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >=20 > > > > This would give someone that wants to use the semantics of the=20 > > > > Signaling Messages an easy framework for implentation > > (sequencing, > > > > retransmission, etc). All they would have to do is define > > > a mobility > > > > option with their data to go "inside". > > > >=20 > > > > Ahmad would define a new GNM Sub-type for revocation, and > > whatever > > > > structures and options to go with it. > > > >=20 > > > > I'll update draft-haley with these changes if there are no > > > objections. > > > >=20 > > > > Thanks to Ahmad for the suggestions. > > > >=20 > > > > -Brian > > > >=20 > > > >=20 > > > > Ahmad Muhanna wrote: > > > > > Hello, > > > > > =20 > > > > > My understanding that the scope of draft-haley is as follows: > > > > >=20 > > > > > o A generic container which can be used to communicate > > multiple > > > > > functionalities while preserving the MH types. > > > > > o Introduce a Generic Notification Messages and Generic > > > > Notification > > > > > mechanism=20 > > > > > that can be used to communicate several common > > > > notification event(s) > > > > > between=20 > > > > > the HA and the MN. > > > > >=20 > > > > > Having said that, I would like to propose a small change to > > > > the current > > > > > Draft-haley revision 02 which would hopefully enrich and > > > enhance the > > > > > draft. > > > > >=20 > > > > > The following summarize the proposed changes: > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > 1. Define the first two bytes, of the current generic > > > > notification > > > > > message, and call them , for example, Generic > > > > Mobility Container, > > > > > GMC, or XYZ. > > > > >=20 > > > > > 2. The Generic Mobility Container is 2 bytes length and > > > > can have up > > > > > to 64k > > > > > different values which we can call, for example, GMC > > > > Type. i.e. > > > > >=20 > > > > > Generic Notification Request message, Generic > > > > Notification Ack, > > > > > Binding Revocation Indication message, Binding > > > > Revocation Ack, > > > > > etc. > > > > >=20 > > > > > 3. Every common functionality defines its own messages > > > > and mechanism > > > > > including its own mechanism as fits the need of > > > the specified > > > > > functionality. > > > > >=20 > > > > > 4. Any functionality, e.g. Generic Notification, may > > > > define the use > > > > > of any MH option inside its own messages or define > > > new ones. > > > > >=20 > > > > > Here is the format, let us use the Generic Notification > > > and Binding > > > > > Revocation as examples: > > > > > =20 > > > > > 1. Generic Mobility Container Message=20 > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > This Signaling Generic Mobility Container Message uses the > > > > MH Type value > > > > > (TBD). > > > > >=20 > > > > >=20 > > > > > =20 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | GMC Type=20 > > > > | > > > > > =20 > > > >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | =20 > > > > | > > > > > . =20 > > > > . > > > > > . Message Data =20 > > > > . > > > > > . =20 > > > > . > > > > > | =20 > > > > | > > > > > =20 > > > >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > >=20 > > > > >=20 > > > > > 2. Generic Notification > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > >=20 > > > > > Let us assume that this application requires two messages, > > > > a Request and > > > > >=20 > > > > > an acknowledgement. > > > > >=20 > > > > > 3.1. Generic Notification Request=20 > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > This Generic Notification Request uses a GMC Type of (TBD). > > > > >=20 > > > > > =20 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | GMC Type=20 > > > > | > > > > > =20 > > > >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | =20 > > > > | > > > > > . =20 > > > > . > > > > > . Generic Notification Request =20 > > > > . > > > > > . =20 > > > > . > > > > > | =20 > > > > | > > > > > =20 > > > >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > >=20 > > > > > 3.2. Generic Notification Ack > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > > > This Generic Notification Ack uses a GMC Type of (TBD). > > > > >=20 > > > > > =20 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | GMC Type=20 > > > > | > > > > > =20 > > > >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | =20 > > > > | > > > > > . =20 > > > > . > > > > > . Generic Notification Ack =20 > > > > . > > > > > . =20 > > > > . > > > > > | =20 > > > > | > > > > > =20 > > > >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > =20 > > > > > 3. Binding Revocation > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > >=20 > > > > > The following are the revocation messages that are > > defined by the > > > > > Binding Revocation Functionality as specified by the Binding=20 > > > > > Revocation for IPv6 Mobility draft. > > > > > =20 > > > > > 2.1. Binding Revocation Indication=20 > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > >=20 > > > > > This Binding Revocation Indication uses a GMC Type of (TBD). > > > > >=20 > > > > > =20 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | GMC Type=20 > > > > | > > > > > =20 > > > >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | =20 > > > > | > > > > > . =20 > > > > . > > > > > . Binding Revocation Indication =20 > > > > . > > > > > . =20 > > > > . > > > > > | =20 > > > > | > > > > > =20 > > > >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > =20 > > > > > 2.2. Binding Revocation Acknowledgement=20 > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > This Binding Revocation Acknowledgement uses a GMC Type (TBD). > > > > >=20 > > > > > =20 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | GMC Type=20 > > > > | > > > > > =20 > > > >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | =20 > > > > | > > > > > . =20 > > > > . > > > > > . Binding Revocation Acknowledgement =20 > > > > . > > > > > . =20 > > > > . > > > > > | =20 > > > > | > > > > > =20 > > > >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > >=20 > > > > >=20 > > > > > Finally and as a suggestion, I would like to suggest that > > > > draft-haley > > > > > address two things: > > > > > 1. Introducing the Generic Mobility Container, GMC. > > > > > 2. Define the Generic Notification Messages and the related > > > > Mechanism. > > > > >=20 > > > > > While the Binding Revocation for IPv6 Mobility draft can > > > define the > > > > > Binding Revocation messages and the binding revocation > > mechanism. > > > > >=20 > > > > >=20 > > > > > Best Regards, > > > > > Ahmad > > > > >=20 > > > > >> -----Original Message----- > > > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > >> Sent: Wednesday, May 30, 2007 12:23 PM > > > > >> To: Mobile IPv6 Mailing List > > > > >> Cc: brian.haley@hp.com; ext Sri Gundavelli > > > > >> Subject: [Mip6] Consensus call: Make I-D=20 > > > > >> draft-haley-mip6-mh-signaling-02.txt a WG doc > > > > >> > > > > >> > > > > >> Hello, > > > > >> > > > > >> At the Prague IETF (IETF68), the MIP6 WG discussed the > > > > following I-D: > > > > >> Mobility Header Signaling Message=20 > > > > >> > > > > >> > > > > >> 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 > > > > >> > > > > >=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 > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 05 03:52: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 1HvTpd-0001CQ-Bw; Tue, 05 Jun 2007 03:51:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvTpb-0001CH-EK for mip6@ietf.org; Tue, 05 Jun 2007 03:51:55 -0400 Received: from smail5.alcatel.fr ([64.208.49.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvTpa-0001wH-JX for mip6@ietf.org; Tue, 05 Jun 2007 03:51:55 -0400 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l557oMro014729; Tue, 5 Jun 2007 09:50:23 +0200 Received: from [172.27.205.187] ([172.27.205.187]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Tue, 5 Jun 2007 09:51:48 +0200 Message-ID: <46651613.501@alcatel-lucent.fr> Date: Tue, 05 Jun 2007 09:51:47 +0200 From: Bruno Mongazon-Cazavet User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Brian Haley Subject: Re: [Mip6] Consensus call: Make I-D draft-haley-mip6-mh-signaling-02.txt a WG doc References: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C3F@zrc2hxm2.corp.nortel.com> <46647E44.6030000@hp.com> In-Reply-To: <46647E44.6030000@hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jun 2007 07:51:48.0155 (UTC) FILETIME=[5EB0E8B0:01C7A746] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Cc: Mobile IPv6 Mailing List , ext 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 all, I think that binding related signaling should not use a generic notification signaling. First, it strongly contradicts RFC 3775: RFC 3775 says: 6.1. Mobility Header The Mobility Header is an extension header used by mobile nodes, correspondent nodes, and home agents in *all messaging related to the creation and management of bindings*. The subsections within this section describe the message types that may be sent using the Mobility Header. RFC 3775 provides some extension capabilities for the MH type that can be used to specify revocation commands. It has been done this way in IPv4. I am not against a generic notification signaling but i think it should be kept separate from the binding management signaling itself. As far as the generic notification signaling draft is concerned (draft-haley), i think the term "notification" is not suited. Generally speaking, I am not expecting a notification to carry a (command) request or a (command) response. The term "notification" does not ask for something but rather notify of something. Doing request-response with a "notification mechanism" is not consistent to me. If the draft intends to extends RFC 3775 with a generic signaling capability, it should be stated explicitly. Such a generic signaling capability could be used for request-response and notification. However, it should explicitly exclude binding management signaling that is specified in RFC 3775 and extended in draft-muhanna. To summarize my opinion: draft-haley => should be defined as a generic signaling protocol on top of MIP6 and exclude binding management signaling (RFC 3775 and futher revisions) draft-muhanna => should be defined as extension to RFC 3775 (or new revision?) without relationship to draft-haley. Any thoughts? Bruno. Brian Haley wrote: > Hi Raj, > > Ahmad, Sri and I have talked off-line about how to go forward with > draft-haley and support draft-muhanna better. We've come to the > following conclusion (someone update if I got this wrong). > > Draft-haley will define a Generic Notification Message (GNM) which is > a new MH type, and also define two new sub-types - one for Signaling > Request, one for Signaling Reply (or some wording like that). > > The structures would look something like this: > > Generic Notification Message (w/MH message pieces, MH Type TBD) > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload Proto | Header Len | MH Type | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Checksum | GNM Type/Sub-Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > In essence, the message is just a container to transport notification > messages between mobility entities. > > They we'd define two Sub-types with the same semantics of the current > messages in draft-haley: > > Signaling Request (GNM Type TBD): > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number |A| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Signaling Reply (GNM Type TBD): > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | Status | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > This would give someone that wants to use the semantics of the > Signaling Messages an easy framework for implentation (sequencing, > retransmission, etc). All they would have to do is define a mobility > option with their data to go "inside". > > Ahmad would define a new GNM Sub-type for revocation, and whatever > structures and options to go with it. > > I'll update draft-haley with these changes if there are no objections. > > Thanks to Ahmad for the suggestions. > > -Brian > > > Ahmad Muhanna wrote: >> Hello, >> >> My understanding that the scope of draft-haley is as follows: >> >> o A generic container which can be used to communicate multiple >> functionalities while preserving the MH types. >> o Introduce a Generic Notification Messages and Generic Notification >> mechanism that can be used to communicate several common >> notification event(s) >> between the HA and the MN. >> >> Having said that, I would like to propose a small change to the >> current Draft-haley revision 02 which would hopefully enrich and >> enhance the >> draft. >> >> The following summarize the proposed changes: >> ============================================= >> 1. Define the first two bytes, of the current generic notification >> message, and call them , for example, Generic Mobility Container, >> GMC, or XYZ. >> >> 2. The Generic Mobility Container is 2 bytes length and can have up >> to 64k >> different values which we can call, for example, GMC Type. i.e. >> >> Generic Notification Request message, Generic Notification Ack, >> Binding Revocation Indication message, Binding Revocation Ack, >> etc. >> >> 3. Every common functionality defines its own messages and mechanism >> including its own mechanism as fits the need of the specified >> functionality. >> >> 4. Any functionality, e.g. Generic Notification, may define the >> use of any MH option inside its own messages or define new ones. >> >> Here is the format, let us use the Generic Notification and Binding >> Revocation as examples: >> 1. Generic Mobility Container Message >> ===================================== This Signaling Generic Mobility >> Container Message uses the MH Type value >> (TBD). >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | GMC Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> . . >> . Message Data . >> . . >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> 2. Generic Notification >> ======================= >> >> Let us assume that this application requires two messages, a Request and >> >> an acknowledgement. >> >> 3.1. Generic Notification Request >> ================================== >> This Generic Notification Request uses a GMC Type of (TBD). >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | GMC Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> . . >> . Generic Notification Request . >> . . >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> 3.2. Generic Notification Ack >> ============================== >> This Generic Notification Ack uses a GMC Type of (TBD). >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | GMC Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> . . >> . Generic Notification Ack . >> . . >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> 3. Binding Revocation >> ====================== >> >> The following are the revocation messages that are defined by >> the Binding Revocation Functionality as specified by the Binding >> Revocation for IPv6 Mobility draft. >> 2.1. Binding Revocation Indication >> ================================== >> >> This Binding Revocation Indication uses a GMC Type of (TBD). >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | GMC Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> . . >> . Binding Revocation Indication . >> . . >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> 2.2. Binding Revocation Acknowledgement >> ======================================== >> This Binding Revocation Acknowledgement uses a GMC Type (TBD). >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | GMC Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> . . >> . Binding Revocation Acknowledgement . >> . . >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Finally and as a suggestion, I would like to suggest that draft-haley >> address two things: >> 1. Introducing the Generic Mobility Container, GMC. >> 2. Define the Generic Notification Messages and the related Mechanism. >> >> While the Binding Revocation for IPv6 Mobility draft can define the >> Binding Revocation messages and the binding revocation mechanism. >> >> >> Best Regards, >> Ahmad >> >>> -----Original Message----- >>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] Sent: >>> Wednesday, May 30, 2007 12:23 PM >>> To: Mobile IPv6 Mailing List >>> 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 >>> >>> >>> 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 >>> >> >> >> _______________________________________________ >> 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 Tue Jun 05 03:55: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 1HvTtF-00085T-MC; Tue, 05 Jun 2007 03:55:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvTtE-00085C-49 for mip6@ietf.org; Tue, 05 Jun 2007 03:55:40 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvTtD-0002Bp-Bf for mip6@ietf.org; Tue, 05 Jun 2007 03:55:40 -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 <0JJ500KVHKOPAQ@mailout2.samsung.com> for mip6@ietf.org; Tue, 05 Jun 2007 16:55:37 +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 <0JJ5004VYKOP3D@ms5.samsung.com> for mip6@ietf.org; Tue, 05 Jun 2007 16:55:37 +0900 (KST) Content-return: prohibited Date: Tue, 05 Jun 2007 07:55:37 +0000 (GMT) From: Heejin Jang Subject: Re: RE: RE: [Mip6] I-D ACTION:draft-ietf-mip6-hiopt-03.txt To: "Premec, Domagoj" Message-id: <29686137.1445221181030137212.JavaMail.weblogic@ep_ml28> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20070605075537210@heejin.jang X-MTR: 20070605075537210@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: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: "mip6@ietf.org" , "Kilian.Weniger@eu.panasonic.com" 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="===============1665352269==" Errors-To: mip6-bounces@ietf.org --===============1665352269== Content-return: prohibited Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 SGksIERvbWFnb2ouDQpLaW5kbHkgc2VlIHRoZSBpbmxpbmUuDQoNCi0gUmVnYXJkcw0KSGVlamlu LiANCg0KLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0NClNlbmRlciA6IFByZW1lYywg RG9tYWdvajxkb21hZ29qLnByZW1lY0BzaWVtZW5zLmNvbT4NCkRhdGUgICA6IDIwMDctMDYtMDQg MTc6MzANClRpdGxlICA6IFJFOiBSRTogW01pcDZdIEktRCBBQ1RJT046ZHJhZnQtaWV0Zi1taXA2 LWhpb3B0LTAzLnR4dA0KDQpIaSBIZWVqaW4sDQoNCj4gSW4gbXkgYW5zd2VyLCAiYSBzaW5nbGUg SG9tZSBOZXR3b3JrIGluZm9ybWF0aW9uIG9wdGlvbiB3aXRoIA0KPiBtdWx0aXBsZSBzdWItb3B0 aW9ucyIgbWVhbnMgcGVyIGVhY2ggYSBzaW5nbGUgSG9tZSBOZXR3b3JrIA0KPiBJZGVudGlmaWVy IG9wdGlvbi4NCg0KT0ssIEkgbWlzdW5kZXJzdG9vZCB0aGlzIHNlbnRlbmNlLCBJIHRob3VnaHQg dGhhdCB0aGVyZSB3aWxsIGJlIGEgdG90YWwgb2YgMSBITiBpbmZvcm1hdGlvbiBvcHRpb24gaW4g dGhlIHJlc3BvbnNlLg0KDQo+IFRoYXQgaXMsIHRoZSBudW1iZXIgb2YgSE4gSW5mb3JtYXRpb24g DQo+IG9wdGlvbiBpbiB0aGUgcmVwbHkgaXMgdGhlIHNhbWUgYXMgdGhlIG51bWJlciBvZiBITiAN Cj4gSW5mb3JtYXRpb24gb3B0aW9uIGluIHRoZSByZXF1ZXN0LCBhbmQgdGhlICJpZC10eXBlIiB3 aWxsIGJlIA0KPiBhZGRlZCBpbiBhbiBITiBpbmZvcm1hdGlvbiBvcHRpb24gZm9yIG1hcHBpbmcg Zm9yIGVhY2ggDQo+IG9wdGlvbi4gV2UgZml4ZWQgdGhpcyBhbmQgdGhlIG5leHQgdmVyc2lvbiB3 aWxsIGNvdmVyIHRoaXMuDQoNCk1vYmlsZSBub2RlIGNhbiBpbmNsdWRlIHNldmVyYWwgSE4gSWRl bnRpZmllciBvcHRpb25zIHdpdGggdGhlIHNhbWUgaWQtdHB5ZSAoMSkgaW4gaXRzIHJlcXVlc3Qu IEluIHRoaXMgY2FzZSBpbmNsdWRpbmcgdGhlIGlkLXR5cGUgaW4gYW4gSE4gaW5mb3JtYXRpb24g b3B0aW9uIHdpbGwgbm90IGJlIGVub3VnaCB0byBlbmFibGUgdGhlIG1hdGNoaW5nLiBPbmUgcG9z c2liaWxpdHkgbWF5IGJlIHRvIHJlcXVpcmUgdGhhdCB0aGUgSE4gaW5mb3JtYXRpb24gb3B0aW9u cyBhcHBlYXIgaW4gdGhlIHNhbWUgb3JkZXIgYXMgSE4gSWRlbnRpZmllciBvcHRpb25zIGFuZCB0 aGF0IHRoZSBtYXRjaGluZyBpcyBiYXNlZCBvbiB0aGUgc2VxdWVudGlhbCBvcmRlciBvZiBvcHRp b25zLg0KDQpIZWVqaW4gPj4gUmlnaHQuIEhOIEluZm9ybWF0aW9uIG9wdGlvbnMgd2l0aCB0aGUg c2FtZSBpZC10eXBlIHdpdGhvdXQgYW55IG1hcHBpbmcgaW5mbyBjb3VsZCBiZSBwcm9ibGVtYXRp Yy4gDQpTZXF1ZW50aWFsIG9yZGVyaW5nIGNhbiBiZSBvbmUgd2F5LCBhbmQgYWRkaW5nIG1hcHBp bmcgaWRlbnRpZmllciBpbiBITiBpbmZvL2lkZW50ZmllciBvcHRpb25zIGNhbiBiZSBhbm90aGVy IHdoaWNoDQpsb29rcyByYXRoZXIgY29tcGxpY2F0ZWQuIFdlJ2xsIHJlZmxlY3QgdGhpcyBwb2lu dCBkdXJpbmcgdWRwYXRlLiBUaGFua3MgZm9yIHlvdXIgaGVscGZ1bCBjb21tZW50cy4gOikNCg0K dGhhbmtzDQpkb21hZ29qDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBIZWVqaW4gSmFuZyBbbWFpbHRvOmhlZWppbi5qYW5nQHNhbXN1bmcuY29tXSANCj4gU2VudDog MDQuIGxpcGFuaiAyMDA3IDAzOjM1DQo+IFRvOiBQcmVtZWMsIERvbWFnb2o7IEtpbGlhbi5XZW5p Z2VyQGV1LnBhbmFzb25pYy5jb20NCj4gQ2M6IG1pcDZAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IFJFOiBbTWlwNl0gSS1EIEFDVElPTjpkcmFmdC1pZXRmLW1pcDYtaGlvcHQtMDMudHh0DQo+IA0K PiBIaSwgRG9tYWdvai4NCj4gVGhhbmtzIGZvciB5b3VyIGNvbW1lbnQuDQo+ICANCj4gQSBmZXcg ZGF5cyBhZ28sIEkgYW5zd2VyZWQgYXMgZm9sbG93cyBmb3IgS2lsaWFuJiMzOTtzIHF1ZXN0aW9u IGluIE1MLg0KPiAgDQo+IEtpbGlhbiYjMzk7cyBRPiBXaGF0IHNob3VsZCB0aGUgREhDUCBzZXJ2 ZXIgZG8gaWYgdGhlIE1JUDYgcmVsYXkgDQo+IGFnZW50IG9wdGlvbiBjb250YWlucyBtdWx0aXBs ZSBzdWItb3B0aW9ucyBhbmQgb25lIG9mIHRoZSANCj4gc3ViLW9wdGlvbnMgbWF0Y2hlcyB0aGUg TkFJJiMzOTtzIHJlYWxtIHdoZXJlYXMgYW5vdGhlciBvbmUgZG9lcyANCj4gbm90PyBUaGlzIHNp dHVhdGlvbiBjYW4gaGFwcGVuIGlmIHRoZSBBQUFIIHNlbmRzIGhvbWUgbmV0d29yayANCj4gaW5m b3JtYXRpb24gZm9yIG11dGxpcGxlIE1TUHMgdG8gdGhlIE5BUyAoZS5nLiwgZm9yIGhvbWUgDQo+ IE1TUC9NU0EgYW5kIG90aGVyIE1TUHMgd2l0aCB0cnVzdCByZWxhdGlvbnNoaXAgdG8gTVNBKS4g DQo+IFNob3VsZCB0aGUgc2VydmVyIHJlc3BvbmQgd2l0aCBtdWx0aXBsZSBIb21lIE5ldHdvcmsg DQo+IEluZm9ybWF0aW9uIFN1Yi1vcHRpb25zPw0KPiAgDQo+IEhlZWppbiYjMzk7cyBBPiBBIERI Q1Agc2VydmVyIGV4dHJhY3RzIG9ubHkgdGhlIGF2YWlsYWJsZSBIQSBpbmZvIA0KPiBhbW9uZyB0 aGUgaW5mbyBwcml2aWRlZCBieSBOQVMgKGZpbmFsbHkgZnJvbSBBQUEpIGFuZCANCj4gaW5jbHVk ZXMgdGhlbSBpbiBhIHNpbmdsZSBIb21lIE5ldHdvcmsgaW5mb3JtYXRpb24gb3B0aW9uIA0KPiB3 aXRoIG11bHRpcGxlIHN1Yi1vcHRpb25zLiBJZiB0aGUgc2VydmVyIGhhcyBubyBpbmZvIGZvciB0 aGUgDQo+IHNwZWNpZmllZCBpZC10eXBlIGluIEhvbWUgTmV0d29yaywgdGhlbiBpdCByZXBsaWVz IHdpdGggDQo+IG9wdC1sZW49MCBpbiBhIEhvbWUgTmV0d29yayBJbmZvcm1hdGlvbiBvcHRpb24u DQo+ICANCj4gSW4gbXkgYW5zd2VyLCAiYSBzaW5nbGUgSG9tZSBOZXR3b3JrIGluZm9ybWF0aW9u IG9wdGlvbiB3aXRoIA0KPiBtdWx0aXBsZSBzdWItb3B0aW9ucyIgbWVhbnMgcGVyIGVhY2ggYSBz aW5nbGUgSG9tZSBOZXR3b3JrIA0KPiBJZGVudGlmaWVyIG9wdGlvbi4gVGhhdCBpcywgdGhlIG51 bWJlciBvZiBITiBJbmZvcm1hdGlvbiANCj4gb3B0aW9uIGluIHRoZSByZXBseSBpcyB0aGUgc2Ft ZSBhcyB0aGUgbnVtYmVyIG9mIEhOIA0KPiBJbmZvcm1hdGlvbiBvcHRpb24gaW4gdGhlIHJlcXVl c3QsIGFuZCB0aGUgImlkLXR5cGUiIHdpbGwgYmUgDQo+IGFkZGVkIGluIGFuIEhOIGluZm9ybWF0 aW9uIG9wdGlvbiBmb3IgbWFwcGluZyBmb3IgZWFjaCANCj4gb3B0aW9uLiBXZSBmaXhlZCB0aGlz IGFuZCB0aGUgbmV4dCB2ZXJzaW9uIHdpbGwgY292ZXIgdGhpcy4NCj4gVGhhbmtzLg0KPiAgDQo+ IC0gQmVzdCBSZWdhcmVkcywNCj4gSGVlamluDQo+IA0KPiAtLS0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0tLQ0KPiBTZW5kZXIgOiBQcmVtZWMsIERvbWFnb2o8ZG9tYWdvai5wcmVtZWNAc2ll bWVucy5jb20+DQo+IERhdGUgICA6IDIwMDctMDYtMDEgMDA6NTYNCj4gVGl0bGUgIDogUkU6IFtN aXA2XSBJLUQgQUNUSU9OOmRyYWZ0LWlldGYtbWlwNi1oaW9wdC0wMy50eHQNCj4gDQo+IEhpIEhl ZWppbiwNCj4gDQo+IEkgaGF2ZSBhIGNsYXJpZmljYXRpb24gcXVlc3Rpb246IGlmIHRoZSBNTiBy ZXF1ZXN0cyANCj4gaW5mb3JtYXRpb24gYWJvdXQgc2V2ZXJhbCB0YXJnZXQgbmV0d29ya3MgaXQg d2lsbCBpbmNsdWRlIA0KPiBzZXZlcmFsIEhvbWUgTmV0d29yayBJZGVudGlmaWVyIG9wdGlvbnMu IFRoZSBmb2xsb3dpbmcgdGV4dCANCj4gDQo+ID4gICBNdWx0aXBsZSBzdWItb3B0aW9ucyBtYXkg ZXhpc3QgaW4gYSBIb21lIE5ldHdvcmsgDQo+IEluZm9ybWF0aW9uIG9wdGlvbg0KPiA+ICAgdG8g Y2FycnkgbW9yZSB0aGFuIG9uZSBob21lIGluZm9ybWF0aW9uLg0KPiANCj4gbGVhdmVzIGltcHJl c3Npb24gdGhhdCB0aGUgcmVzcG9uc2UgbWVzc2FnZSBjb250YWlucyBvbmx5IG9uZSANCj4gSG9t ZSBOZXR3b3JrIEluZm9ybWF0aW9uIG9wdGlvbiB3aGljaCBjYXJyaWVzIHRoZSBhZGRyZXNzZXMs IA0KPiBwcmVmaXhlcyBhbmQvb3IgRlFETnMgb2YgYWxsIHRhcmdldCBuZXR3b3Jrcy4gSSBjb3Vs ZCBiZSANCj4gd3JvbmcsIGJ1dCBJIGNvdWxkbiYmIzM1OzM5O3QgZmluZCBhbnkgdGV4dCB0aGF0 IGlzIHNwZWNpZmljIGFib3V0IHRoaXMuIA0KPiANCj4gSWYgdGhlIGluZm9ybWF0aW9uIGFib3V0 IG11bHRpcGxlIHRhcmdldCBuZXR3b3JrcyBpcyBjYXJyaWVkIA0KPiBpbiBhIHNpbmdsZSBIb21l IE5ldHdvcmsgSW5mb3JtYXRpb24gb3B0aW9uLCB0aGUgTU4gbWF5IG5vdCANCj4gYmUgYWJsZSB0 byBtYXRjaCB0aGUgaW5mbyBmcm9tIHRoZSBIb21lIE5ldHdvcmsgSW5mb3JtYXRpb24gDQo+IG9w dGlvbiB0byBhIHBhcnRpY3VsYXIgdGFyZ2V0IG5ldHdvcmsuIEZvciBleGFtcGxlLCB0aGUgTU4g DQo+IG1heSBhc2sgZm9yIGluZm9tYXRpb24gYWJvdXQgb3BlcmF0b3IxLmNvbSBhbmQgb3BlcmF0 b3IyLmNvbSwgDQo+IGFuZCB0aGUgSG9tZSBOZXR3b3JrIEluZm9ybWF0aW9uIG9wdGlvbiBtYXkg Y29udGFpbiB0aGUgaG9tZSANCj4gc3VibmV0IHByZWZpeCBhbmQgdGhlIEZRRE4uIEhvdyB3b3Vs ZCB0aGUgTU4ga25vdyBpZiBib3RoIA0KPiBzdWJvcHRpb25zIGNhcnJ5IGluZm9ybWF0aW9uIGFi b3V0IG9wZXJhdG9yMS5jb20gb3IgaWYgc3VibmV0IA0KPiBiZWxvbmdzIHRvIG9wZXJhdG9yMSBh bmQgRlFETiB0byBvcGVyYXRvciAyPw0KPiANCj4gdGhhbmtzDQo+IGRvbWFnb2oNCj4gDQo+IA0K PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogSW50ZXJuZXQtRHJhZnRz QGlldGYub3JnIFttYWlsdG86SW50ZXJuZXQtRHJhZnRzQGlldGYub3JnXQ0KPiA+IFNlbnQ6IDE2 LiBzdmliYW5qIDIwMDcgMjE6NTANCj4gPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+ID4g Q2M6IG1pcDZAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBbTWlwNl0gSS1EIEFDVElPTjpkcmFmdC1p ZXRmLW1pcDYtaGlvcHQtMDMudHh0DQo+ID4gDQo+ID4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg YXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIA0KPiA+IGRpcmVjdG9y aWVzLg0KPiA+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE1vYmlsaXR5IGZvciBJ UHY2IFdvcmtpbmcgR3JvdXAgb2YgDQo+ID4gdGhlIElFVEYuDQo+ID4gDQo+ID4gICAgIFRpdGxl ICAgICAgICA6IERIQ1AgT3B0aW9uIGZvciBIb21lIEluZm9ybWF0aW9uIA0KPiA+IERpc2NvdmVy eSBpbiBNSVB2Ng0KPiA+ICAgICBBdXRob3IocykgICAgOiBILiBKYW5nLCBldCBhbC4NCj4gPiAg ICAgRmlsZW5hbWUgICAgOiBkcmFmdC1pZXRmLW1pcDYtaGlvcHQtMDMudHh0DQo+ID4gICAgIFBh Z2VzICAgICAgICA6IDE5DQo+ID4gICAgIERhdGUgICAgICAgIDogMjAwNy01LTE2DQo+ID4gICAg IA0KPiA+IFRoaXMgZHJhZnQgZGVmaW5lcyBhIERIQ1AtYmFzZWQgc2NoZW1lIHRvIGVuYWJsZSBk eW5hbWljIA0KPiBkaXNjb3Zlcnkgb2YNCj4gPiAgICBNb2JpbGUgSVB2NiBob21lIGFnZW50IGFk ZHJlc3MsIGhvbWUgYWdlbnQgRlFETiBhbmQgaG9tZSANCj4gc3VibmV0LiAgDQo+ID4gTmV3DQo+ ID4gICAgREhDUCBvcHRpb25zIGFyZSBkZWZpbmVkIHRvIGNhcnJ5IHRoZSBpbmZvcm1hdGlvbiBm cm9tIGEgREhDUCANCj4gPiBzZXJ2ZXINCj4gPiAgICB0byB0aGUgREhDUCBjbGllbnQgcnVubmlu ZyBvbiB0aGUgbW9iaWxlIG5vZGUuDQo+ID4gDQo+ID4gQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQt RHJhZnQgaXM6DQo+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt aWV0Zi1taXA2LWhpb3B0LTAzLnR4dA0KPiA+IA0KPiA+IFRvIHJlbW92ZSB5b3Vyc2VsZiBmcm9t IHRoZSBJLUQgQW5ub3VuY2VtZW50IGxpc3QsIHNlbmQgYSANCj4gbWVzc2FnZSB0byANCj4gPiBp LWQtYW5ub3VuY2UtcmVxdWVzdEBpZXRmLm9yZyB3aXRoIHRoZSB3b3JkIHVuc3Vic2NyaWJlIGlu IA0KPiB0aGUgYm9keSBvZiANCj4gPiB0aGUgbWVzc2FnZS4NCj4gPiBZb3UgY2FuIGFsc28gdmlz aXQgDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL0ktRC1hbm5vdW5j ZQ0KPiA+IHRvIGNoYW5nZSB5b3VyIHN1YnNjcmlwdGlvbiBzZXR0aW5ncy4NCj4gPiANCj4gPiBJ bnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAuIExvZ2lu IHdpdGggdGhlIA0KPiA+IHVzZXJuYW1lICJhbm9ueW1vdXMiIGFuZCBhIHBhc3N3b3JkIG9mIHlv dXIgZS1tYWlsIGFkZHJlc3MuIEFmdGVyIA0KPiA+IGxvZ2dpbmcgaW4sIHR5cGUgImNkIGludGVy bmV0LWRyYWZ0cyIgYW5kIHRoZW4gImdldCANCj4gPiBkcmFmdC1pZXRmLW1pcDYtaGlvcHQtMDMu dHh0Ii4NCj4gPiANCj4gPiBBIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzIGNh biBiZSBmb3VuZCBpbiANCj4gPiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIG9yIA0K PiA+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQo+ID4gDQo+ID4g SW50ZXJuZXQtRHJhZnRzIGNhbiBhbHNvIGJlIG9idGFpbmVkIGJ5IGUtbWFpbC4NCj4gPiANCj4g PiBTZW5kIGEgbWVzc2FnZSB0bzoNCj4gPiAgICAgbWFpbHNlcnZAaWV0Zi5vcmcuDQo+ID4gSW4g dGhlIGJvZHkgdHlwZToNCj4gPiAgICAgIkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRm LW1pcDYtaGlvcHQtMDMudHh0Ii4NCj4gPiAgICAgDQo+ID4gTk9URTogICAgVGhlIG1haWwgc2Vy dmVyIGF0IGlldGYub3JnIGNhbiByZXR1cm4gdGhlIGRvY3VtZW50IGluDQo+ID4gICAgIE1JTUUt ZW5jb2RlZCBmb3JtIGJ5IHVzaW5nIHRoZSAibXBhY2siIHV0aWxpdHkuICBUbyB1c2UgdGhpcw0K PiA+ICAgICBmZWF0dXJlLCBpbnNlcnQgdGhlIGNvbW1hbmQgIkVOQ09ESU5HIG1pbWUiIGJlZm9y ZSB0aGUgIkZJTEUiDQo+ID4gICAgIGNvbW1hbmQuICBUbyBkZWNvZGUgdGhlIHJlc3BvbnNlKHMp LCB5b3Ugd2lsbCBuZWVkICJtdW5wYWNrIiBvcg0KPiA+ICAgICBhIE1JTUUtY29tcGxpYW50IG1h aWwgcmVhZGVyLiAgRGlmZmVyZW50IE1JTUUtY29tcGxpYW50IG1haWwgDQo+ID4gcmVhZGVycw0K PiA+ICAgICBleGhpYml0IGRpZmZlcmVudCBiZWhhdmlvciwgZXNwZWNpYWxseSB3aGVuIGRlYWxp bmcgd2l0aA0KPiA+ICAgICAibXVsdGlwYXJ0IiBNSU1FIG1lc3NhZ2VzIChpLmUuIGRvY3VtZW50 cyB3aGljaCBoYXZlIGJlZW4gc3BsaXQNCj4gPiAgICAgdXAgaW50byBtdWx0aXBsZSBtZXNzYWdl cyksIHNvIGNoZWNrIHlvdXIgbG9jYWwgZG9jdW1lbnRhdGlvbiBvbg0KPiA+ICAgICBob3cgdG8g bWFuaXB1bGF0ZSB0aGVzZSBtZXNzYWdlcy4NCj4gPiANCj4gPiBCZWxvdyBpcyB0aGUgZGF0YSB3 aGljaCB3aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxpYW50IG1haWwgcmVhZGVyIA0KPiA+IGltcGxl bWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhlIEFTQ0lJIHZlcnNpb24gb2Yg dGhlIA0KPiA+IEludGVybmV0LURyYWZ0Lg0KPiA+IA0KPiANCj4gDQo+IA0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTWlwNiBtYWlsaW5nIGxpc3QN Ck1pcDZAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21p cDYNCg0KDQo= --===============1665352269== 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 --===============1665352269==-- From mip6-bounces@ietf.org Tue Jun 05 07:18: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 1HvX34-0002Su-As; Tue, 05 Jun 2007 07:18:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvX32-0002Sn-61 for mip6@ietf.org; Tue, 05 Jun 2007 07:18:00 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvX31-0000Mi-HC for mip6@ietf.org; Tue, 05 Jun 2007 07:18:00 -0400 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l55BH40q026047 for ; Tue, 5 Jun 2007 13:17:04 +0200 Received: from [172.27.205.187] ([172.27.205.187]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Tue, 5 Jun 2007 13:17:58 +0200 Message-ID: <46654666.5000701@alcatel-lucent.fr> Date: Tue, 05 Jun 2007 13:17:58 +0200 From: Bruno Mongazon-Cazavet User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jun 2007 11:17:58.0679 (UTC) FILETIME=[2C191270:01C7A763] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Subject: [Mip6] Comments on 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 Dear writers, Here are my comments/questions to your draft (ed. 01). Sorry, this is a long review but i think its needed if we want to do a good job! Bruno. Abstract section ************ [opinion] I don't see the need to say that revocation is missing in other drafts. Should just say that the draft "defines" a revocation mechanism that applies to mobile IPv6 and its extensions (PMIP6). [opinion] Draft says: 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. I don't think it is the main focus of the draft. It introduces some confusion for the reader. The revocation mechanism has a semantic and the abstract raises first implementation aspects. Revocation is independent of a generic messaging between "any two mobility entities". Moreover, reading further the draft, the revocation appears to be mainly initiated by HA or LMA (CN?) and thus might not require a generic messaging. You might have a look at the abstract of draft-ietf-reg-revok-07.txt. I think it is a perfect abstract of a revocation mechanism. [question] Is the example of PMIP6 usage pertinent in the abstract section? Would a regular MIP6 example not be simpler? Protocol overview section (3.) *********************** [opinion] Usage of the term "Binding Revocation Indication Message" is not consistent with the term "Binding Revocation Message" used in IPv4 revocation draft. Not critical. [question] HA/LMA can issue BRI, but can a CN (Correspondant Node) issue a BRI? BRI message ********** [question] possible senders and receivers of BRI? My understanding is: -HA can send BRI to MN (MIP6) -LMA can send BRI to MAG (PMIP6) Is that correct? I don't get it that way when reading the section intro. It seems MAG can send BRI to LMA also, right? It seems MN can cend BRI to HA also, right? If so, i would rather suggest MAG sends regular deregistration PBU to release the binding rather than revocation. I would also suggest (as recommended by RFC 3775) that MN sends deregistration BU to release the binding rather than revocation. [opinion] "sessions" in Global Per-Peer Bindings (G bit) should be "bindings". The term "session" is confusing. Same in Mobility Options and several places in the draft. [opinion+question] lack of BRI semantics in the section. If P bit (Proxy) is set, binding identification shall be present in Mobility Options. How is a PBU identified? Is it possible to include multiple PBU identifications in a BRI. If P bit not set, same problem to identify a binding. If G bit (global) is set, does the revocation concerns all BU and PBU? Identification of the BU/PBU in Mobility options is critical. I doubt solely the HoA is enough, thoughts? BRA message *********** [question] how do you handle the case where G bit has been set in the BRI and revocation is partially successful (some BU/PBU revoked, others don't)? [opinion] lack of semantics for the Mobility Options field in BRA ("usually match..."). [opinion] lack of semantics for the Status code (BU/PBU discrimination). BCE term is confusing. Use cases ******** [opinion+question] You say that revocation no longer authorizes to receive mobility services. What does it mean exactly "authorizes to receive mobility service"? To revocation terminates prematurely an established BU/PBU with the following consequences: -no more data will be tunneled by the revoker (HA/LMA) toward the peer mobility agent -no more data will be accepted from the revokee for tunneling to the network by the revoker -BU/PBU need to be reestablished Thus revocation implies deregistration at both revoker and revokee level. I think this could be said in the draft before to go into use case details. ===> Use Case 1 (HA to MN) [question] Why is the P bit (Proxy bit) set while PMIP6 is not involved? [question] Is the HoA sufficient to identify the binding? I doubt it. If the MN has multiple CoA (primary and non-primary), multiple BU can exist at HA level. In such case the (CoA, HoA) couple is needed to identify the BU to revoke. ===> Use Case 2 (LMA to MAG) [question] Looks like the A bit is required for PBU revocation. Is it stated previously in revocation message semantics? [opinion] the sending of the RA to terminate the prefix of the MN should be optional (as in IPv4 with the I bit). Ideally, the support of sending such RA when a BRI is received shall be an option of the PBU message (the MAG indicates its capability). In addition, the BRI shall indicate if RA sending is requested on a BRI basis and according to MAG capability. This of course, will require additional working on the draft if a BRI targets multiple BU/PBU with the G bit. ===> Use Case 3 (MAG to LMA) [opinion] BRI/BRA is not required in that case. The MAG can send a regular deregistration BU/PBU to the LMA with suited CoA and HoA. To me the case does not really correspond to a revocation but more to regular behavior of MIP6/PMIP6. Thoughts on this? [question] What is the need for Handoff timer? I have in mind that you can let BU from sMAG expire in LMA and accept new BU from tMAG in LMA. When new BU is in LMA, data gets to MN through tMAG. In the meantime (handoff) data will try to get to MN through sMAG (no guarantee since MN might not be anymore on the sMAG link). Bulk termination ************ [opinion] please use the term "bindings" instead of "sessions". [question] How is the HA address is provided in the BRI? As a specific Mobility Option? Is this what you mean by Home Address Option? If so, is it the same option than the one used to sepcify the HoA in the BRI? I guess a specific Mobility Option is required to distinguish HoA from HA address. [opinion] also note that this section introduces an additional semantic for the G bit (all bindings of a HA/LMA) that was not specified in the field semantic before. MAG Operational summary ********************* [question] if MAG sends a BRI to LMA for maintenance purpose and uses the MAG IP address as the CoA address option (Mobility Option i presume), how does the LMA find the related bindings? I don't see a necessary relationship between MAG IP address and the CoA managed by the MAG. The MAG IP address is not necessarily stored on LMA side, is it? [opinion] i think that using the HNP in the PMIP6 binding management is not a good idea. Any binding can be identified by the couple (CoA, HoA). The identification of binding should be consistent in the draft. The usage of HNP is equivalent because the per-MN prefix model is used in PMIPv6 for now. Should this change in the future, this would cause problems with your draft. Binding revocation signaling in global mobility ********************************** [question] Do you mean that revocation can be used to avoid unexpected mobility service interruption? So, when a BRI is received because the user runs out of money, the user puts additional money and sends a BRA with status "refunded" and the revocation process is relinquished? [opinion] i disagree with the usage of BRI/BRA when returning home while this can be done using RFC 3775 as recommended. Other points ********* -support of the revocation mechanism should be optional as this has been done in IPv4. That is the BU or PBU should be extended with a capability bit. HA/LMA should not send BRA for BU or PBU if MN/MAG does not support it. -not clear if the draft allows a CN (Correspondant Node) to issue a BRI when RO is in effect (MIP6 case) -missing MN Operational summary section to describe MIP6 MN behavior supported by the draft. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 05 11:58:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbQG-0004ZJ-VY; Tue, 05 Jun 2007 11:58:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbQF-0004Yk-RN; Tue, 05 Jun 2007 11:58:15 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvbQE-0002WE-Ps; Tue, 05 Jun 2007 11:58:15 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Jun 2007 17:58:13 +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 l55FwDG4012385; Tue, 5 Jun 2007 17:58:13 +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 l55Fw9DR023805; Tue, 5 Jun 2007 15:58:10 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, 5 Jun 2007 17:58: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: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6-Consensuscall to close issue 93 Date: Tue, 5 Jun 2007 17:58:05 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC040D0263@xmb-ams-337.emea.cisco.com> In-Reply-To: <20070603023726.DFMV1743.oaamta04sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6-Consensuscall to close issue 93 Thread-Index: Acek/wdV5Mb77tH2Swi5l/2MLoVHTgABj9NAAA5PM6AAEj1mkAB/8CMA References: <03ad01c7a544$2a3abc40$d4f6200a@amer.cisco.com> <20070603023726.DFMV1743.oaamta04sl.mx.bigpond.com@PC20005> From: "Pascal Thubert \(pthubert\)" To: "Hesham Soliman" , "Sri Gundavelli \(sgundave\)" , "Henrik Levkowetz" X-OriginalArrivalTime: 05 Jun 2007 15:58:09.0895 (UTC) FILETIME=[505D0F70:01C7A78A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13748; t=1181059093; x=1181923093; 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[Mip6]=20Re=3A=20[nemo]=20Summary=20and=20conclusion= 20of=3A=20DS-MIP6-Consensuscall=20to=20close=20issue=2093 |Sender:=20; bh=9X+5z4K2vNbPUv+N2nNEhPD5p+Ak6x8x/DuahHJHeG0=; b=fd0KzWcIdPwvjViPlmirPww8OqZywx9v4JimoTt2Ep2V8R4Z0l1Z8GSF50vXqUBag+rnQyOQ XrEIerN76WWoWw47U3+O2n0d5c7ZpgYE/XGVg4E5zUO/EPewwYeJOlvP; 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: db284e046c8702920c1c6125bc4d0b7a 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 > >Pascal's email was not sent in private and we don't need an interpretation. >He's alive and well and he didn't object to Raj's conclusion. He clearly >said that we should let the draft move as is. I believe other people who are >also alive and well can speak for themselves if they were >misrepresented..... [Pascal] Thanks Hesham :) :)=20 I might have preferred 3 to be honest, just like I might have preferred to include the RR test for IPv4 traversal and a number of other things like HA in an IPv6 dominant network, etc... But realistically I think the draft is good enough for the purpose and should not be delayed. I voted to keep the mapped address for the same reasons. So my proposal was: 1) publish the current draft ASAP with minimum (editorial) change. 2) promote rapidly a separate I-D on enabling option 3.=20 The PS for that new I-D is almost done thanks to Sri's work and the discussions over this issue 93. There were needs listed, I just added a mobile pseudo-wire. The fact that IPv6 comes straight after the UDP header pre exists to the IPv4 traversal work, so issue 93 is a problem that should be addressed, but can be addressed separately, with backward compatibility to both MIP and MIPTRANS (it's not much harder anyway). I believe it's hard to close the issue cleanly without a commitment to do that work. IMHO, exact same goes for the security issue we discuss over the validity of the CoA: It's generally very hard for a MR to check that it is actually reachable from the HA at the CoA unless RR test is performed. Then again, the problem preexists to MIPTRANS, even if MIPTRANS makes it worse with IPv4 and NATs. There also, I think a small paper proposing a new optional mechanism could be a useful RFC. I hope I made myself clearer now... >I look forward to people expressing that they were misrepresnted by the >chairs. I don't think it's useful for you or Henrik to recount on their >behalf. > >Hesham > > > I understand the need to complete the DSMIP6 as early as > > possible and I appreciate the Chair's position to close > > this issue soon. I really like to see that as well. I also > > believe, IMO, that there is a proper justification in asking > > for Option#3. Its for a simple TLV header, qualifier in UDP > > for the payload packet. Many reasons, examples, protocol > > conventions including 3519's way of dealing with the exact > > same issue, lack of resaved port numbers, opening multiple > > port numbers if we were to extend it later, and many other > > reasons were mentioned and against the one solid reason of > > extra-4 byte overhead. We don't have turn this to a voting > > machine, if we see the need for this request with certain > > flexibility. > > > > Now, w.r.t the voting, I though Pascal did mention the need > > for a supporting new encapsulation mode and off course he > > also wanted this work to close ASAP and that leaves it in > > a ambiguous vote. And if I interpret Vijay's emails correctly, > > his preference is for Option#4 and his second preference is > > for option#3. He can speak up. And, we missed Alessio Casati's > > preference on this issue, he did support option#3. So with > > Jouni Korhonen, he did state that "I prefer more future proof > > extensibility over slight performance hit thus I prefer the > > 4 bytes header like in 3519". I also interpret Yoshi Tsuda's > > vote in favour of option#3. > > > > If this is not rough consensus, atleast, there is sufficient > > interest to discuss this issue further and proper conclude. > > My 2c. > > > > Regards > > Sri > > > > > > > > > > > -----Original Message----- > > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > > Sent: Saturday, June 02, 2007 4:05 AM > > > To: 'Henrik Levkowetz' > > > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > > > Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: > > > DS-MIP6 -Consensuscall to close issue 93 > > > > > > > > > > No, I'm not looking for a vote. I'm looking for consensus > > > on how to > > > > handle the issue. And I don't see any consensus on how to > > > handle the > > > > issue here. > > > > > > =3D> The issue was raised against an existing solution, if > > > there is no support > > > in the WG (6 people against and 5 for it) then clearly there > > > is no agreement > > > that there is an issue to begin with. What are you suggesting > > > we do? If > > > there is no support for the perceived issue then naturally > > > it's rejected. I > > > don't think anyone is changing their mind if we ask the same > > > question again > > > in the space of two weeks... > > > > > > If a 6:5 or 5:4 means no concensus to you, then I'm > > surprised that you > > > accepted the same numbers as concensus on other issues, like > > > the mapped > > > address one or issue 93. Should we repeat all those > > questions again? > > > > > > Hesham > > > > > > > > > > > > > > > Henrik > > > > > > > > > We've always asked for concencus to > > > > > change anything > > > > > in the draft. The numbers that Raj sent clearly indicate > > > > that there is no > > > > > concensus to change the draft. 5:4 is not concensus. > > > > Therefore, I think > > > > > Raj's decision is correct. I hope we don't turn the IETF > > > > into a voting > > > > > organisation, if we do then the whole process of providing > > > > a vote would be > > > > > different from what we do today. > > > > > > > > > > Hesham > > > > > > > > > >> -----Original Message----- > > > > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > > > >> Sent: Saturday, June 02, 2007 9:28 AM > > > > >> To: Narayanan, Vidya > > > > >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Basavaraj Patil > > > > >> Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: > > > > >> DS-MIP6 - Consensuscall to close issue 93 > > > > >> > > > > >> Hi Vidya, Rai, > > > > >> > > > > >> On 2007-06-02 00:13 Narayanan, Vidya said the following: > > > > >>> FWIW, I had also supported going with Option 1 for DS-MIP6. > > > > >> Of course that matters, Vidya, but the more > > important thing here > > > > >> is that it's pretty clear to me that there is *no* > > > rough consensus > > > > >> present. > > > > >> > > > > >> Please don't manufacture one when there isn't one; if there > > > > >> really isn't one, do another call for discussion and/or show > > > > >> of hands, and if the group is deadlocked, use 3929. > > > > >> > > > > >> I can't accept this pronouncement of a consensus, > > rough or not, > > > > >> in the group, neither from my observation of the > > discussion or > > > > >> from the count. > > > > >> > > > > >> > > > > >> Henrik > > > > >> > > > > >> > > > > >>> Vidya > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > >>>> Sent: Friday, June 01, 2007 2:36 PM > > > > >>>> To: Levkowetz > > > > >>>> Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > > > >>>> Subject: [Mip6] Re: [nemo] Summary and conclusion > > of: DS-MIP6 > > > > >>>> - Consensus call to close issue 93 > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> Vijay D. - Option 4 originally and then changed to > > Option 2 > > > > >>>> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - > > Option 3 > > > > >>>> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 > > > > >>>> (Interpreted) George T. - Option 1 Mohamed Khalil > > - Option 3 > > > > >>>> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - > > > > >>>> Option 1 (Interpreted) > > > > >>>> > > > > >>>> So we have a sort of a tie if you strictly go by count. > > > > >>>> If I were to express my own opinion > > (non-chair-hat), I would > > > > >>>> go with option 1 as well for the current DS-MIP6 proposal > > > > >>>> (aligned with my earlier email that if and when GRE is > > > > >>>> planned for use, another UDP port can be > > reserved... But for > > > > >>>> now option 1). That would break any deadlock issues. > > > > >>>> > > > > >>>> Or the other way is to let the chairs decide what is the > > > > >>>> sense of the discussion on the ML and from the > > perspective of > > > > >>>> the charter/scope and urgency of this protocol. > > And from this > > > > >>>> angle as well, I would stick by my conclusion, i.e > > option 1. > > > > >>>> > > > > >>>> -Raj > > > > >>>> > > > > >>>> > > > > >>>> On 6/1/07 3:52 PM, "ext Henrik Levkowetz" > > > > >>>> wrote: > > > > >>>> > > > > >>>>> Hi Raj, > > > > >>>>> > > > > >>>>> On 2007-06-01 21:46 Basavaraj Patil said the following: > > > > >>>>>> So after an extensive discussion on this topic > > which spun > > > > >>>> off into a > > > > >>>>>> discussion about the need/use for GRE, I would like to > > > > >> summarize > > > > >>>>>> where we are with the options that we have. > > > > >>>>>> > > > > >>>>>> Conclusion was that for DS-MIP6, Option 1 which is : " > > > > >> Parse the > > > > >>>>>> protocol header following the UDP header" is good enough. > > > > >>>>> Could you give us an indication of who preferred which > > > > >> option? You > > > > >>>>> seem to be very clear about the outcome, while it was far > > > > >>>> from obvious > > > > >>>>> to me that the counts turned out to support above > > > conclusion... > > > > >>>>> > > > > >>>>> > > > > >>>>> Henrik > > > > >>>>> > > > > >>>>>> So it implies no changes to the current text in the > > > > >>>> DS-MIP6 I-D w.r.t > > > > >>>>>> this issue are needed. > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> It was pointed out that in the future if GRE was > > > > >> determined as a > > > > >>>>>> protocol that needs to be supported as well either for > > > > >>>> MIP6, NEMO or > > > > >>>>>> PMIP6 then it would be specified in the > > appropriate WG and > > > > >>>> a UDP port > > > > >>>>>> reserved for the same. In such a case it would > > > > >> essentially be the > > > > >>>>>> equivalent of option 2 in the choices list (below). > > > > >>>>>> > > > > >>>>>> At this time, the need for GRE especially in the scope > > > > >> of DS-MIP6 > > > > >>>>>> which is primarily MIP6 and NEMO is not proven. Hence > > > > >> we will move > > > > >>>>>> forward with Option 1 and close this issue. > > > > >>>>>> > > > > >>>>>> -Raj > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> On 5/8/07 4:16 PM, "ext Basavaraj Patil" > > > > >>>> wrote: > > > > >>>>>>> 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 Tue Jun 05 12:12: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 1Hvbds-00060m-O7; Tue, 05 Jun 2007 12:12:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvbdr-00060h-MU for mip6@ietf.org; Tue, 05 Jun 2007 12:12:19 -0400 Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvbdq-0004o3-NW for mip6@ietf.org; Tue, 05 Jun 2007 12:12:19 -0400 Received: from smtp1.fc.hp.com (smtp1.fc.hp.com [15.15.136.127]) by atlrel6.hp.com (Postfix) with ESMTP id 0133936247; Tue, 5 Jun 2007 12:12:15 -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 40385142F61; Tue, 5 Jun 2007 16:12:14 +0000 (UTC) Message-ID: <46658B5D.3090702@hp.com> Date: Tue, 05 Jun 2007 12:12:13 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.10 (X11/20070403) MIME-Version: 1.0 To: Bruno Mongazon-Cazavet Subject: Re: [Mip6] Consensus call: Make I-D draft-haley-mip6-mh-signaling-02.txt a WG doc References: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C3F@zrc2hxm2.corp.nortel.com> <46647E44.6030000@hp.com> <46651613.501@alcatel-lucent.fr> In-Reply-To: <46651613.501@alcatel-lucent.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: Mobile IPv6 Mailing List , ext 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 Bruno, Bruno Mongazon-Cazavet wrote: > Hi all, > > I think that binding related signaling should not use a generic > notification signaling. > First, it strongly contradicts RFC 3775: > RFC 3775 says: > > 6.1. Mobility Header > > The Mobility Header is an extension header used by mobile nodes, > correspondent nodes, and home agents in *all messaging related to the > creation and management of bindings*. The subsections within this > section describe the message types that may be sent using the > Mobility Header. I disagree with "strongly contradicts", the Mobility Header can be used for any number of mobility-related purposes, as it is in other drafts. Also, we are creating it to help with binding management - revocation, even signaling, etc. RFC 3775 doesn't restrict it's use with a MUST/MUST NOT either. > RFC 3775 provides some extension capabilities for the MH type that can > be used to specify revocation commands. > It has been done this way in IPv4. > I am not against a generic notification signaling but i think it should > be kept separate from the binding management signaling itself. There are no provisions in 3775 for binding revocation, the only thing a HA can do is deny the binding when the next BU is received. > As far as the generic notification signaling draft is concerned > (draft-haley), i think the term "notification" is not suited. > Generally speaking, I am not expecting a notification to carry a > (command) request or a (command) response. The term "notification" does > not ask for something but rather notify of something. Doing > request-response with a "notification mechanism" is not consistent to > me. If the draft intends to extends RFC 3775 with a generic signaling > capability, it should be stated explicitly. Such a generic signaling > capability could be used for request-response and notification. However, > it should explicitly exclude binding management signaling that is > specified in RFC 3775 and extended in draft-muhanna. The Mobile IPv4 Generic Notification Message is doing similar things, so I'd like to keep the naming consistent if we can. > To summarize my opinion: > draft-haley => should be defined as a generic signaling protocol on top > of MIP6 and exclude binding management signaling (RFC 3775 and futher > revisions) I disagree. We shouldn't restrict the Generic Notification message to certain types of messages, it should be usable for *anything* one mobility entity - the data contained inside is basically opaque. > draft-muhanna => should be defined as extension to RFC 3775 (or new > revision?) without relationship to draft-haley. We just spent the last few days debating the best way to do this, and the authors agreed to work together and use a common mechanism. So I disagree with this as well since I don't want to re-visit that discussion. -Brian > Brian Haley wrote: >> Hi Raj, >> >> Ahmad, Sri and I have talked off-line about how to go forward with >> draft-haley and support draft-muhanna better. We've come to the >> following conclusion (someone update if I got this wrong). >> >> Draft-haley will define a Generic Notification Message (GNM) which is >> a new MH type, and also define two new sub-types - one for Signaling >> Request, one for Signaling Reply (or some wording like that). >> >> The structures would look something like this: >> >> Generic Notification Message (w/MH message pieces, MH Type TBD) >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Payload Proto | Header Len | MH Type | Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Checksum | GNM Type/Sub-Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> In essence, the message is just a container to transport notification >> messages between mobility entities. >> >> They we'd define two Sub-types with the same semantics of the current >> messages in draft-haley: >> >> Signaling Request (GNM Type TBD): >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sequence Number |A| Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Signaling Reply (GNM Type TBD): >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sequence Number | Status | Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> This would give someone that wants to use the semantics of the >> Signaling Messages an easy framework for implentation (sequencing, >> retransmission, etc). All they would have to do is define a mobility >> option with their data to go "inside". >> >> Ahmad would define a new GNM Sub-type for revocation, and whatever >> structures and options to go with it. >> >> I'll update draft-haley with these changes if there are no objections. >> >> Thanks to Ahmad for the suggestions. >> >> -Brian >> >> >> Ahmad Muhanna wrote: >>> Hello, >>> >>> My understanding that the scope of draft-haley is as follows: >>> >>> o A generic container which can be used to communicate multiple >>> functionalities while preserving the MH types. >>> o Introduce a Generic Notification Messages and Generic Notification >>> mechanism that can be used to communicate several common >>> notification event(s) >>> between the HA and the MN. >>> >>> Having said that, I would like to propose a small change to the >>> current Draft-haley revision 02 which would hopefully enrich and >>> enhance the >>> draft. >>> >>> The following summarize the proposed changes: >>> ============================================= >>> 1. Define the first two bytes, of the current generic notification >>> message, and call them , for example, Generic Mobility Container, >>> GMC, or XYZ. >>> >>> 2. The Generic Mobility Container is 2 bytes length and can have up >>> to 64k >>> different values which we can call, for example, GMC Type. i.e. >>> >>> Generic Notification Request message, Generic Notification Ack, >>> Binding Revocation Indication message, Binding Revocation Ack, >>> etc. >>> >>> 3. Every common functionality defines its own messages and mechanism >>> including its own mechanism as fits the need of the specified >>> functionality. >>> >>> 4. Any functionality, e.g. Generic Notification, may define the >>> use of any MH option inside its own messages or define new ones. >>> >>> Here is the format, let us use the Generic Notification and Binding >>> Revocation as examples: >>> 1. Generic Mobility Container Message >>> ===================================== This Signaling Generic Mobility >>> Container Message uses the MH Type value >>> (TBD). >>> >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | GMC Type | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> . . >>> . Message Data . >>> . . >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> 2. Generic Notification >>> ======================= >>> >>> Let us assume that this application requires two messages, a Request and >>> >>> an acknowledgement. >>> >>> 3.1. Generic Notification Request >>> ================================== >>> This Generic Notification Request uses a GMC Type of (TBD). >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | GMC Type | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> . . >>> . Generic Notification Request . >>> . . >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> 3.2. Generic Notification Ack >>> ============================== >>> This Generic Notification Ack uses a GMC Type of (TBD). >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | GMC Type | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> . . >>> . Generic Notification Ack . >>> . . >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> 3. Binding Revocation >>> ====================== >>> >>> The following are the revocation messages that are defined by >>> the Binding Revocation Functionality as specified by the Binding >>> Revocation for IPv6 Mobility draft. >>> 2.1. Binding Revocation Indication >>> ================================== >>> >>> This Binding Revocation Indication uses a GMC Type of (TBD). >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | GMC Type | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> . . >>> . Binding Revocation Indication . >>> . . >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> 2.2. Binding Revocation Acknowledgement >>> ======================================== >>> This Binding Revocation Acknowledgement uses a GMC Type (TBD). >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | GMC Type | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> . . >>> . Binding Revocation Acknowledgement . >>> . . >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> Finally and as a suggestion, I would like to suggest that draft-haley >>> address two things: >>> 1. Introducing the Generic Mobility Container, GMC. >>> 2. Define the Generic Notification Messages and the related Mechanism. >>> >>> While the Binding Revocation for IPv6 Mobility draft can define the >>> Binding Revocation messages and the binding revocation mechanism. >>> >>> >>> Best Regards, >>> Ahmad >>> >>>> -----Original Message----- >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] Sent: >>>> Wednesday, May 30, 2007 12:23 PM >>>> To: Mobile IPv6 Mailing List >>>> 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 >>>> >>>> >>>> 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 >>>> >>> >>> >>> _______________________________________________ >>> 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 Tue Jun 05 12:35: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 1Hvbzu-0005Zc-IZ; Tue, 05 Jun 2007 12:35:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvbzs-0005P7-Sm for mip6@ietf.org; Tue, 05 Jun 2007 12:35:04 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvbzq-0002vS-H3 for mip6@ietf.org; Tue, 05 Jun 2007 12:35:04 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 05 Jun 2007 09:34:34 -0700 X-IronPort-AV: i="4.16,386,1175497200"; d="scan'208"; a="377289298:sNHT15645328310" 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 l55GYYUU016954; Tue, 5 Jun 2007 09:34:34 -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 l55GYDag019945; Tue, 5 Jun 2007 16:34:25 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 09:34:16 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 09:34:15 -0700 From: "Sri Gundavelli" To: "'Brian Haley'" , "'Bruno Mongazon-Cazavet'" References: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C3F@zrc2hxm2.corp.nortel.com> <46647E44.6030000@hp.com> <46651613.501@alcatel-lucent.fr> <46658B5D.3090702@hp.com> Subject: RE: [Mip6] Consensus call: Make I-D draft-haley-mip6-mh-signaling-02.txt a WG doc Date: Tue, 5 Jun 2007 09:34:15 -0700 Message-ID: <00df01c7a78f$5b406fe0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <46658B5D.3090702@hp.com> thread-index: AcenjEuprykA20yaQnWNdos109MLpAAAhx/g X-OriginalArrivalTime: 05 Jun 2007 16:34:16.0116 (UTC) FILETIME=[5B882740:01C7A78F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1577; t=1181061274; x=1181925274; 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]=20Consensus=20call=3A=20Make=09I-D=09draft-hal ey-mip6-mh-signaling-02.txt=20a=20WG=20doc |Sender:=20; bh=T4BbSiDN4ImuUrDYhyv6AeKWEys1X8U07PvkKp9JsqE=; b=ansOc8gzj46Fs8/zMBaJNLGVVDPfK9c+0569y1PROVJAUWem4HcGupBjvJ9MgqPL31uZYe7u lNbLxunRx/MV0x4hSQt6zAPmpSHUJKlv7GbhwYu3tDAESC8bJY0XnskV; 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: 4adaf050708fb13be3316a9eee889caa 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 Hi Bruno, Adding to Brian's comment .. > -----Original Message----- > From: Brian Haley [mailto:brian.haley@hp.com] > Sent: Tuesday, June 05, 2007 9:12 AM > To: Bruno Mongazon-Cazavet > Cc: Basavaraj Patil; Mobile IPv6 Mailing List; ext Sri Gundavelli > Subject: Re: [Mip6] Consensus call: Make I-D > draft-haley-mip6-mh-signaling-02.txt a WG doc > > Hi Bruno, > > Bruno Mongazon-Cazavet wrote: > > Hi all, > > > > I think that binding related signaling should not use a generic > > notification signaling. > > First, it strongly contradicts RFC 3775: > > RFC 3775 says: > > > > 6.1. Mobility Header > > > > The Mobility Header is an extension header used by mobile nodes, > > correspondent nodes, and home agents in *all messaging > related to the > > creation and management of bindings*. The subsections within this > > section describe the message types that may be sent using the > > Mobility Header. > Thanks for the review comments. The notification messages have a relation to the established session between the entities. The message has no purpose, if there is no session. The exchanged message using the signaling does not have to be just about a creation/deletion of the BCE, but it can a message that has a relation to that state. A message indicating that the mobile node's prepayed service is getting expired has a relation to that session. So, with other messages, "your home agent is getting rebooted in 5 minutes". So, the notification message must use the MH signaling. Regards Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 06 03:14: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 1HvpjI-0002Kg-T0; Wed, 06 Jun 2007 03:14:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvpjH-0002KY-4n for mip6@ietf.org; Wed, 06 Jun 2007 03:14:51 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvpjG-0001yU-7J for mip6@ietf.org; Wed, 06 Jun 2007 03:14:51 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0F9F720645; Wed, 6 Jun 2007 09:14:49 +0200 (CEST) X-AuditID: c1b4fb3c-a9cedbb0000073d5-1a-46665ee8eff0 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E3A22203A4; Wed, 6 Jun 2007 09:14:48 +0200 (CEST) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 09:14:48 +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] question on DS-MIPv6 security Date: Wed, 6 Jun 2007 09:14:47 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] question on DS-MIPv6 security Thread-Index: AcekORQS3FnWSBDKSwKA12zKkyDn+gCtfhcgAEY2abA= References: From: "Karen E. Nielsen (AH/LMD)" To: "Vijay Devarapalli" , X-OriginalArrivalTime: 06 Jun 2007 07:14:48.0178 (UTC) FILETIME=[5DE50D20:01C7A80A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 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 Vijay, Thanks. Yes I understand this. What I think is important however is also=20 the relation to IPSec. I.e., one thing is the packet format another issue is what the packet format represents and how it is negotiated. For example, as far as I understand it anyway, then using the standard ESP transport protection=20 for BU in DS-MIP means that one can use IPSec SA's agreed on beforehand in-between the HA and the MN, as these are anchored on the Home Addresses. However if the optional tunnel mode encapsulation is used, one will use IKEv2 to detect NAT traversal and establish the appropriate SAs (ESP tunnel or ESP UDP tunnel, and now also IPv4 or IPv6 transport layer) after which the BU can be authenticated - Right ? BTW. How is it thought that HA and MNs will decide upon which BU protection mechanism and thus packet format to use - the standard or the optional ?=20 Thanks, Karen > -----Original Message----- > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com]=20 > Sent: 4. juni 2007 23:36 > To: Karen E. Nielsen (AH/LMD); mip6@ietf.org > Subject: RE: [Mip6] question on DS-MIPv6 security >=20 > Hello Karen, >=20 > The stuff that you cut and pasted from an earlier mail of=20 > mine shows reverse tunneled IPsec protected DS-MIPv6 traffic=20 > when the mobile node is attached to an IPv4 access network.=20 > Nothing about a binding update. >=20 > If a mobile node chooses to reserve tunnel IPv6 traffic with=20 > ESP protection when it is attached to an IPv6 access network,=20 > the packet format would be as follows. >=20 > IPv6 hdr (src=3DMN-IPv6-CoA, dst=3DHA-IPv6)=20 > ESP hdr=20 > IPv6 (src=3DMN-IPv6-HoA, dst=3DCN)=20 > Payload=20 >=20 > If the same mobile node ends up on an IPv4 access network,=20 > the packet format for the same traffic flow will be as follows. >=20 > IPv4 hdr (src=3DMN-IPv4-CoA, dst=3DHA-IPv4)=20 > UDP hdr=20 > ESP hdr=20 > IPv6 (src=3DMN-IPv6-HoA, dst=3DCN)=20 > Payload=20 >=20 > If the payload traffic does not need ESP tunnel mode=20 > protection, then the packet formats would be (when the mobile=20 > node is on an > IPv6 access network) >=20 > IPv6 hdr (src=3DMN-IPv6-CoA, dst=3DHA-IPv6)=20 > IPv6 (src=3DMN-IPv6-HoA, dst=3DCN)=20 > Payload=20 >=20 > and (when the mobile node is on an IPv4 access network) >=20 > IPv4 hdr (src=3DMN-IPv4-CoA, dst=3DHA-IPv4)=20 > UDP hdr=20 > IPv6 (src=3DMN-IPv6-HoA, dst=3DCN)=20 > Payload=20 >=20 > Vijay >=20 > > -----Original Message----- > > From: Karen E. Nielsen (AH/LMD)=20 > [mailto:karen.e.nielsen@ericsson.com] > > Sent: Friday, June 01, 2007 3:39 AM > > To: mip6@ietf.org > > Subject: [Mip6] question on DS-MIPv6 security > >=20 > > Hi, > >=20 > > A couple of questions to the security model of DS-MIPv6.=20 > >=20 > > The option for BU protection described below in option 2 in=20 > a mail cut=20 > > from the archives seems to say UDP ESP tunnel encapsulation (RFC=20 > > 3948). Is that correctly understood and if yes then why=20 > would you need=20 > > a specific port for this usage in DS-MIPv6 ? > >=20 > > ******snip***** > > To: "Basavaraj Patil" , "ext Tsirtsis,=20 > > George" , "Sri Gundavelli" > cisco.com>, "Hesham Soliman" ,=20 > > ietf.org>, > >=20 > > Subject: RE: [Mip6] The use of GRE > > From: "Vijay Devarapalli" > > Date: Wed, 16 May 2007 14:33:59 -0700 > > Cc:=20 > > List-help: > > > > List-id: mip6.ietf.org > > List-post: > > > List-subscribe: > >,=20 > > > > > > List-unsubscribe:=20 > > > >,=20 > > > > > > References: > > Thread-index:=20 > > AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAAa6kGYQAInDPQ > > Thread-topic: [Mip6] The use of GRE > >=20 > > Hello Raj, > >=20 > > We might actually end up with option 2. I see three=20 > reserved UDP ports=20 > > with DS-MIPv6 already. > >=20 > > 1. One UDP port indicating IPv4/IPv6. You parse the IP version=20 > > field to figure out whether it is IPv4 or IPv6.=20 > > 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=20 > > IPv4 hdr (src=3DMN-IPv4-CoA, dst=3DHA-IPv4)=20 > > UDP hdr=20 > > ESP hdr=20 > > IPv6 (src=3DMN-IPv6-HoA, dst=3DCN)=20 > > Payload > > 3. One reserved UDP port for GRE encapsulation in DS-MIPv6.=20 > >=20 > > So this is almost option 2. :) Option 2 was one reserved port per=20 > > protocol that follows the UDP header. > >=20 > > Vijay > > ********************* > >=20 > > On the other hand, this option is not described in the DS-MIP draft=20 > > which only seems to reference the destination option/routing header=20 > > versions > >=20 > > of the BU and not the optional tunneling version from RFC=20 > 4877. I find=20 > > it a little confusing that optional ways to transmit BU's are=20 > > described on the list > >=20 > > and not in the draft - ?=20 > > =20 > > Secondly, looking into the destination option/routing=20 > header versions=20 > > of the BU as described in Section 4.1 of DS-MIP, then these are=20 > > described without security > >=20 > > headers, although they in Section 5 of DS-MIP are said to=20 > be protected=20 > > using IPSec (as in standard [MIP] modulo RFC 4285). > > In this respect, > >=20 > > I am rather concerned with the processing of the stack:=20 > > IPv4 header (src=3DV4ADDR, dst=3DHA_V4ADDR) UDP header > > IPv6 header (src=3DV4CoA, dst=3DHAADDR) > > DST-OPT HAO (IPv6 home address) > > ESP (transport) > > Mobility header BU [IPv4 HAO] > >=20 > > as the appearance of ESP after a transport header will=20 > require a not=20 > > very nice processing flow in the stack, unless IPSec is made to=20 > > understand > >=20 > > "IP" headers of form IP-UDP-IP - Has this been discussed or=20 > is it not=20 > > perceived as a problem by other implementators ? > >=20 > > I have to admit that I have been away from this list in a very long=20 > > time, and yes, I haven't checked the archives all that way=20 > back, but=20 > > I hope you can, at least, let me know whether this has been thought=20 > > through, and I just haven't grasped the details yet, or=20 > whether these=20 > > details are still being finalized. > >=20 > > Thanks, > > Karen > >=20 > >=20 > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 06 10:55: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 1Hvwv7-0008R6-Pj; Wed, 06 Jun 2007 10:55:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvwv6-0008Qq-0i; Wed, 06 Jun 2007 10:55: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 1Hvwv5-00020G-Fo; Wed, 06 Jun 2007 10:55:32 -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 l56Et8ih026879; Wed, 6 Jun 2007 17:55:25 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 17:55:21 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 09:55:12 -0500 Received: from 10.241.58.179 ([10.241.58.179]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 6 Jun 2007 14:55:11 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 06 Jun 2007 09:55:19 -0500 Subject: Re: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 From: Basavaraj Patil To: Vijay Devarapalli , Mobile IPv6 Mailing List , Message-ID: Thread-Topic: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiASz3DPBAJmM6QAAV7s87g== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Jun 2007 14:55:12.0478 (UTC) FILETIME=[AF42B7E0:01C7A84A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 Vijay, Sure... So I guess you are okay with not having to add the 4 byte header (Option 3). -Raj On 6/4/07 4:05 PM, "ext Vijay Devarapalli" wrote: > Raj, > > This is fine with me. But today we already have option 2. One > reserved UDP port for IPv4/v6 and another for ESP encapsulation > of DS-MIPv6 tunneled packets. > > Vijay > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Friday, June 01, 2007 12:47 PM >> To: ext Basavaraj Patil; Mobile IPv6 Mailing List; nemo@ietf.org >> Subject: [Mip6] Summary and conclusion of: DS-MIP6 - >> Consensus call to close issue 93 >> >> >> So after an extensive discussion on this topic which spun off into a >> discussion about the need/use for GRE, I would like to >> summarize where we >> are with the options that we have. >> >> Conclusion was that for DS-MIP6, Option 1 which is : " Parse >> the protocol >> header following the UDP header" is good enough. >> >> So it implies no changes to the current text in the DS-MIP6 >> I-D w.r.t this >> issue are needed. >> >> >> It was pointed out that in the future if GRE was determined >> as a protocol >> that needs to be supported as well either for MIP6, NEMO or >> PMIP6 then it >> would be specified in the appropriate WG and a UDP port >> reserved for the >> same. In such a case it would essentially be the equivalent >> of option 2 in >> the choices list (below). >> >> At this time, the need for GRE especially in the scope of >> DS-MIP6 which is >> primarily MIP6 and NEMO is not proven. Hence we will move forward with >> Option 1 and close this issue. >> >> -Raj >> >> >> >> On 5/8/07 4:16 PM, "ext Basavaraj Patil" >> wrote: >> >>> >>> 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 Wed Jun 06 11:02: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 1Hvx1e-0006RW-SQ; Wed, 06 Jun 2007 11:02:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvx1e-0006QD-4k; Wed, 06 Jun 2007 11:02:18 -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 1Hvx1c-0003OL-MH; Wed, 06 Jun 2007 11:02:18 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l56F1xNj024983; Wed, 6 Jun 2007 18:02:14 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 18:02:04 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 10:01:29 -0500 Received: from 10.241.58.179 ([10.241.58.179]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 6 Jun 2007 15:01:29 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 06 Jun 2007 10:01:37 -0500 Subject: Re: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 From: Basavaraj Patil To: ext Basavaraj Patil , Mobile IPv6 Mailing List , , ext Jari Arkko Message-ID: Thread-Topic: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiASz3DPBAJmM6QAAV7s87gAAOFNq In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Jun 2007 15:01:29.0936 (UTC) FILETIME=[903E3D00:01C7A84B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 Since concerns about rough consensus, process followed and who said what w.r.t the various options seem to be dragging on, I have requested Jari Arkko (AD) to review the discussion and the thread and provide a recommendtion on next steps. -Raj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 06 17:40: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 1Hw3Em-00017k-7n; Wed, 06 Jun 2007 17:40:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3El-00017c-6l; Wed, 06 Jun 2007 17:40:15 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw3Ek-0002Db-OZ; Wed, 06 Jun 2007 17:40:15 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2EECF19868A; Thu, 7 Jun 2007 00:40:13 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D654019867C; Thu, 7 Jun 2007 00:40:12 +0300 (EEST) Message-ID: <466729AE.3000707@piuha.net> Date: Thu, 07 Jun 2007 00:39:58 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 References: In-Reply-To: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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, (Sorry for not responding to this sooner -- I was traveling. But I have now reviewed the list discussion and talked to some of you as well.) First, it should be obvious that if we need to worry about the difference of one or two persons, then we don't have consensus. I appreciate the fact that we sometimes end up in a controversial situation where there is no clear consensus. But we should aim to run the working groups by consensus rather than move forward when a slim margin shows that some resolution "wins". That is, if the opinions are so diverse then more discussion is probably needed. Also, it would be better if people who post opinions actually state why they believe what they believe ("Approach A is already in my implementation" or "Approach B makes X very hard"). We also need to listen to what the others are saying, and be able to change our opinion when we learn new things. Everyone on this WG needs to work harder towards consensus. The other observation I would make is that in any case the conclusions sent by the chairs need to be accurate. I realize that in some cases a response is unclear or may change/come late. But the counts need to be right, and contain people who have sent their opinions to the list. Basavaraj has already admitted he made a mistake here, and has promised to get this right in the future. A datapoint from my discussion with the people involved in this: I did not hear any extreme opinions about the technical matter itself. None of the main alternatives were seen to cause significant problems, even if everyone had their favorite alternative. With that in mind, I do not believe we should make this process a long one. An almost perfect solution now is better than a perfect solution later... Hesham and Henrik talked about the nature of the consensus call and that is actually an interesting issue. One opinion was that lack of consensus means we can not move forward until the issue is resolved. Another opinion was that lack of consensus means the issue was rejected and we move forward without changing the document. I'd say which approach to use is a judgment call. The former approach is the usual IETF one. We really need to solve issues that we know exist in the specification. But in some cases, particularly with new features someone suggests to adopt, it may make sense to employ the other approach. Then lack of consensus to adopt/not adopt the feature means the document progresses anyway, assuming of course there was earlier consensus about the current document. Issue 93 is perhaps a borderline case, as you could argue its either a new feature or an issue in the current document. How do we move forward? I would like to extend the consensus call for a short period (a week) and see if we can reach a better conclusion. In addition to the preferred alternative (1-4) and rationale, I think it would also be useful to understand how the group feels about the text in the current document. Does it adequately describe the operation with regards to this issue (irrespective of whether you prefer the used approach or not)? If no, some change will be needed. Hesham has also raised a concern about one earlier issue (73). I will take a look at the discussion to see if we need to revisit that. Note that we will not revisit old issues lightly, only in case of when substantial new information comes to light. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 06 20:54: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 1Hw6GM-0006TZ-3C; Wed, 06 Jun 2007 20:54:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw6GK-0006TR-TN; Wed, 06 Jun 2007 20:54:04 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw6GI-0003kq-Qb; Wed, 06 Jun 2007 20:54:04 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070607005359.TBHF25724.omta05sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Thu, 7 Jun 2007 00:53:59 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta07sl.mx.bigpond.com with ESMTP id <20070607005358.PNHE23012.oaamta07sl.mx.bigpond.com@PC20005>; Thu, 7 Jun 2007 00:53:58 +0000 From: "Hesham Soliman" To: "'Jari Arkko'" , "'Basavaraj Patil'" Subject: RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus call toclose issue 93 Date: Thu, 7 Jun 2007 10:53:49 +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: Aceog07TO1La/gT9RhyphyL26IwOawAGttwQ In-Reply-To: <466729AE.3000707@piuha.net> Message-Id: <20070607005358.PNHE23012.oaamta07sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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 Thanks Jari, This is the perfect answer to our discussion. I hope we can move on within the extended week to resolve this. Folks, please feel free to express more opinions, change opinions ...etc Hesham > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Thursday, June 07, 2007 7:40 AM > To: Basavaraj Patil > Cc: nemo@ietf.org; Mobile IPv6 Mailing List > Subject: Re: [Mip6] Summary and conclusion of: DS-MIP6 - > Consensus call toclose issue 93 > > All, > > (Sorry for not responding to this sooner -- I was traveling. > But I have now reviewed the list discussion and talked > to some of you as well.) > > First, it should be obvious that if we need to worry about > the difference of one or two persons, then we don't have > consensus. I appreciate the fact that we sometimes end > up in a controversial situation where there is no clear > consensus. But we should aim to run the working groups > by consensus rather than move forward when a slim > margin shows that some resolution "wins". That is, if > the opinions are so diverse then more discussion is > probably needed. Also, it would be better if people > who post opinions actually state why they believe > what they believe ("Approach A is already in my > implementation" or "Approach B makes X very > hard"). We also need to listen to what the others > are saying, and be able to change our opinion when > we learn new things. Everyone on this WG needs > to work harder towards consensus. > > The other observation I would make is that in any > case the conclusions sent by the chairs need to > be accurate. I realize that in some cases a response > is unclear or may change/come late. But the counts > need to be right, and contain people who have > sent their opinions to the list. Basavaraj has already > admitted he made a mistake here, and has promised > to get this right in the future. > > A datapoint from my discussion with the people > involved in this: I did not hear any extreme opinions > about the technical matter itself. None of the main > alternatives were seen to cause significant problems, > even if everyone had their favorite alternative. With > that in mind, I do not believe we should make this > process a long one. An almost perfect solution > now is better than a perfect solution later... > > Hesham and Henrik talked about the nature of the > consensus call and that is actually an interesting > issue. One opinion was that lack of consensus > means we can not move forward until the issue > is resolved. Another opinion was that lack of > consensus means the issue was rejected and we > move forward without changing the document. > I'd say which approach to use is a judgment call. > The former approach is the usual IETF one. We really > need to solve issues that we know exist in the > specification. But in some cases, particularly with > new features someone suggests to adopt, it may > make sense to employ the other approach. Then > lack of consensus to adopt/not adopt the feature > means the document progresses anyway, assuming > of course there was earlier consensus about the > current document. Issue 93 is perhaps a borderline > case, as you could argue its either a new feature > or an issue in the current document. > > How do we move forward? I would like to extend > the consensus call for a short period (a week) > and see if we can reach a better conclusion. > In addition to the preferred alternative (1-4) and > rationale, I think it would also be useful to understand > how the group feels about the text in the current > document. Does it adequately describe the operation > with regards to this issue (irrespective of whether you > prefer the used approach or not)? If no, some change > will be needed. > > Hesham has also raised a concern about one > earlier issue (73). I will take a look at the discussion > to see if we need to revisit that. Note that we > will not revisit old issues lightly, only in case > of when substantial new information comes to > light. > > Jari > > > _______________________________________________ > 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 Jun 06 22:54: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 1Hw88g-0001Gh-QK; Wed, 06 Jun 2007 22:54:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw88f-0001GZ-VP; Wed, 06 Jun 2007 22:54:17 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw88f-00011x-Fr; Wed, 06 Jun 2007 22:54:17 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070607025415.BRBC25724.omta05sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Thu, 7 Jun 2007 02:54:15 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta07sl.mx.bigpond.com with ESMTP id <20070607025414.RNUJ23012.oaamta07sl.mx.bigpond.com@PC20005>; Thu, 7 Jun 2007 02:54:14 +0000 From: "Hesham Soliman" To: , Date: Thu, 7 Jun 2007 12:54:07 +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: Aceorx2gDxKnsRnRRCe92adTSLzcvA== Message-Id: <20070607025414.RNUJ23012.oaamta07sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Subject: [Mip6] issue 93 summary 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 In light of the discussions that went on I thought it would be useful to summarise the issue and discussions so far to give people who haven't kept up an insight into what this is all about. First the issue text discussed the need for a "TLV" type encoding between the outer IP header and the inner UDP header. The reason specified in the issue was that the upper layer parsing the packet can't tell what information follows UDP unless it is explicitly encoded. Upon further discussion it was clear that this rationale is not true because the upper layer can always parse the version field in the IP header following UDP. However, the following question was "what if the information following UDP was not an IP header?". One could encode messages (at least in theory) that follow UDP and that are not IP. But to save space and reading time, the main (probably only) example for such information is the use of GRE encapsulation. Some people don't see the need for the use of GRE and some people do. I suggested that GRE can be used before UDP and not after, but that was seen as unhelpful for cases where a NAT is present. Since I, after substantial effort, still couldn't find out what the deployment scenario that needs this might be, I won't try to invent a scenario for GRE on behalf of people who are calling for it and I'll leave the floor open for that discussion. The point I wanted to highlight here that practically this is the only reason left for adding TLV encoding. Finally, there are 3 options available for us to move forward and I'll use the same numbers that Raj use to avoid confusing people: 1. Do nothing, keep the draft as is. 2. Specify a different port number for the different format suggested. 3. Add the TLV encoding suggested in the issue. 1) above implies that should there be agreement in future that the format suggested in this issue is necessary, it can be achieved using option 2 (i.e. specify a new port that carries that format). This can be used if, for example, GRE is needed for NETLMM. A MAG can use a different port from the one used by the MN. The main reasons expressed by people for choosing 1 were: a) Adding 4 bytes on every packet is not needed. b) GRE is not needed. 2) above is pretty clear to everyone I think but Karen Nielsen raised some questions that people should read. 3) I believe 3 is also clear for everyone. Going to 3 will not require a move to 2) later. Of course this comes at the cost mentioned above. I believe the main reason expressed by people for this option was "future proof". So, hopefully this gives a summary of the discussion so far. I think there are basically two ways of finding concensus: 1. Discuss the rationale a lot more to make either side move. For instance, discuss the deployment scenarios that require GRE, what is "future proof", why the extra 4 bytes are an issue for those who chose 1) ...etc 2. Due to current threads more people might express their opionions. I'm not too hopeful with 2) above because most of the people that are actively involved have commented. Plus it would actually be nice to see 1) being achieved once in a while! So let's try to do that. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 06 23:53: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 1Hw94M-0000hV-Bj; Wed, 06 Jun 2007 23:53:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw94K-0000XW-T1; Wed, 06 Jun 2007 23:53:52 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw93i-0001d5-1g; Wed, 06 Jun 2007 23:53:17 -0400 Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-1.cisco.com with ESMTP; 07 Jun 2007 22:19:25 +0530 X-IronPort-AV: i="4.16,392,1175452200"; d="scan'208"; a="81614982:sNHT71267386" 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 l573r99K016748; Thu, 7 Jun 2007 11:53:09 +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 l573qaqU022428; Thu, 7 Jun 2007 03:53:00 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); Thu, 7 Jun 2007 11:52:36 +0800 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] Summary and conclusion of: DS-MIP6 - Consensus calltoclose issue 93 Date: Thu, 7 Jun 2007 11:52:34 +0800 Message-ID: <35912544FC930E49BF20EF16C3EF2765024ACE7B@xmb-hkg-416.apac.cisco.com> In-Reply-To: <20070607005358.PNHE23012.oaamta07sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus calltoclose issue 93 Thread-Index: Aceog07TO1La/gT9RhyphyL26IwOawAGttwQAAMam6A= From: "Yoshi Tsuda \(yotsuda\)" To: "Hesham Soliman" , "Jari Arkko" , "Basavaraj Patil" , "Henrik Levkowetz" , "Sri Gundavelli \(sgundave\)" X-OriginalArrivalTime: 07 Jun 2007 03:52:36.0928 (UTC) FILETIME=[4984F400:01C7A8B7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5960; t=1181188390; x=1182052390; 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]=20Summary=20and=20conclusion=20of=3A=20DS-MIP6 =20-=20Consensus=20calltoclose=20issue=2093 |Sender:=20; bh=DAqIv9j1ayDqnWH6hREaggbM80iVRB94oSvaZezGVek=; b=n64dNmQLG6uNDJe+th0CiuJEvJ+Ubfyjk3dF5CAoev/x6ZOwITb6ekoxSFxHRCzzIAbRxAv9 Dqf3zM1YybIu8h1M2chgnyhH3fJrM8mzWiBn7t5MSERrvWudZjFDgjuxlIhTHV7wMp1y/HCtCz C1p1Gg+1uH+TIReIwyze2IEtI=; 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: 6ffdee8af20de249c24731d8414917d3 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 Hello Jari, Hesham, Sri and all: Thank you for your works! If possible, and if you have time, I prefer the option#3. I'm sorry for my late response. Does anyone have any time constraint to publish the current draft now? If not, I deeply agree with Henrik; it would be sad to see many emails about a -bis document just after publishing the current draft... Personally, I don't care too much for GRE; if there are any other better mechanisms than GRE, it would be fine. I agree with Hesham, if we got a port number, it would be wonderful. But, if not, it would be still great to have some encapsulation mechanisms as a second option. GRE is just available in MIPv4 so far. :) Have a nice day! Cheers. -Yoshi > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Thursday, June 07, 2007 9:54 AM > To: 'Jari Arkko'; 'Basavaraj Patil' > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > Subject: RE: [Mip6] Summary and conclusion of: DS-MIP6 -=20 > Consensus calltoclose issue 93 >=20 > Thanks Jari, This is the perfect answer to our discussion. I=20 > hope we can move on within the extended week to resolve this.=20 > Folks, please feel free to express more opinions, change=20 > opinions ...etc >=20 > Hesham=20 >=20 > > -----Original Message----- > > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent:=20 > Thursday, June 07, 2007 7:40 AM > To: Basavaraj Patil > Cc:=20 > nemo@ietf.org; Mobile IPv6 Mailing List > Subject: Re:=20 > [Mip6] Summary and conclusion of: DS-MIP6 - > Consensus call=20 > toclose issue 93 > > All, > > (Sorry for not responding=20 > to this sooner -- I was traveling. > > But I have now reviewed the list discussion and talked >=20 > to some of you as well.) > > First, it should be obvious=20 > that if we need to worry about > the difference of one or=20 > two persons, then we don't have > consensus. I appreciate=20 > the fact that we sometimes end > up in a controversial=20 > situation where there is no clear > consensus. But we should=20 > aim to run the working groups > by consensus rather than=20 > move forward when a slim > margin shows that some resolution=20 > "wins". That is, if > the opinions are so diverse then more=20 > discussion is > probably needed. Also, it would be better if=20 > people > who post opinions actually state why they believe =20 > > what they believe ("Approach A is already in my >=20 > implementation" or "Approach B makes X very > hard"). We=20 > also need to listen to what the others > are saying, and be=20 > able to change our opinion when > we learn new things.=20 > Everyone on this WG needs > to work harder towards consensus. > > > > The other observation I would make is that in any > case=20 > the conclusions sent by the chairs need to > be accurate. I=20 > realize that in some cases a response > is unclear or may=20 > change/come late. But the counts > need to be right, and=20 > contain people who have > sent their opinions to the list.=20 > Basavaraj has already > admitted he made a mistake here, and=20 > has promised > to get this right in the future. > > > > A datapoint from my discussion with the people > involved=20 > in this: I did not hear any extreme opinions > about the=20 > technical matter itself. None of the main > alternatives=20 > were seen to cause significant problems, > even if everyone=20 > had their favorite alternative. With > that in mind, I do=20 > not believe we should make this > process a long one. An=20 > almost perfect solution > now is better than a perfect=20 > solution later... > > > > Hesham and Henrik talked about the nature of the >=20 > consensus call and that is actually an interesting > issue.=20 > One opinion was that lack of consensus > means we can not=20 > move forward until the issue > is resolved. Another opinion=20 > was that lack of > consensus means the issue was rejected=20 > and we > move forward without changing the document. > > I'd say which approach to use is a judgment call. > > The former approach is the usual IETF one. We really >=20 > need to solve issues that we know exist in the >=20 > specification. But in some cases, particularly with > new=20 > features someone suggests to adopt, it may > make sense to=20 > employ the other approach. Then > lack of consensus to=20 > adopt/not adopt the feature > means the document progresses=20 > anyway, assuming > of course there was earlier consensus=20 > about the > current document. Issue 93 is perhaps a=20 > borderline > case, as you could argue its either a new=20 > feature > or an issue in the current document. > > > > How do we move forward? I would like to extend > the=20 > consensus call for a short period (a week) > and see if we=20 > can reach a better conclusion. > > In addition to the preferred alternative (1-4) and >=20 > rationale, I think it would also be useful to understand >=20 > how the group feels about the text in the current >=20 > document. Does it adequately describe the operation > with=20 > regards to this issue (irrespective of whether you > prefer=20 > the used approach or not)? If no, some change > will be needed. > > > > Hesham has also raised a concern about one > earlier=20 > issue (73). I will take a look at the discussion > to see if=20 > we need to revisit that. Note that we > will not revisit old=20 > issues lightly, only in case > of when substantial new=20 > information comes to > light. > > > > Jari > > > > > > _______________________________________________ > > 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 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 07 00:20: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 1Hw9U6-0002du-6e; Thu, 07 Jun 2007 00:20:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw9U4-0002WT-Cz; Thu, 07 Jun 2007 00:20:28 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw9U1-0007d7-U4; Thu, 07 Jun 2007 00:20:28 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 06 Jun 2007 21:20:21 -0700 X-IronPort-AV: i="4.16,392,1175497200"; d="scan'208"; a="161437969:sNHT50325849" 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 l574KLfH026313; Wed, 6 Jun 2007 21:20:21 -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 l574KKaI011322; Thu, 7 Jun 2007 04:20:21 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 21:20:20 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 21:20:20 -0700 From: "Sri Gundavelli" To: "'Jari Arkko'" , "'Basavaraj Patil'" , "'Henrik Levkowetz'" References: <20070607005358.PNHE23012.oaamta07sl.mx.bigpond.com@PC20005> <35912544FC930E49BF20EF16C3EF2765024ACE7B@xmb-hkg-416.apac.cisco.com> Subject: RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus calltoclose issue 93 Date: Wed, 6 Jun 2007 21:20:19 -0700 Message-ID: <004f01c7a8bb$28b99470$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceog07TO1La/gT9RhyphyL26IwOawAGttwQAAMam6AAA88QsA== In-Reply-To: <35912544FC930E49BF20EF16C3EF2765024ACE7B@xmb-hkg-416.apac.cisco.com> X-OriginalArrivalTime: 07 Jun 2007 04:20:20.0585 (UTC) FILETIME=[2922DD90:01C7A8BB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3729; t=1181190021; x=1182054021; 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]=20Summary=20and=20conclusion=20of=3A=20DS-MIP6 =20-=20Consensus=20calltoclose=20issue=2093 |Sender:=20; bh=JFDCwvvGjzlg0bjqmqtJ3bDA/RBLlJPZ2PVe5Me/SiM=; b=rpVc+Eo53OJm6vuWon+QCy/RstbAxABn6a+aVW6D5f59KRkaWOsfk9CNPXPgjZG2kw/0kjGn rm8luyrYIto12xRWQgWofLUSsAD/mgn/mZr68z29wYTDvtFCwyErbmu8; 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: 287c806b254c6353fcb09ee0e53bbc5e 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 A question was asked, why do we need a 4-byte header when we carry IPv4/IPv6 packets in a IPv4-UDP tunnel header ? Reasons were stated as why we don't need it and why there is no next IP version in our lifetimes. This is the other side of the coin as why we would need it. I'm sure, we can converge and decide on one solution, what ever that is. Summary of the comments captured favoring option#3. Lets close this thread ASAP. 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. How 3519 handles the exact same scenario When a packet is carried in a UDP transport, its important that the payload is classified by a prior header. Designers of 3519 chose that option. Please see the 4 byte TLV header in RFC-3519, Section 3.1. 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 | Next Header | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3. Extensibility and Future proof We cannot say, we will only carry raw IPv4 or IPv6 payloads and so the 1st byte IPv4 version lookup is sufficient. Lets learn some thing from the IPv6 address space design, from the Y2K problem or the millennium bug. Allow the provision for carrying other types of messages. Example: - GRE Header (Explained below in item#6) - Other encapsulation headers 4. Tunnel Keep Alive message When DSMIP chose IPv4 UDP transport for NAT traversal, the need for keepalive messaging between the tunnel peers for keeping the NAT bindings came up. The authors of the draft chose to use MIP6 signaling messages BU/BA as a way to refresh the keepalive messages. IMO, having a simple keepalive messages is lot more useful than an expensive BU/BA. Most 3519 implementation today optimize on this, by eliminating the keepalives when there is traffic. We cant do such optimizations with BU/BA. 5. Lack of Reserved ports for allocation The comment was made, we can always extend DSMIP for supporting GRE or other encapsulation modes. Then the issue of backward compatibility came up. The tunnel end points cannot demux the encapsulated packets, when some packets are encapsulated with a thin header and some with out a thin header. So, the only alternative would be to allocate two ports numbers and the end points have to listen on both the port numbers. But, as Henrik mentioned, there is also an issue with the available reserved ports for standard network services. 6. Why do we need GRE Header ? We need GRE tunnel header for various reasons, when ever we carry multiple streams within a tunnel, the GRE header for its mature header semantics, the key field and the sequence number field is useful. We have some NEMO 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. Use cases: a.) Overlapping private IPv4 addressing support on the MAGs (PMIP6 Usage) b.) GRE tunnel header for NEMO usecase c.) Carrying other protocol packets (Lets say, IPX packets) in a MIP tunnel. d.) MIP4 supports it for a reason e.) Industry direction and related work, these are the active drafts: http://www.ietf.org/internet-drafts/draft-muhanna-netlmm-grekey-option-00.tx t http://www.ietf.org/internet-drafts/draft-yegani-gre-key-extension-02.txt http://www.ietf.org/internet-drafts/draft-tsirtsis-l2gre-pmipv4-00.txt _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 07 00:35: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 1Hw9j1-0002zq-Ns; Thu, 07 Jun 2007 00:35:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw9j0-0002ze-9o; Thu, 07 Jun 2007 00:35:54 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw9iy-0002Kl-QY; Thu, 07 Jun 2007 00:35:54 -0400 Received: from oaamta01sl.mx.bigpond.com ([124.191.178.123]) by omta01sl.mx.bigpond.com with ESMTP id <20070607043550.TAYZ14178.omta01sl.mx.bigpond.com@oaamta01sl.mx.bigpond.com>; Thu, 7 Jun 2007 04:35:50 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta01sl.mx.bigpond.com with ESMTP id <20070607043545.KGCE24660.oaamta01sl.mx.bigpond.com@PC20005>; Thu, 7 Jun 2007 04:35:45 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , "'Jari Arkko'" , "'Basavaraj Patil'" , "'Henrik Levkowetz'" Subject: RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus calltocloseissue 93 Date: Thu, 7 Jun 2007 14:35:38 +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: Aceog07TO1La/gT9RhyphyL26IwOawAGttwQAAMam6AAA88QsAAAjlBw In-Reply-To: <004f01c7a8bb$28b99470$1220fea9@amer.cisco.com> Message-Id: <20070607043545.KGCE24660.oaamta01sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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, This is a good start for discussion. In the spirit of listening, I'll address some of those comments. > 4. Tunnel Keep Alive message > > When DSMIP chose IPv4 UDP transport for NAT traversal, > the need for keepalive messaging between the tunnel > peers for keeping the NAT bindings came up. The authors > of the draft chose to use MIP6 signaling messages BU/BA > as a way to refresh the keepalive messages. IMO, having > a simple keepalive messages is lot more useful than an > expensive BU/BA. Most 3519 implementation today optimize > on this, by eliminating the keepalives when there is > traffic. We cant do such optimizations with BU/BA. => We discussed this already no? We said that you could encapsulate a ping in IP or use a dst option if you want to save bytes. So there are many ways of doing this, I don't see this as a Y2K equivalent. > 5. Lack of Reserved ports for allocation > > The comment was made, we can always extend DSMIP for supporting > GRE or other encapsulation modes. Then the issue of backward > compatibility came up. The tunnel end points cannot demux the > encapsulated packets, when some packets are encapsulated with > a thin header and some with out a thin header. So, the only > alternative would be to allocate two ports numbers and the end > points have to listen on both the port numbers. But, as Henrik > mentioned, there is also an issue with the available reserved > ports for standard network services. => I'd appreciate some pointers to this problem. About 18 months ago I asked for 6 ports and got them almost instantly. > > > 6. Why do we need GRE Header ? > > We need GRE tunnel header for various reasons, "when ever we > carry multiple streams within a tunnel, the GRE header for its > mature header semantics, the key field and the sequence number > field is useful." => I've added quotes around the area that I'm responding to above Are you seriously saying that whenever multiple flows are encapsulated in a packet GRE is needed? If you are then I think this is flat wrong, factually it's wrong. I hope you can either qualify that or change it or explain it better. I'll leave it with those comments for now to focus the discussion, I have other comments on the rest of the text but let's do it piecemeal. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 07 01:30: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 1HwAZj-00030U-MJ; Thu, 07 Jun 2007 01:30:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwAZh-00030D-P6; Thu, 07 Jun 2007 01:30:21 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwAZf-0000no-Bn; Thu, 07 Jun 2007 01:30:21 -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 l575UGY22149; Thu, 7 Jun 2007 05:30: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] issue 93 summary Date: Thu, 7 Jun 2007 00:30:13 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114C3A358@zrc2hxm2.corp.nortel.com> In-Reply-To: <20070607025414.RNUJ23012.oaamta07sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] issue 93 summary Thread-Index: Aceorx2gDxKnsRnRRCe92adTSLzcvAAELUjg References: <20070607025414.RNUJ23012.oaamta07sl.mx.bigpond.com@PC20005> From: "Ahmad Muhanna" To: "Hesham Soliman" , , 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 all, If I understand Jari comments correctly, I think at one point, he mentioned that we need to revisit/revaluate the existing text in the draft. I looked into the draft but the only thing that I found w.r.t option (1) is the following text: LOCATION NO. 1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2.3.2.1 Visited network supports IPv4 only (private addresses) In this scenario the mobile node will need to tunnel IPv6 packets containing the binding update to the home agent's IPv4 address. In order to traverse the NAT device, IPv6 packets are tunneled UDP and IPv4. The UDP port used to send the IPv6 packet is TBD. Basically there is no text included in the draft to explain how to identify the type of payload that is encapsulated in UDP. In other words and strictly speaking, if we take the draft most relevant text above, this "TBD" reserved UDP port will always indicate that the payload is an IPv6!=20 LOCATION NO. 2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Under section 8. IANA considerations: " 8. IANA considerations The specification requires the following allocations from IANA: - A UDP port is needed for the NAT traversal mechanism described in section 4.1. " Well, looking under section 4.1, I found the following sentence which suggest that an IPv4 packet may be encapsulated in UDP in IPv4. " ......... All tunneled IPv4 packets will contain the mobile node's IPv4 home address in the source address field of the inner IPv4 packet and the correspondent node's IPv4 address in the destination address field. The outer IPv4 header is the same whether the inner packet is IPv4 or IPv6. ..... " The least that I may say about the existing text, it is inadequate. IMO, it needs serious update to identify the mechanism needed by the receiving node to identify the type of packet that is encapsulated in UDP then in IPv4. Finally, I still favor option 3 considering that the 4 bytes can be compressed to much less than 4 bytes reducing the overhead on the wireless link. Regards, Ahmad =20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Wednesday, June 06, 2007 9:54 PM > To: mip6@ietf.org; nemo@ietf.org > Subject: [Mip6] issue 93 summary >=20 >=20 >=20 > In light of the discussions that went on I thought it would=20 > be useful to summarise the issue and discussions so far to=20 > give people who haven't kept up an insight into what this is=20 > all about.=20 >=20 > First the issue text discussed the need for a "TLV" type=20 > encoding between the outer IP header and the inner UDP=20 > header. The reason specified in the issue was that the upper=20 > layer parsing the packet can't tell what information follows=20 > UDP unless it is explicitly encoded. Upon further discussion=20 > it was clear that this rationale is not true because the=20 > upper layer can always parse the version field in the IP=20 > header following UDP.=20 >=20 > However, the following question was "what if the information=20 > following UDP was not an IP header?". One could encode=20 > messages (at least in theory) that follow UDP and that are=20 > not IP. But to save space and reading time, the main=20 > (probably only) example for such information is the use of=20 > GRE encapsulation. Some people don't see the need for the use=20 > of GRE and some people do. I suggested that GRE can be used=20 > before UDP and not after, but that was seen as unhelpful for=20 > cases where a NAT is present.=20 >=20 > Since I, after substantial effort, still couldn't find out=20 > what the deployment scenario that needs this might be, I=20 > won't try to invent a scenario for GRE on behalf of people=20 > who are calling for it and I'll leave the floor open for that=20 > discussion. The point I wanted to highlight here that=20 > practically this is the only reason left for adding TLV encoding.=20 >=20 > Finally, there are 3 options available for us to move forward=20 > and I'll use the same numbers that Raj use to avoid confusing people: >=20 > 1. Do nothing, keep the draft as is.=20 >=20 > 2. Specify a different port number for the different format suggested. >=20 > 3. Add the TLV encoding suggested in the issue.=20 >=20 >=20 > 1) above implies that should there be agreement in future=20 > that the format suggested in this issue is necessary, it can=20 > be achieved using option 2 (i.e. specify a new port that=20 > carries that format). This can be used if, for example, GRE=20 > is needed for NETLMM. A MAG can use a different port from the=20 > one used by the MN. The main reasons expressed by people for=20 > choosing 1 > were: > a) Adding 4 bytes on every packet is not needed.=20 > b) GRE is not needed.=20 >=20 > 2) above is pretty clear to everyone I think but Karen=20 > Nielsen raised some questions that people should read.=20 >=20 > 3) I believe 3 is also clear for everyone. Going to 3 will=20 > not require a move to 2) later. Of course this comes at the=20 > cost mentioned above. I believe the main reason expressed by=20 > people for this option was "future proof".=20 >=20 > So, hopefully this gives a summary of the discussion so far.=20 > I think there are basically two ways of finding concensus: > 1. Discuss the rationale a lot more to make either side move.=20 > For instance, discuss the deployment scenarios that require=20 > GRE, what is "future proof", why the extra 4 bytes are an=20 > issue for those who chose 1) ...etc 2. Due to current threads=20 > more people might express their opionions.=20 >=20 > I'm not too hopeful with 2) above because most of the people=20 > that are actively involved have commented. Plus it would=20 > actually be nice to see 1) being achieved once in a while! So=20 > let's try to do that.=20 >=20 > Hesham >=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 From mip6-bounces@ietf.org Thu Jun 07 03:03:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwC1c-0005ge-W6; Thu, 07 Jun 2007 03:03:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwC1a-0005gV-Qb; Thu, 07 Jun 2007 03:03:14 -0400 Received: from omta05ps.mx.bigpond.com ([144.140.83.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwC1Z-0005lj-CW; Thu, 07 Jun 2007 03:03:14 -0400 Received: from oaamta07ps.mx.bigpond.com ([124.191.178.123]) by omta05ps.mx.bigpond.com with ESMTP id <20070607070308.GDCN23363.omta05ps.mx.bigpond.com@oaamta07ps.mx.bigpond.com>; Thu, 7 Jun 2007 07:03:08 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta07ps.mx.bigpond.com with ESMTP id <20070607070308.UIFP5648.oaamta07ps.mx.bigpond.com@PC20005>; Thu, 7 Jun 2007 07:03:08 +0000 From: "Hesham Soliman" To: "'Ahmad Muhanna'" , , Subject: RE: [Mip6] issue 93 summary Date: Thu, 7 Jun 2007 17:03:01 +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 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437114C3A358@zrc2hxm2.corp.nortel.com> Thread-Index: Aceorx2gDxKnsRnRRCe92adTSLzcvAAELUjgAARjEMA= Message-Id: <20070607070308.UIFP5648.oaamta07ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 > If I understand Jari comments correctly, I think at one point, he > mentioned that we need to revisit/revaluate the existing text in the > draft. I looked into the draft but the only thing that I found w.r.t > option (1) is the following text: > > LOCATION NO. 1: > =============== > 2.3.2.1 Visited network supports IPv4 only (private addresses) > > In this scenario the mobile node will need to tunnel IPv6 packets > containing the binding update to the home agent's IPv4 address. In > order to traverse the NAT device, IPv6 packets are > tunneled UDP and > IPv4. The UDP port used to send the IPv6 packet is TBD. > > Basically there is no text included in the draft to explain how to > identify the type of payload that is encapsulated in UDP. In > other words > and strictly speaking, if we take the draft most relevant text above, > this "TBD" reserved UDP port will always indicate that the > payload is an > IPv6! => No that's not true at all. There is an IP version field in the IP header that tells you what the header is. The fact that the IP header fields (for v4 or v6) are not revisited in this draft does not in any shape or form suggest that we have no way of parsing header. I suggest that we get off the header parsing argument because frankly, it's a waste of time. Everyone knows (including people who want option 3) that you can do this with the version field. Let's not debate facts here, it's pointless. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 07 04:10: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 1HwD4v-0007JO-Sm; Thu, 07 Jun 2007 04:10:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwD4u-0007Iy-Ek; Thu, 07 Jun 2007 04:10:44 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwD4r-0004Fa-Fu; Thu, 07 Jun 2007 04:10:44 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 361C8204D6; Thu, 7 Jun 2007 10:10:40 +0200 (CEST) X-AuditID: c1b4fb3c-a8cebbb0000073d5-14-4667bd80207b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 17134204BE; Thu, 7 Jun 2007 10:10:40 +0200 (CEST) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 10:10:39 +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] issue 93 summary Date: Thu, 7 Jun 2007 10:10:38 +0200 Message-ID: In-Reply-To: <20070607025414.RNUJ23012.oaamta07sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] issue 93 summary Thread-Index: Aceorx2gDxKnsRnRRCe92adTSLzcvAAIjFBg References: <20070607025414.RNUJ23012.oaamta07sl.mx.bigpond.com@PC20005> From: "Karen E. Nielsen (AH/LMD)" To: "Hesham Soliman" , , X-OriginalArrivalTime: 07 Jun 2007 08:10:39.0713 (UTC) FILETIME=[55FA7510:01C7A8DB] X-Brightmail-Tracker: AAAAAA== 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 Hi Hesham, All For completeness it would be good to understand the implications vis-a-vis IPSec in the three options. I assume that we are speaking about UDP encapsulated ESP (3948) in option 1 and option 2, whether for payload and optionally also for BU/BACK. But what is the intended approach with option 3 ? Thanks, Karen > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: 7. juni 2007 04:54 > To: mip6@ietf.org; nemo@ietf.org > Subject: [Mip6] issue 93 summary >=20 >=20 >=20 > In light of the discussions that went on I thought it would=20 > be useful to summarise the issue and discussions so far to=20 > give people who haven't kept up an insight into what this is=20 > all about.=20 >=20 > First the issue text discussed the need for a "TLV" type=20 > encoding between the outer IP header and the inner UDP=20 > header. The reason specified in the issue was that the upper=20 > layer parsing the packet can't tell what information follows=20 > UDP unless it is explicitly encoded. Upon further discussion=20 > it was clear that this rationale is not true because the=20 > upper layer can always parse the version field in the IP=20 > header following UDP.=20 >=20 > However, the following question was "what if the information=20 > following UDP was not an IP header?". One could encode=20 > messages (at least in theory) that follow UDP and that are=20 > not IP. But to save space and reading time, the main=20 > (probably only) example for such information is the use of=20 > GRE encapsulation. Some people don't see the need for the use=20 > of GRE and some people do. I suggested that GRE can be used=20 > before UDP and not after, but that was seen as unhelpful for=20 > cases where a NAT is present.=20 >=20 > Since I, after substantial effort, still couldn't find out=20 > what the deployment scenario that needs this might be, I=20 > won't try to invent a scenario for GRE on behalf of people=20 > who are calling for it and I'll leave the floor open for that=20 > discussion. The point I wanted to highlight here that=20 > practically this is the only reason left for adding TLV encoding.=20 >=20 > Finally, there are 3 options available for us to move forward=20 > and I'll use the same numbers that Raj use to avoid confusing people: >=20 > 1. Do nothing, keep the draft as is.=20 >=20 > 2. Specify a different port number for the different format suggested. >=20 > 3. Add the TLV encoding suggested in the issue.=20 >=20 >=20 > 1) above implies that should there be agreement in future=20 > that the format suggested in this issue is necessary, it can=20 > be achieved using option 2 (i.e. specify a new port that=20 > carries that format). This can be used if, for example, GRE=20 > is needed for NETLMM. A MAG can use a different port from the=20 > one used by the MN. The main reasons expressed by people for=20 > choosing 1 > were: > a) Adding 4 bytes on every packet is not needed.=20 > b) GRE is not needed.=20 >=20 > 2) above is pretty clear to everyone I think but Karen=20 > Nielsen raised some questions that people should read.=20 >=20 > 3) I believe 3 is also clear for everyone. Going to 3 will=20 > not require a move to 2) later. Of course this comes at the=20 > cost mentioned above. I believe the main reason expressed by=20 > people for this option was "future proof".=20 >=20 > So, hopefully this gives a summary of the discussion so far.=20 > I think there are basically two ways of finding concensus: > 1. Discuss the rationale a lot more to make either side move.=20 > For instance, discuss the deployment scenarios that require=20 > GRE, what is "future proof", why the extra 4 bytes are an=20 > issue for those who chose 1) ...etc 2. Due to current threads=20 > more people might express their opionions.=20 >=20 > I'm not too hopeful with 2) above because most of the people=20 > that are actively involved have commented. Plus it would=20 > actually be nice to see 1) being achieved once in a while! So=20 > let's try to do that.=20 >=20 > Hesham >=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 From mip6-bounces@ietf.org Thu Jun 07 04:33: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 1HwDQo-00063z-5H; Thu, 07 Jun 2007 04:33:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwDQm-00063X-HX; Thu, 07 Jun 2007 04:33:20 -0400 Received: from omta03ps.mx.bigpond.com ([144.140.82.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwDQj-0006r5-N7; Thu, 07 Jun 2007 04:33:20 -0400 Received: from oaamta03ps.mx.bigpond.com ([124.191.178.123]) by omta03ps.mx.bigpond.com with ESMTP id <20070607083314.VYQJ8709.omta03ps.mx.bigpond.com@oaamta03ps.mx.bigpond.com>; Thu, 7 Jun 2007 08:33:14 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta03ps.mx.bigpond.com with ESMTP id <20070607083314.UIHJ22348.oaamta03ps.mx.bigpond.com@PC20005>; Thu, 7 Jun 2007 08:33:14 +0000 From: "Hesham Soliman" To: "'Karen E. Nielsen \(AH/LMD\)'" , , Subject: RE: [Mip6] issue 93 summary Date: Thu, 7 Jun 2007 18:33: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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Aceorx2gDxKnsRnRRCe92adTSLzcvAAIjFBgAAM2IUA= Message-Id: <20070607083314.UIHJ22348.oaamta03ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 Karen, Good question. I don't know actually. Transport ESP on the outer header is obviously not a good idea. Transport ESP on the inner header is obviously possible. It doesn't seem like UDP encapsulated ESP as per 3948 is possible. Anyone else has a comment on this? Hesham > -----Original Message----- > From: Karen E. Nielsen (AH/LMD) > [mailto:karen.e.nielsen@ericsson.com] > Sent: Thursday, June 07, 2007 6:11 PM > To: Hesham Soliman; mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] issue 93 summary > > Hi Hesham, All > > For completeness it would be good to understand the implications > vis-a-vis IPSec in the three options. > > I assume that we are speaking about UDP encapsulated ESP (3948) in > option 1 and option 2, > whether for payload and optionally also for BU/BACK. > But what is the intended approach with option 3 ? > > Thanks, > Karen > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: 7. juni 2007 04:54 > > To: mip6@ietf.org; nemo@ietf.org > > Subject: [Mip6] issue 93 summary > > > > > > > > In light of the discussions that went on I thought it would > > be useful to summarise the issue and discussions so far to > > give people who haven't kept up an insight into what this is > > all about. > > > > First the issue text discussed the need for a "TLV" type > > encoding between the outer IP header and the inner UDP > > header. The reason specified in the issue was that the upper > > layer parsing the packet can't tell what information follows > > UDP unless it is explicitly encoded. Upon further discussion > > it was clear that this rationale is not true because the > > upper layer can always parse the version field in the IP > > header following UDP. > > > > However, the following question was "what if the information > > following UDP was not an IP header?". One could encode > > messages (at least in theory) that follow UDP and that are > > not IP. But to save space and reading time, the main > > (probably only) example for such information is the use of > > GRE encapsulation. Some people don't see the need for the use > > of GRE and some people do. I suggested that GRE can be used > > before UDP and not after, but that was seen as unhelpful for > > cases where a NAT is present. > > > > Since I, after substantial effort, still couldn't find out > > what the deployment scenario that needs this might be, I > > won't try to invent a scenario for GRE on behalf of people > > who are calling for it and I'll leave the floor open for that > > discussion. The point I wanted to highlight here that > > practically this is the only reason left for adding TLV encoding. > > > > Finally, there are 3 options available for us to move forward > > and I'll use the same numbers that Raj use to avoid > confusing people: > > > > 1. Do nothing, keep the draft as is. > > > > 2. Specify a different port number for the different > format suggested. > > > > 3. Add the TLV encoding suggested in the issue. > > > > > > 1) above implies that should there be agreement in future > > that the format suggested in this issue is necessary, it can > > be achieved using option 2 (i.e. specify a new port that > > carries that format). This can be used if, for example, GRE > > is needed for NETLMM. A MAG can use a different port from the > > one used by the MN. The main reasons expressed by people for > > choosing 1 > > were: > > a) Adding 4 bytes on every packet is not needed. > > b) GRE is not needed. > > > > 2) above is pretty clear to everyone I think but Karen > > Nielsen raised some questions that people should read. > > > > 3) I believe 3 is also clear for everyone. Going to 3 will > > not require a move to 2) later. Of course this comes at the > > cost mentioned above. I believe the main reason expressed by > > people for this option was "future proof". > > > > So, hopefully this gives a summary of the discussion so far. > > I think there are basically two ways of finding concensus: > > 1. Discuss the rationale a lot more to make either side move. > > For instance, discuss the deployment scenarios that require > > GRE, what is "future proof", why the extra 4 bytes are an > > issue for those who chose 1) ...etc 2. Due to current threads > > more people might express their opionions. > > > > I'm not too hopeful with 2) above because most of the people > > that are actively involved have commented. Plus it would > > actually be nice to see 1) being achieved once in a while! So > > let's try to do that. > > > > Hesham > > > > > > > > _______________________________________________ > > 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 Jun 07 05:11: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 1HwE1p-0006vd-2G; Thu, 07 Jun 2007 05:11:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwE1n-0006vT-Jp for mip6@ietf.org; Thu, 07 Jun 2007 05:11:35 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwE1n-0004Ne-5I for mip6@ietf.org; Thu, 07 Jun 2007 05:11:35 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1181207494!6930943!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19106 invoked from network); 7 Jun 2007 09:11:34 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 7 Jun 2007 09:11: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 l579BSj7016966; Thu, 7 Jun 2007 02:11:28 -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 l579BS3P027133; Thu, 7 Jun 2007 04:11:28 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l579BQM5027062; Thu, 7 Jun 2007 04:11:26 -0500 (CDT) Message-ID: <4667CBB8.7050408@gmail.com> Date: Thu, 07 Jun 2007 11:11:20 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] question on DS-MIPv6 security References: <20070601120608.LFMN7523.oaamta05sl.mx.bigpond.com@PC20005> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000747-3, 06/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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 Vijay Devarapalli wrote: > Karen, > > RFC 4877 allows the use of ESP both in transport and tunnel mode > protecting the Binding Update. The packet formats are already listed > in 4877. > > The DS-MIPv6 spec shows the introduction of UDP header but only shows > the use of ESP transport mode. ESP tunnel mode with UDP header is > also possible. It is not however shown explicitly in the DS-MIPv6 > specification. Vijay I don't see in DS-MIPv6 spec any picture with ESP, IPv6 and UDPv4 headers - what do you mean? (I see pictures with IPv6, IPv4 and UDP headers, but not ESP). draft-ietf-mip6-nemo-v4traversal-04.txt RFC4877 "Mobile IPv6 with IKEv2 and IPsec" is only about IPv6 and IPv6-in-IPv6, not IPv4; as I read it. Alex > > Vijay > >> -----Original Message----- From: Karen E. Nielsen (AH/LMD) >> [mailto:karen.e.nielsen@ericsson.com] Sent: Friday, June 01, 2007 >> 6:03 AM To: Hesham Soliman; mip6@ietf.org Subject: RE: [Mip6] >> question on DS-MIPv6 security >> >> Hi, >> >> No, to keep it in IP/IPSec kernel space I guess the options, as you >> have discussed on the list, is specific UDP port for IP-UDP-IP or >> ESP UDP encapsulation and the option 2 tunnel BU format. >> >> I do not want to attempt to reopen this discussion. I have a better >> idea about where the spec is now. Thanks. >> >> Karen >> >> >> >> >> ________________________________ >> >> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] Sent: 1. >> juni 2007 14:06 To: Karen E. Nielsen (AH/LMD); mip6@ietf.org >> Subject: RE: [Mip6] question on DS-MIPv6 security Ah, sure, >> that's a problem if you do implement this in user space. What can I >> say, let's hope NATs disappear! Not much else we can do about >> this. Hesham >> >> >> ________________________________ >> >> From: Karen E. Nielsen (AH/LMD) >> [mailto:karen.e.nielsen@ericsson.com] Sent: Friday, June 01, 2007 >> 10:00 PM To: Hesham Soliman; mip6@ietf.org Subject: RE: [Mip6] >> question on DS-MIPv6 security Hi, The problem, I see, is the >> looping from higher transport layer, UDP, back to IP/IPSec >> processing. With ESP UDP encapsulation the processing of the full >> header IP-UDP-IP-IPSEC is kept in the IP/IPSec layer. BR, Karen >> >> >> ________________________________ >> >> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] Sent: 1. >> juni 2007 13:39 To: Karen E. Nielsen (AH/LMD); mip6@ietf.org >> Subject: RE: [Mip6] question on DS-MIPv6 security Karen, Please >> ignore option 2 below, we're not doing this in the draft. This was >> part of a concensus call and we're leaving the draft as is today as >> a result of this call. >> >> >> Secondly, looking into the destination option/routing header >> versions of the BU as described in Section 4.1 of DS-MIP, then >> these are described without security >> >> headers, although they in Section 5 of DS-MIP are said to be >> protected using IPSec (as in standard [MIP] modulo RFC 4285). In >> this respect, >> >> I am rather concerned with the processing of the stack: IPv4 header >> (src=V4ADDR, dst=HA_V4ADDR) UDP header IPv6 header (src=V4CoA, >> dst=HAADDR) DST-OPT HAO (IPv6 home address) ESP (transport) >> Mobility header BU [IPv4 HAO] >> >> as the appearance of ESP after a transport header will require a >> not very nice processing flow in the stack, unless IPSec is made to >> understand >> >> "IP" headers of form IP-UDP-IP - Has this been discussed or is it >> not perceived as a problem by other implementators ? >> >> => I'm not sure I understand the problem you're seeing above. By >> the time IPsec gets this packet there would not be IPv4/UDP headers >> and it would look like a normal IPsec protected IPv6 packet. >> >> Hesham >> >> > > _______________________________________________ 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 Jun 07 05:49: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 1HwEc8-0001ZQ-8S; Thu, 07 Jun 2007 05:49:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwEc5-0001Z5-Ol; Thu, 07 Jun 2007 05:49:06 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwEc4-000387-H0; Thu, 07 Jun 2007 05:49:05 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1181209743!17594856!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 15992 invoked from network); 7 Jun 2007 09:49:03 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-8.tower-119.messagelabs.com with SMTP; 7 Jun 2007 09:49:03 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l579msVD023620; Thu, 7 Jun 2007 02:48:59 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l579msx2014558; Thu, 7 Jun 2007 04:48:54 -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 l579mpG2014493; Thu, 7 Jun 2007 04:48:52 -0500 (CDT) Message-ID: <4667D47D.7060909@gmail.com> Date: Thu, 07 Jun 2007 11:48:45 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] issue 93 summary References: <20070607083314.UIHJ22348.oaamta03ps.mx.bigpond.com@PC20005> In-Reply-To: <20070607083314.UIHJ22348.oaamta03ps.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000747-3, 06/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 Hesham Soliman wrote: > Hi Karen, > > Good question. I don't know actually. Transport ESP on the outer header is > obviously not a good idea. Transport ESP on the inner header is obviously > possible. It doesn't seem like UDP encapsulated ESP as per 3948 is possible. > Anyone else has a comment on this? YEs. I don't think implementations of DS-MIPv6 do what rfc3948 says when encapsulating IPv6 in UDPv4 with ESP. The rfc3948 operations are mainly about re-computing checksums in UDP header. Doesn't mean it should be ignored. I think the differences between RFC3948 (UDP-ESP) and DS-MIPv6 use of ESP lie in the style of approach of using ESP. It's not only the typical tunnel vs transport mode. It is about which style of ESP? IPv4-style or IPv6-style ESP? The ESP as usually used by UDP in IPv4 (ESP is after the UDP header, RFC3948)? Or the ESP as used by the inner typical IPv6 packet (IPv6baseheader-ESPheader-MobilityHEader). The exact placing of the ESP header (with respect to UDP and IPv6 headers) obviously has an impact of the level of protection afforded. I believe for maximum protection there may be two ESP headers. I think what DS-MIPv6 assumes is this: IPv4-header UDP IPv6-baseheader ESP IPv6-MobilityHeader I think what RFC3948 suggests is this: IPv4-header IPv4-header UDP or UDP ESP ESP IPv6-MobilityHeader IPv6-baseheader IPv6-MobilityHeader Two ESP headers - one IPv4 style and the other IPv6 style - would look like this: IPv4-header UDP ESP IPv6-baseheader ESP IPv6-MobilityHeader But that has two ESP headers and UDP is still exposed. So better would be: IPv4-header ESP IPv4-header UDP ESP IPv6-header But that doesn't traverse NATs because UDP is not seen by NAT :-( (I think this was already discussed recently). Maybe a shorter-packet alternative is this: IPv4-header UDP ESP IPv6-MobilityHeader. I think in practice the implementer will prefer to either use IPsec code from that s/he usually uses for IPv4 or for IPv6. But packets surely look different. 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 Jun 07 06:09: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 1HwEw0-0000EQ-Op; Thu, 07 Jun 2007 06:09:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwEvy-0000EG-V5; Thu, 07 Jun 2007 06:09:38 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwEvy-0007oX-Jn; Thu, 07 Jun 2007 06:09:38 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1181210977!1314935!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 10139 invoked from network); 7 Jun 2007 10:09:37 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-128.messagelabs.com with SMTP; 7 Jun 2007 10:09:37 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l57A9OUM002317; Thu, 7 Jun 2007 03:09:28 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l57A9N6f021308; Thu, 7 Jun 2007 05:09:23 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l57A9JxQ021225; Thu, 7 Jun 2007 05:09:20 -0500 (CDT) Message-ID: <4667D94A.5050806@gmail.com> Date: Thu, 07 Jun 2007 12:09:14 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: GRE, L2TP and no intermediary header (was: [nemo] RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus calltocloseissue 93) References: <20070607043545.KGCE24660.oaamta01sl.mx.bigpond.com@PC20005> In-Reply-To: <20070607043545.KGCE24660.oaamta01sl.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000747-3, 06/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: nemo@ietf.org, 'Sri Gundavelli' , 'Mobile IPv6 Mailing List' , 'Henrik Levkowetz' 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: [...] >> 5. Lack of Reserved ports for allocation >> >> The comment was made, we can always extend DSMIP for supporting GRE >> or other encapsulation modes. Then the issue of backward >> compatibility came up. The tunnel end points cannot demux the >> encapsulated packets, when some packets are encapsulated with a >> thin header and some with out a thin header. So, the only >> alternative would be to allocate two ports numbers and the end >> points have to listen on both the port numbers. But, as Henrik >> mentioned, there is also an issue with the available reserved ports >> for standard network services. > > => I'd appreciate some pointers to this problem. About 18 months ago > I asked for 6 ports and got them almost instantly. >> >> 6. Why do we need GRE Header ? >> >> We need GRE tunnel header for various reasons, "when ever we carry >> multiple streams within a tunnel, the GRE header for its mature >> header semantics, the key field and the sequence number field is >> useful." > > => I've added quotes around the area that I'm responding to above Are > you seriously saying that whenever multiple flows are encapsulated in > a packet GRE is needed? If you are then I think this is flat wrong, > factually it's wrong. I hope you can either qualify that or change it > or explain it better. Another comment that was made is that _if_ the problem is to transport link-layer messages (something else than IP) over IP then GRE is not the only solution - L2TP does approximately that too; if I understand the comment correctly. Thus _if_ we know the problem then we still have to choose between several solutions (muxing based on other things than the intermediary tagging header, GRE and L2TP). But I'm not sure I understand very well the problem in the first place. 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 Jun 07 06:11: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 1HwExY-0001Pe-9i; Thu, 07 Jun 2007 06:11:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwExX-0001PW-Rb; Thu, 07 Jun 2007 06:11:15 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwExX-00082v-5L; Thu, 07 Jun 2007 06:11:15 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5958A2057C; Thu, 7 Jun 2007 12:11:14 +0200 (CEST) X-AuditID: c1b4fb3c-aacefbb0000073d5-d3-4667d9c27a07 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 38FD820496; Thu, 7 Jun 2007 12:11:14 +0200 (CEST) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 12:11:13 +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] issue 93 summary Date: Thu, 7 Jun 2007 12:11:13 +0200 Message-ID: In-Reply-To: <4667D47D.7060909@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] issue 93 summary Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+g References: <20070607083314.UIHJ22348.oaamta03ps.mx.bigpond.com@PC20005> <4667D47D.7060909@gmail.com> From: "Karen E. Nielsen (AH/LMD)" To: "Alexandru Petrescu" , "Hesham Soliman" X-OriginalArrivalTime: 07 Jun 2007 10:11:13.0605 (UTC) FILETIME=[2DB6C750:01C7A8EC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 Hi, I agree that DS-MIP model for BU ESP protection is:=20 > IPv4-header > UDP > IPv6-baseheader > ESP > IPv6-MobilityHeader But what about ESP tunnel payload protection (and optional way of BU protection - read: Section 3 of 4877). Here it could be appropriate to use UDP ESP 3948 to obtain IPv4-header UDP ESP =20 IPv6/4-header Payload/BU but, then the question for me is - is that also the intention in case of option 3 - or is a different way of ESP tunnel envisaged here. Karen > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: 7. juni 2007 11:49 > To: Hesham Soliman > Cc: Karen E. Nielsen (AH/LMD); mip6@ietf.org; nemo@ietf.org > Subject: Re: [Mip6] issue 93 summary >=20 > Hesham Soliman wrote: > > Hi Karen, > >=20 > > Good question. I don't know actually. Transport ESP on the outer=20 > > header is obviously not a good idea. Transport ESP on the=20 > inner header=20 > > is obviously possible. It doesn't seem like UDP=20 > encapsulated ESP as per 3948 is possible. > > Anyone else has a comment on this? >=20 > YEs. >=20 > I don't think implementations of DS-MIPv6 do what rfc3948=20 > says when encapsulating IPv6 in UDPv4 with ESP. The rfc3948=20 > operations are mainly about re-computing checksums in UDP=20 > header. Doesn't mean it should be ignored. >=20 > I think the differences between RFC3948 (UDP-ESP) and=20 > DS-MIPv6 use of ESP lie in the style of approach of using=20 > ESP. It's not only the typical tunnel vs transport mode. >=20 > It is about which style of ESP? IPv4-style or IPv6-style=20 > ESP? The ESP as usually used by UDP in IPv4 (ESP is after=20 > the UDP header, RFC3948)?=20 > Or the ESP as used by the inner typical IPv6 packet=20 > (IPv6baseheader-ESPheader-MobilityHEader). >=20 > The exact placing of the ESP header (with respect to UDP and IPv6 > headers) obviously has an impact of the level of protection=20 > afforded. I believe for maximum protection there may be two=20 > ESP headers. >=20 > I think what DS-MIPv6 assumes is this: >=20 > IPv4-header > UDP > IPv6-baseheader > ESP > IPv6-MobilityHeader >=20 > I think what RFC3948 suggests is this: >=20 > IPv4-header IPv4-header > UDP or UDP > ESP ESP > IPv6-MobilityHeader IPv6-baseheader > IPv6-MobilityHeader >=20 > Two ESP headers - one IPv4 style and the other IPv6 style -=20 > would look like this: >=20 > IPv4-header > UDP > ESP > IPv6-baseheader > ESP > IPv6-MobilityHeader >=20 > But that has two ESP headers and UDP is still exposed. So=20 > better would be: >=20 > IPv4-header > ESP > IPv4-header > UDP > ESP > IPv6-header >=20 > But that doesn't traverse NATs because UDP is not seen by=20 > NAT :-( (I think this was already discussed recently). >=20 > Maybe a shorter-packet alternative is this: >=20 > IPv4-header > UDP > ESP > IPv6-MobilityHeader. >=20 > I think in practice the implementer will prefer to either use=20 > IPsec code from that s/he usually uses for IPv4 or for IPv6. =20 > But packets surely look different. >=20 > Alex >=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 Jun 07 06:26: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 1HwFCX-0003HX-CW; Thu, 07 Jun 2007 06:26:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwFCV-0003HK-Nv; Thu, 07 Jun 2007 06:26:43 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwFCU-0004NC-CJ; Thu, 07 Jun 2007 06:26:43 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1181212001!12285776!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9257 invoked from network); 7 Jun 2007 10:26:41 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-128.messagelabs.com with SMTP; 7 Jun 2007 10:26:41 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l57AQaZr006008; Thu, 7 Jun 2007 03:26:36 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l57AQaFr013782; Thu, 7 Jun 2007 05:26:36 -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 l57AQYUC013727; Thu, 7 Jun 2007 05:26:35 -0500 (CDT) Message-ID: <4667DD55.10300@gmail.com> Date: Thu, 07 Jun 2007 12:26:29 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Karen E. Nielsen (AH/LMD)" Subject: Re: [Mip6] issue 93 summary References: <20070607083314.UIHJ22348.oaamta03ps.mx.bigpond.com@PC20005> <4667D47D.7060909@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000747-3, 06/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Karen E. Nielsen (AH/LMD) wrote: > Hi, > > I agree that DS-MIP model for BU ESP protection is: > >> IPv4-header >> UDP >> IPv6-baseheader >> ESP >> IPv6-MobilityHeader > > But what about ESP tunnel payload protection (and optional way of BU > protection - read: Section 3 of 4877). Here it could be appropriate > to use UDP ESP 3948 to obtain > > IPv4-header > UDP > ESP > IPv6/4-header > Payload/BU Looks meaningful to me (just don't call MobilityHeader 'payload' :-) > but, then the question for me is - is that also the intention in case > of option 3 - or is a different way of ESP tunnel envisaged here. It's a question. I show the Chair's call below. I don't know what Raj means by a DS-MIP6 'tunnel type message'. Is that an intermediary header between UDP and ESP (in the figure above)? Is that intermediary header a MobileIPv4-header? Is that the rfc3012 Generalized MIP Auth Extension replacing ESP? Is that GRE? I think your figure above looks good. Alex Raj originally posted 'issue 93 summary': [...] > 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 ______________________________________________________________________ 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 Jun 07 08:02: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 1HwGgk-00054x-UN; Thu, 07 Jun 2007 08:02:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwGgi-00053x-KJ; Thu, 07 Jun 2007 08:02:00 -0400 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwGgh-0008Md-3p; Thu, 07 Jun 2007 08:02:00 -0400 Received: from oaamta06ps.mx.bigpond.com ([124.191.178.123]) by omta01ps.mx.bigpond.com with ESMTP id <20070607120155.ZNSL19666.omta01ps.mx.bigpond.com@oaamta06ps.mx.bigpond.com>; Thu, 7 Jun 2007 12:01:55 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta06ps.mx.bigpond.com with ESMTP id <20070607120155.XAZS6690.oaamta06ps.mx.bigpond.com@PC20005>; Thu, 7 Jun 2007 12:01:55 +0000 From: "Hesham Soliman" To: "'Karen E. Nielsen \(AH/LMD\)'" , "'Alexandru Petrescu'" Subject: RE: [Mip6] issue 93 summary Date: Thu, 7 Jun 2007 22:01:48 +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 In-Reply-To: Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqA= Message-Id: <20070607120155.XAZS6690.oaamta06ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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 > I agree that DS-MIP model for BU ESP protection is: => Perhaps the draft needs clarification because there is no reason why this should be the only model. > > > IPv4-header > > UDP > > IPv6-baseheader > > ESP > > IPv6-MobilityHeader > > But what about ESP tunnel payload protection (and optional way of BU > protection - read: Section 3 of 4877). > Here it could be appropriate to use UDP ESP 3948 to obtain > > IPv4-header > UDP > ESP > IPv6/4-header > Payload/BU > => Right, which we do support today. > but, then the question for me is - is that also the > intention in case of > option 3 - or > is a different way of ESP tunnel envisaged here. => That's how I understood your original question, it's not a general question, it's specific to the option 3 case. Unless I'm missing something I don't think the latter format (3948) would work in this case due to the additional TLV. Hesham > > Karen > > > -----Original Message----- > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > Sent: 7. juni 2007 11:49 > > To: Hesham Soliman > > Cc: Karen E. Nielsen (AH/LMD); mip6@ietf.org; nemo@ietf.org > > Subject: Re: [Mip6] issue 93 summary > > > > Hesham Soliman wrote: > > > Hi Karen, > > > > > > Good question. I don't know actually. Transport ESP on the outer > > > header is obviously not a good idea. Transport ESP on the > > inner header > > > is obviously possible. It doesn't seem like UDP > > encapsulated ESP as per 3948 is possible. > > > Anyone else has a comment on this? > > > > YEs. > > > > I don't think implementations of DS-MIPv6 do what rfc3948 > > says when encapsulating IPv6 in UDPv4 with ESP. The rfc3948 > > operations are mainly about re-computing checksums in UDP > > header. Doesn't mean it should be ignored. > > > > I think the differences between RFC3948 (UDP-ESP) and > > DS-MIPv6 use of ESP lie in the style of approach of using > > ESP. It's not only the typical tunnel vs transport mode. > > > > It is about which style of ESP? IPv4-style or IPv6-style > > ESP? The ESP as usually used by UDP in IPv4 (ESP is after > > the UDP header, RFC3948)? > > Or the ESP as used by the inner typical IPv6 packet > > (IPv6baseheader-ESPheader-MobilityHEader). > > > > The exact placing of the ESP header (with respect to UDP and IPv6 > > headers) obviously has an impact of the level of protection > > afforded. I believe for maximum protection there may be two > > ESP headers. > > > > I think what DS-MIPv6 assumes is this: > > > > IPv4-header > > UDP > > IPv6-baseheader > > ESP > > IPv6-MobilityHeader > > > > I think what RFC3948 suggests is this: > > > > IPv4-header IPv4-header > > UDP or UDP > > ESP ESP > > IPv6-MobilityHeader IPv6-baseheader > > IPv6-MobilityHeader > > > > Two ESP headers - one IPv4 style and the other IPv6 style - > > would look like this: > > > > IPv4-header > > UDP > > ESP > > IPv6-baseheader > > ESP > > IPv6-MobilityHeader > > > > But that has two ESP headers and UDP is still exposed. So > > better would be: > > > > IPv4-header > > ESP > > IPv4-header > > UDP > > ESP > > IPv6-header > > > > But that doesn't traverse NATs because UDP is not seen by > > NAT :-( (I think this was already discussed recently). > > > > Maybe a shorter-packet alternative is this: > > > > IPv4-header > > UDP > > ESP > > IPv6-MobilityHeader. > > > > I think in practice the implementer will prefer to either use > > IPsec code from that s/he usually uses for IPv4 or for IPv6. > > But packets surely look different. > > > > 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 Jun 07 08:24:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwH2k-0000hX-64; Thu, 07 Jun 2007 08:24:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwH1l-0008Ne-Fd; Thu, 07 Jun 2007 08:23:45 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwH0V-0004cp-Ea; Thu, 07 Jun 2007 08:22:28 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-153.messagelabs.com!1181218946!1064795!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 4539 invoked from network); 7 Jun 2007 12:22:26 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-153.messagelabs.com with SMTP; 7 Jun 2007 12:22:26 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l57CMP3s003942; Thu, 7 Jun 2007 05:22:25 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l57CMO2D024839; Thu, 7 Jun 2007 07:22:24 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l57CMMje024760; Thu, 7 Jun 2007 07:22:22 -0500 (CDT) Message-ID: <4667F876.9030109@gmail.com> Date: Thu, 07 Jun 2007 14:22:14 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] issue 93 summary References: <20070607120155.XAZS6690.oaamta06ps.mx.bigpond.com@PC20005> In-Reply-To: <20070607120155.XAZS6690.oaamta06ps.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000747-3, 06/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f 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 Hesham Soliman wrote: > > > I agree that DS-MIP model for BU ESP protection is: > > => Perhaps the draft needs clarification because there is no reason why this > should be the only model. > > > > > > IPv4-header > > > UDP > > > IPv6-baseheader > > > ESP > > > IPv6-MobilityHeader > > > > But what about ESP tunnel payload protection (and optional way of BU > > protection - read: Section 3 of 4877). > > Here it could be appropriate to use UDP ESP 3948 to obtain > > > > IPv4-header > > UDP > > ESP > > IPv6/4-header > > Payload/BU > > > > => Right, which we do support today. > > > but, then the question for me is - is that also the > > intention in case of > > option 3 - or > > is a different way of ESP tunnel envisaged here. > > => That's how I understood your original question, it's not a general > question, it's specific to the option 3 case. Unless I'm missing something I > don't think the latter format (3948) would work in this case due to the > additional TLV. I don't think either. If the additional TLV is after ESP then we the existing ESP spec may not say how to calculate ESP fields across that TLV: IPv4-header UDP ESP TLV-tunneltypemessage IPv6-baseheader IPv6-MobilityHeader If the additional TLV is before the ESP then it is obviously insecure: IPv4-header UDP TLV-tunneltypemessage ESP IPv6-baseheader IPv6-MobilityHeader Alex > > Hesham > > > > > Karen > > > > > -----Original Message----- > > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > > Sent: 7. juni 2007 11:49 > > > To: Hesham Soliman > > > Cc: Karen E. Nielsen (AH/LMD); mip6@ietf.org; nemo@ietf.org > > > Subject: Re: [Mip6] issue 93 summary > > > > > > Hesham Soliman wrote: > > > > Hi Karen, > > > > > > > > Good question. I don't know actually. Transport ESP on the outer > > > > header is obviously not a good idea. Transport ESP on the > > > inner header > > > > is obviously possible. It doesn't seem like UDP > > > encapsulated ESP as per 3948 is possible. > > > > Anyone else has a comment on this? > > > > > > YEs. > > > > > > I don't think implementations of DS-MIPv6 do what rfc3948 > > > says when encapsulating IPv6 in UDPv4 with ESP. The rfc3948 > > > operations are mainly about re-computing checksums in UDP > > > header. Doesn't mean it should be ignored. > > > > > > I think the differences between RFC3948 (UDP-ESP) and > > > DS-MIPv6 use of ESP lie in the style of approach of using > > > ESP. It's not only the typical tunnel vs transport mode. > > > > > > It is about which style of ESP? IPv4-style or IPv6-style > > > ESP? The ESP as usually used by UDP in IPv4 (ESP is after > > > the UDP header, RFC3948)? > > > Or the ESP as used by the inner typical IPv6 packet > > > (IPv6baseheader-ESPheader-MobilityHEader). > > > > > > The exact placing of the ESP header (with respect to UDP and IPv6 > > > headers) obviously has an impact of the level of protection > > > afforded. I believe for maximum protection there may be two > > > ESP headers. > > > > > > I think what DS-MIPv6 assumes is this: > > > > > > IPv4-header > > > UDP > > > IPv6-baseheader > > > ESP > > > IPv6-MobilityHeader > > > > > > I think what RFC3948 suggests is this: > > > > > > IPv4-header IPv4-header > > > UDP or UDP > > > ESP ESP > > > IPv6-MobilityHeader IPv6-baseheader > > > IPv6-MobilityHeader > > > > > > Two ESP headers - one IPv4 style and the other IPv6 style - > > > would look like this: > > > > > > IPv4-header > > > UDP > > > ESP > > > IPv6-baseheader > > > ESP > > > IPv6-MobilityHeader > > > > > > But that has two ESP headers and UDP is still exposed. So > > > better would be: > > > > > > IPv4-header > > > ESP > > > IPv4-header > > > UDP > > > ESP > > > IPv6-header > > > > > > But that doesn't traverse NATs because UDP is not seen by > > > NAT :-( (I think this was already discussed recently). > > > > > > Maybe a shorter-packet alternative is this: > > > > > > IPv4-header > > > UDP > > > ESP > > > IPv6-MobilityHeader. > > > > > > I think in practice the implementer will prefer to either use > > > IPsec code from that s/he usually uses for IPv4 or for IPv6. > > > But packets surely look different. > > > > > > 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 Jun 07 10:59: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 1HwJST-0003ie-SR; Thu, 07 Jun 2007 10:59:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJSR-0003iO-VY; Thu, 07 Jun 2007 10:59:27 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwJSP-0005vH-EH; Thu, 07 Jun 2007 10:59:27 -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] issue 93 summary Date: Thu, 7 Jun 2007 07:59:23 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] issue 93 summary thread-index: Aceo/tmNS8cVk6UjSGeFqBKAzz3nIAAFSW4g References: <20070607120155.XAZS6690.oaamta06ps.mx.bigpond.com@PC20005> <4667F876.9030109@gmail.com> From: "Vijay Devarapalli" To: "Alexandru Petrescu" , "Hesham Soliman" , "Karen E. Nielsen \(AH/LMD\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 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 This discussion is creating confusion. Obviously if we have the TLV that comes after the UDP header, we are not really using RFC 3948 (UDP encapsulation for ESP). It would still work fine. The port number in UDP header would not point to ESP. It would point this new TLV (MIP tunnel data message header). The TLV's port/protocol field will then point to ESP.=20 There is *no* problem in encryption or calculating the MAC in the ESP header. It would work fine with the TLV header. =20 Vijay=20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Thursday, June 07, 2007 5:22 AM > To: Hesham Soliman > Cc: nemo@ietf.org; mip6@ietf.org > Subject: Re: [Mip6] issue 93 summary >=20 > Hesham Soliman wrote: > >=20 > > > I agree that DS-MIP model for BU ESP protection is:=20 > >=20 > > =3D> Perhaps the draft needs clarification because there is=20 > no reason why this > > should be the only model. > >=20 > > >=20 > > > > IPv4-header > > > > UDP > > > > IPv6-baseheader > > > > ESP > > > > IPv6-MobilityHeader > > >=20 > > > But what about ESP tunnel payload protection (and=20 > optional way of BU > > > protection - read: Section 3 of 4877). > > > Here it could be appropriate to use UDP ESP 3948 to obtain > > >=20 > > > IPv4-header > > > UDP > > > ESP =20 > > > IPv6/4-header > > > Payload/BU > > >=20 > >=20 > > =3D> Right, which we do support today. > >=20 > > > but, then the question for me is - is that also the=20 > > > intention in case of > > > option 3 - or > > > is a different way of ESP tunnel envisaged here. > >=20 > > =3D> That's how I understood your original question, it's not=20 > a general > > question, it's specific to the option 3 case. Unless I'm=20 > missing something I > > don't think the latter format (3948) would work in this=20 > case due to the > > additional TLV. >=20 > I don't think either. >=20 > If the additional TLV is after ESP then we the existing ESP=20 > spec may not=20 > say how to calculate ESP fields across that TLV: >=20 > IPv4-header > UDP > ESP > TLV-tunneltypemessage > IPv6-baseheader > IPv6-MobilityHeader >=20 > If the additional TLV is before the ESP then it is obviously insecure: >=20 > IPv4-header > UDP > TLV-tunneltypemessage > ESP > IPv6-baseheader > IPv6-MobilityHeader >=20 > Alex >=20 > >=20 > > Hesham > >=20 > > >=20 > > > Karen > > >=20 > > > > -----Original Message----- > > > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > > > > Sent: 7. juni 2007 11:49 > > > > To: Hesham Soliman > > > > Cc: Karen E. Nielsen (AH/LMD); mip6@ietf.org; nemo@ietf.org > > > > Subject: Re: [Mip6] issue 93 summary > > > >=20 > > > > Hesham Soliman wrote: > > > > > Hi Karen, > > > > >=20 > > > > > Good question. I don't know actually. Transport ESP=20 > on the outer=20 > > > > > header is obviously not a good idea. Transport ESP on the=20 > > > > inner header=20 > > > > > is obviously possible. It doesn't seem like UDP=20 > > > > encapsulated ESP as per 3948 is possible. > > > > > Anyone else has a comment on this? > > > >=20 > > > > YEs. > > > >=20 > > > > I don't think implementations of DS-MIPv6 do what rfc3948=20 > > > > says when encapsulating IPv6 in UDPv4 with ESP. The rfc3948=20 > > > > operations are mainly about re-computing checksums in UDP=20 > > > > header. Doesn't mean it should be ignored. > > > >=20 > > > > I think the differences between RFC3948 (UDP-ESP) and=20 > > > > DS-MIPv6 use of ESP lie in the style of approach of using=20 > > > > ESP. It's not only the typical tunnel vs transport mode. > > > >=20 > > > > It is about which style of ESP? IPv4-style or IPv6-style=20 > > > > ESP? The ESP as usually used by UDP in IPv4 (ESP is after=20 > > > > the UDP header, RFC3948)?=20 > > > > Or the ESP as used by the inner typical IPv6 packet=20 > > > > (IPv6baseheader-ESPheader-MobilityHEader). > > > >=20 > > > > The exact placing of the ESP header (with respect to=20 > UDP and IPv6 > > > > headers) obviously has an impact of the level of protection=20 > > > > afforded. I believe for maximum protection there may be two=20 > > > > ESP headers. > > > >=20 > > > > I think what DS-MIPv6 assumes is this: > > > >=20 > > > > IPv4-header > > > > UDP > > > > IPv6-baseheader > > > > ESP > > > > IPv6-MobilityHeader > > > >=20 > > > > I think what RFC3948 suggests is this: > > > >=20 > > > > IPv4-header IPv4-header > > > > UDP or UDP > > > > ESP ESP > > > > IPv6-MobilityHeader IPv6-baseheader > > > > IPv6-MobilityHeader > > > >=20 > > > > Two ESP headers - one IPv4 style and the other IPv6 style -=20 > > > > would look like this: > > > >=20 > > > > IPv4-header > > > > UDP > > > > ESP > > > > IPv6-baseheader > > > > ESP > > > > IPv6-MobilityHeader > > > >=20 > > > > But that has two ESP headers and UDP is still exposed. So=20 > > > > better would be: > > > >=20 > > > > IPv4-header > > > > ESP > > > > IPv4-header > > > > UDP > > > > ESP > > > > IPv6-header > > > >=20 > > > > But that doesn't traverse NATs because UDP is not seen by=20 > > > > NAT :-( (I think this was already discussed recently). > > > >=20 > > > > Maybe a shorter-packet alternative is this: > > > >=20 > > > > IPv4-header > > > > UDP > > > > ESP > > > > IPv6-MobilityHeader. > > > >=20 > > > > I think in practice the implementer will prefer to either use=20 > > > > IPsec code from that s/he usually uses for IPv4 or for IPv6. =20 > > > > But packets surely look different. > > > >=20 > > > > Alex > > > >=20 > > > >=20 > > > _____________________________________________________________ > > > _________ > > > > This email has been scanned by the MessageLabs Email=20 > > > Security System. > > > > For more information please visit=20 > > > > http://www.messagelabs.com/email=20 > > > >=20 > > > _____________________________________________________________ > > > _________ > > > >=20 > > >=20 > >=20 > >=20 > >=20 >=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 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 07 11:03: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 1HwJW7-0005qX-JU; Thu, 07 Jun 2007 11:03:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJW6-0005pB-6m; Thu, 07 Jun 2007 11:03:14 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwJW5-0007DQ-O3; Thu, 07 Jun 2007 11:03:14 -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 l57F3AA25179; Thu, 7 Jun 2007 15:03: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] issue 93 summary (Text Adequacy) Date: Thu, 7 Jun 2007 10:03:03 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114C3A912@zrc2hxm2.corp.nortel.com> In-Reply-To: <20070607070308.UIFP5648.oaamta07ps.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] issue 93 summary (Text Adequacy) Thread-Index: Aceorx2gDxKnsRnRRCe92adTSLzcvAAELUjgAARjEMAADGzLYA== References: <6FC4416DDE56C44DA0AEE67BC7CA437114C3A358@zrc2hxm2.corp.nortel.com> <20070607070308.UIFP5648.oaamta07ps.mx.bigpond.com@PC20005> From: "Ahmad Muhanna" To: "Hesham Soliman" , , X-Spam-Score: 0.0 (/) 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: , Errors-To: mip6-bounces@ietf.org Thanks Hesham. Understood! However, the comment was not regarding a technical issue (in the sense right vs. wrong) here, but about adequacy of the text. It may ,very well, be straight forward in your mind, however, we are not writing a standard for the editor to read and understand! Right? On the other hand, since we are addressing adequacy of the draft text, let me point out a couple of places that you may need to fix in order to reduce the reader's confusion. CASE No. 1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Under section: 2.3.2.1 Visited network supports IPv4 only (private addresses) " In this scenario the mobile node will need to tunnel IPv6 packets containing the binding update to the home agent's IPv4 address. In order to traverse the NAT device, IPv6 packets are tunneled UDP and IPv4. The UDP port used to send the IPv6 packet is TBD. " Here, it is clear that the MN needs to use UDP whenever using a Private IPv4 address, i.e. a NAT is assumed. However, I assume that the MN probably does not know if it is using a private IPv4 address or to be more accurate, if there is a NAT in path or not. Reading further down under the same section when it talks about what the HA does after receiving a BU with IPv4 HAO, it reads the following: " After accepting the binding update, the home agent MUST create a new binding cache entry for the mobile node's IPv6 home address. If an IPv4 home address option were included, the home agent MUST create another entry for that address. All entries MUST point to the mobile node's IPv4 care-of address included in the source address of the IPv6 packet and represented as an IPv4-mapped IPv6 address. In addition, the tunnel used MUST indicate UDP encapsulation for NAT traversal. .... " Here it is assumed that there is a NAT and HA marked the tunnel with UDP encapsulation for NAT traversal. Right? There is a lot of assumptions can go in the mind of the reader why this is true, however, the straight forward one is we are talking about private IP addresses anyway. Ok, let us move on. " .......... Hence, all packets addressed to the mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in UDP then encapsulated in an IPv4 header that includes the home agent's IPv4 address in the source address field and the mobile node's IPv4 care- of address in the destination address field. " Please tell me, which scenario we are talking about now?! If we assume that we are talking about private IP addresses, then How in the world, the HA will be able to send packet destined to the MN IPv4 care-of address, which is a private address. OK here is one needs to be adequately clarified. [1] CASE No. 2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Let us continue reading under the same section, the same comments above applies on how the HA sends the BA as per the text below: " ... ............... The binding acknowledgement is encapsulated in UDP then IPv4 with the home agent's IPv4 address in the source address field and the mobile node's IPv4 care-of address in the destination field. The inner IPv6 packet will contain the home agent's IPv6 address as a source address and the mobile node's IPv4 care-of address in the destination address field. The latter is represented as an IPv4-mapped IPv6 address. " Are we still talking about private IPv4 addresses in this scenario? I assume yes, because that is the title of the section and what the previous text indicates. Then the same comment above applies here and an adequate clarification is needed. [2] Finally the section ends the discussion as below, which gives the impression that this whole section assumes that NAT is always in path but does not talk how the MN would know that to start with. " The mobile node needs to maintain the NAT bindings for its current IPv4 care-of address. This is done through sending the binding update regularly to the home agent. " May be it is a good idea to up front highlight the assumption that this section is based on to eliminate a lot of confusion, what is the assumption behind the text of this section? Is it: 1. The IPv4 is a private IP address and there is a NAT on path all the time, or 2. The IPv4 address is a private but not necessary there is a NAT, or 3. There is a NAT regardless of the type of IPv4 address allocated to the MN. Case No. 3: =3D=3D=3D=3D=3D=3D=3D=3D=3D Under section 4.1. NAT detection and traversal, it reads: " NAT detection is done when the initial binding update message is sent from the mobile node to the home agent. When located in an IPv4-only foreign link, the mobile node sends the binding update message encapsulated in UDP and IPv4. The source address of the IPv6 packet is the mobile node's IPv4 care-of address represented in IPv4-mapped IPv6 format. The destination address is the IPv6 address of the home agent. The IPv4 header contains the IPv4 care-of address in the source address field and the IPv4 address of the home agent in the destination address field. " This is a clear assumption that the MN uses UDP encapsulation (for sending BU) any time when it is located in an IPv4 only foreign network. Which I assume is the intent here. Let us move on and continue to read under the same section. Now, the below text MAY give an impression that UDP encapsulation is done only when HA detects NAT in the path. Correct? " ......... If the two addresses match, no NAT device was in the path. Otherwise, a NAT device was in the path and the NAT detection option is included in the binding acknowledgement. The binding acknowledgement, and all future packets, are then encapsulated in UDP and IPv4. The source address in the IPv4 header is the IPv4 address of the home agent. The destination address is the IPv4 address received in the IPv4 header encapsulating the binding update (this address will be different from the IPv4 care-of address when a NAT is in the path). " May be another place that clarification is needed. [3] However, here, the dst. IP address is specified correctly:) Reading the below text, I would suggest that an example for, at least, data packets UDP encapsulation like the one for BU and BA is very useful and probably needed. It makes things much cleaner. Instead of just have an indirect reference as in the below paragraph. [3+.5=3D3.5] " If no NAT device was detected in the path between the mobile node and the home agent then IPv6 packets are tunneled in an IPv4 header, unless the home agent forces UDP encapsulation using the F flag. The content of the inner and outer headers are identical to the **** UDP encapsulation case.***=20 " CASE NO. 4: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A. Binding update received by the home agent: 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] Where V4ADDR is either the IPv4 care-of address or the address provided by the NAT device. V4COA is the IPv4 care-of address of the mobile node. HAO is the home address option and BU is the binding update, which MAY contain the IPv4 home address option. I believe the definition of V4ADDR is very useful and SHOULD be global. This can be used whenever the text addresses HA functionality where NAT vs. NO NAT is not clearly identified. It eliminates confusion. [3.5 + 0.5=3D4] CASE NO. 5: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Under section: 4.3.1 Sending packets from a visited network. " When the mobile node is located in an IPv4 only network, it will send IPv6 packets to its home agent according to the following format: IPv4 header (src=3DV4ADDR, dst=3DHA_V4ADDR) [UDP header] IPv6 header (src=3DV6HoA, dst=3DCN) Upper layer protocols Where the UDP header is only used if a NAT were detected between the mobile node and the home agent, or if the home agent forced UDP encapsulation. " Now, the use of the V4ADDR in this context is wrong. We are talking about the MN sending an IPv6 packet in an IPv4 only network. MN will always set the src addr of the outer header to MN's IPv4 Care-of Address. Right? The above format would be perfect if we are talking about the HA receiving an IPv6 packet that the MN sent from an IPv4 only network. Right? The same comment applies to the following case: " Similarly, IPv4 packets are sent according to the following format: IPv4 header (src=3DV4ADDR, dst=3DHA_V4ADDR) [UDP header] IPv4 header (src=3DV4HoA, dst=3DV4CN) Upper layer protocols " An adequate clarification is needed. [4+1=3D5] SUGGESTION: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Finally, probably this suggestion is a little too late in the game and have been discussed earlier, but since the MN is roaming in an IPv4 only foreign network, SHOULD not we make it optional to the MN to request that only an IPv4 HoA to be allocated. This would save resources at the HA. Regards, Ahmad =20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Thursday, June 07, 2007 2:03 AM > To: Muhanna, Ahmad (RICH1:2H10); mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] issue 93 summary >=20 >=20 > > If I understand Jari comments correctly, I think at one=20 > point, he > mentioned that we need to revisit/revaluate the=20 > existing text in the > draft. I looked into the draft but=20 > the only thing that I found w.r.t > option (1) is the following text: > > > > LOCATION NO. 1: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 2.3.2.1 Visited network supports IPv4 only (private addresses) >=20 > > In this scenario the mobile node will need to tunnel=20 > IPv6 packets > > containing the binding update to the home agent's IPv4=20 > address. In > > order to traverse the NAT device, IPv6 packets are=20 > > tunneled UDP and > > IPv4. The UDP port used to send the IPv6 packet is TBD. > > > > Basically there is no text included in the draft to=20 > explain how to > identify the type of payload that is=20 > encapsulated in UDP. In > other words > and strictly=20 > speaking, if we take the draft most relevant text above, >=20 > this "TBD" reserved UDP port will always indicate that the >=20 > payload is an > IPv6!=20 >=20 > =3D> No that's not true at all. There is an IP version field in=20 > the IP header that tells you what the header is. The fact=20 > that the IP header fields (for > v4 or v6) are not revisited in this draft does not in any=20 > shape or form suggest that we have no way of parsing header.=20 > I suggest that we get off the header parsing argument because=20 > frankly, it's a waste of time. Everyone knows (including=20 > people who want option 3) that you can do this with the=20 > version field. Let's not debate facts here, it's pointless.=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 Jun 07 11:10: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 1HwJcc-0004Yh-V3; Thu, 07 Jun 2007 11:09:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJcb-0004SB-Sl; Thu, 07 Jun 2007 11:09:57 -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 1HwJXD-0007rm-R2; Thu, 07 Jun 2007 11:04:25 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2007 08:04:23 -0700 X-IronPort-AV: i="4.16,395,1175497200"; d="scan'208"; a="491499355:sNHT52356230" 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 l57F4NdJ016892; Thu, 7 Jun 2007 08:04:23 -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 l57F4C2A020403; Thu, 7 Jun 2007 15:04:22 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, 7 Jun 2007 08:04:20 -0700 Received: from sgundavewxp ([10.21.83.232]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 08:04:20 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , "'Karen E. Nielsen \(AH/LMD\)'" , "'Alexandru Petrescu'" References: <20070607120155.XAZS6690.oaamta06ps.mx.bigpond.com@PC20005> Subject: RE: [Mip6] issue 93 summary Date: Thu, 7 Jun 2007 08:04:20 -0700 Message-ID: <003201c7a915$20437e50$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QA== In-Reply-To: <20070607120155.XAZS6690.oaamta06ps.mx.bigpond.com@PC20005> X-OriginalArrivalTime: 07 Jun 2007 15:04:20.0568 (UTC) FILETIME=[205C5D80:01C7A915] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=555; t=1181228663; x=1182092663; 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]=20issue=2093=20summary |Sender:=20; bh=msYuQq9yaeNry8d9G99OO6364h3wrwt3gGNJ6Ym3eK4=; b=lfvxmbz9cdJaJZ2EQHPvG4AVmeWvG4Zxr/rdNWWnlpboas8PWRH6bG+9ZL3hfjzDVCzHH6gS fhK4nnj12Wv1QPQBYSkF6d4qcMuT0latLgrauE3wgui8aLNHGROprlvv; 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: cf4fa59384e76e63313391b70cd0dd25 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 > > => That's how I understood your original question, it's not a general > question, it's specific to the option 3 case. Unless I'm > missing something I > don't think the latter format (3948) would work in this case > due to the > additional TLV. > If ESP over UDP is negotiated, then the port number will be UDP 4500. We cannot use the DSMIP UDP tunnel port number for this. The packets have to be handled by IPSec process and not MIP process. So, the IPSec issue Karen raised is common for both option#1 and option#3, IMO. Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 07 11:18: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 1HwJl9-0000hZ-QT; Thu, 07 Jun 2007 11:18:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJl8-0000hL-Uh; Thu, 07 Jun 2007 11:18:46 -0400 Received: from omta04ps.mx.bigpond.com ([144.140.83.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwJl7-00056Q-GD; Thu, 07 Jun 2007 11:18:46 -0400 Received: from oaamta08ps.mx.bigpond.com ([124.191.178.123]) by omta04ps.mx.bigpond.com with ESMTP id <20070607151842.NDV15631.omta04ps.mx.bigpond.com@oaamta08ps.mx.bigpond.com>; Thu, 7 Jun 2007 15:18:42 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta08ps.mx.bigpond.com with ESMTP id <20070607151842.HRIL3831.oaamta08ps.mx.bigpond.com@PC20005>; Thu, 7 Jun 2007 15:18:42 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , "'Karen E. Nielsen \(AH/LMD\)'" , "'Alexandru Petrescu'" Subject: RE: [Mip6] issue 93 summary Date: Fri, 8 Jun 2007 01:18:37 +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 In-Reply-To: <003201c7a915$20437e50$1220fea9@amer.cisco.com> Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHw Message-Id: <20070607151842.HRIL3831.oaamta08ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 > > => That's how I understood your original question, it's > not a general > > question, it's specific to the option 3 case. Unless I'm > > missing something I > > don't think the latter format (3948) would work in this case > > due to the > > additional TLV. > > > > If ESP over UDP is negotiated, then the port number will be UDP 4500. => Agreed. > We cannot use the DSMIP UDP tunnel port number for this. The packets > have to be handled by IPSec process and not MIP process. So, > the IPSec > issue Karen raised is common for both option#1 and option#3, IMO. => I don't understand this part. If we're using port 4500 and following 3948, how would the IPsec implementation add that TLV or process it at the receiving end? Assume that a packet (v4 or v6) is passed to IPsec for sending, are you saying that the TLV is added to that packet before passing it to IPsec? If so, are you asking that this TLV gets treated as a protocol? It might be too late at night for me here but I don't follow. I don't see this issue in option 1 or 2 because there is no confusion about adding the TLV. Assuming that you answer the above issue, how does a packet that contains the TLV after ESP get processed at the receiving end? I mean, after it's decapsulated how do you parse the packet? you don't necessarily know that it's a TLV, it could be an IP packet as described in 3498. Hesham > > Sri > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 07 11:20: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 1HwJmT-0003dQ-9c; Thu, 07 Jun 2007 11:20:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJmQ-0003U6-VA; Thu, 07 Jun 2007 11:20:06 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwJmO-0005K5-Q9; Thu, 07 Jun 2007 11:20:06 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2007 08:20:04 -0700 X-IronPort-AV: i="4.16,395,1175497200"; d="scan'208"; a="4489113:sNHT23373330" 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 l57FK3Rb013590; Thu, 7 Jun 2007 08:20:03 -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 l57FJoai017148; Thu, 7 Jun 2007 15:20:03 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 08:20:00 -0700 Received: from sgundavewxp ([10.21.83.232]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 08:20:00 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , "'Jari Arkko'" , "'Basavaraj Patil'" , "'Henrik Levkowetz'" References: <004f01c7a8bb$28b99470$1220fea9@amer.cisco.com> <20070607043545.KGCE24660.oaamta01sl.mx.bigpond.com@PC20005> Subject: RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus calltocloseissue 93 Date: Thu, 7 Jun 2007 08:19:59 -0700 Message-ID: <003301c7a917$50538020$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceog07TO1La/gT9RhyphyL26IwOawAGttwQAAMam6AAA88QsAAAjlBwABZUbaA= In-Reply-To: <20070607043545.KGCE24660.oaamta01sl.mx.bigpond.com@PC20005> X-OriginalArrivalTime: 07 Jun 2007 15:20:00.0204 (UTC) FILETIME=[506D70C0:01C7A917] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2304; t=1181229604; x=1182093604; 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]=20Summary=20and=20conclusion=20of=3A=20DS-MIP6 =20-=20Consensus=20calltocloseissue=2093 |Sender:=20; bh=hLmozkhPpoaNrwFAFSTupcQhrP0dBb559v2iRRXWj1I=; b=Ka6eWAhh+z5MZW/egap5a1UCicnOmGrcR30XejEb9K5rFBj55PqYRY3g5UyX8Rmyt9z69mi7 yP0yGjNhjlc2iEj0ip1PClLLFwA5/33tpD2AQeGQ2r8zKqJ3oNQcxM8p; 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: d0bdc596f8dd1c226c458f0b4df27a88 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, > => We discussed this already no? We said that you could > encapsulate a ping > in IP or use a dst option if you want to save bytes. So there > are many ways > of doing this, I don't see this as a Y2K equivalent. > Yes. Your suggestion will work ! A *minor* side affect is that, if a user does a manual ping to the HA, the HA will not be able to differentiate between the user ping to the DSMIP ping, always DSMIP process gets all the packets. > => I'd appreciate some pointers to this problem. About 18 > months ago I asked > for 6 ports and got them almost instantly. > I will let Henrik answer the port number issue. As I mentioned, this was noted by Henrik. > > > > > > 6. Why do we need GRE Header ? > > > > > > We need GRE tunnel header for various reasons, "when ever we > > carry multiple streams within a tunnel, the GRE header for its > > mature header semantics, the key field and the sequence number > > field is useful." > > => I've added quotes around the area that I'm responding to above > Are you seriously saying that whenever multiple flows are > encapsulated in a > packet GRE is needed? > If you are then I think this is flat wrong, factually it's > wrong. I hope you > can either qualify that or change it or explain it better. > > I'll leave it with those comments for now to focus the > discussion, I have > other comments on the rest of the text but let's do it piecemeal. > When a tunnel carries multiple flows from different nodes, the semantics of the outer GRE header are useful. That was my intended comment. Now, I've cleary given the pointers as where its useful. - In Proxy Mobile IPv6, when the MAG is supporting mobile nodes with overlapping private IPv4 addresses, we need a selector that can be used by the tunnel peers for differentiating the flows. - I've given pointers to the three active drafts, using GRE and all are mobility related drafts, leveraging GRE header. George's draft uses GRE key as a way to identify the mobile flows inside. My text above may not be convincing to you, but, the use of GRE is much more than what we think, IMHO. Just these 3 draft and the support for GRE in MIP4, reflect the same. Thanks Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 07 11:25: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 1HwJrI-0000DB-RU; Thu, 07 Jun 2007 11:25:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJrI-0000D2-3e; Thu, 07 Jun 2007 11:25:08 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwJrG-0006Mx-OS; Thu, 07 Jun 2007 11:25:08 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 07 Jun 2007 08:25:05 -0700 X-IronPort-AV: i="4.16,395,1175497200"; d="scan'208"; a="160526860:sNHT45326889" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l57FP5fR022909; Thu, 7 Jun 2007 08:25:05 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l57FOt0Y015164; Thu, 7 Jun 2007 15:25:05 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, 7 Jun 2007 08:25:05 -0700 Received: from sgundavewxp ([10.21.83.232]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 08:25:04 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , "'Karen E. Nielsen \(AH/LMD\)'" , "'Alexandru Petrescu'" References: <003201c7a915$20437e50$1220fea9@amer.cisco.com> <20070607151842.HRIL3831.oaamta08ps.mx.bigpond.com@PC20005> Subject: RE: [Mip6] issue 93 summary Date: Thu, 7 Jun 2007 08:25:04 -0700 Message-ID: <003901c7a918$05c84a30$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aA= In-Reply-To: <20070607151842.HRIL3831.oaamta08ps.mx.bigpond.com@PC20005> X-OriginalArrivalTime: 07 Jun 2007 15:25:04.0685 (UTC) FILETIME=[05E98DD0:01C7A918] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1436; t=1181229905; x=1182093905; 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]=20issue=2093=20summary |Sender:=20; bh=A4rJ+UP8nYAL8+31LrW0/0zAokuRXIU+91bIqFxjhEs=; b=iMkpnjWTJzJqHeDjRmHj61uiSt7JCmWw/MpGzmzXRDTtRJ+IwoT/kJFfb8OtJH9hzjjlr5si exiP+nqN+1GTsyYRtl0ZQl9gXKGVMHIIbnwGyC8QF5agBD3lfPD3zeFU; 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: 9ed51c9d1356100bce94f1ae4ec616a9 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 > -----Original Message----- > > > We cannot use the DSMIP UDP tunnel port number for this. > The packets > > have to be handled by IPSec process and not MIP process. So, > > the IPSec > > issue Karen raised is common for both option#1 and option#3, IMO. > > => I don't understand this part. If we're using port 4500 and > following > 3948, how would the IPsec implementation add that TLV or > process it at the > receiving end? > Assume that a packet (v4 or v6) is passed to IPsec for > sending, are you > saying that the TLV is added to that packet before passing it > to IPsec? If > so, are you asking that this TLV gets treated as a protocol? > It might be too > late at night for me here but I don't follow. > I don't see this issue in option 1 or 2 because there is no > confusion about > adding the TLV. > > Assuming that you answer the above issue, how does a packet > that contains > the TLV after ESP get processed at the receiving end? I mean, > after it's > decapsulated how do you parse the packet? you don't > necessarily know that > it's a TLV, it could be an IP packet as described in 3498. > > Hesham Ok. If there is no TLV header, how does the IPSec process after decap, demux the packets ? Will it look in the version field as DSMIP ? How does it know, if it needs to feed the packet to the IPv4 forwarding engine or IPv6 forwarding engine ? Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 07 11:37: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 1HwK3J-0007uK-2M; Thu, 07 Jun 2007 11:37:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwK3H-0007sv-TF; Thu, 07 Jun 2007 11:37:31 -0400 Received: from omta04ps.mx.bigpond.com ([144.140.83.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwK37-0002FK-60; Thu, 07 Jun 2007 11:37:22 -0400 Received: from oaamta08ps.mx.bigpond.com ([124.191.178.123]) by omta04ps.mx.bigpond.com with ESMTP id <20070607153719.QDO15631.omta04ps.mx.bigpond.com@oaamta08ps.mx.bigpond.com>; Thu, 7 Jun 2007 15:37:19 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta08ps.mx.bigpond.com with ESMTP id <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005>; Thu, 7 Jun 2007 15:37:19 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , "'Karen E. Nielsen \(AH/LMD\)'" , "'Alexandru Petrescu'" Subject: RE: [Mip6] issue 93 summary Date: Fri, 8 Jun 2007 01:37:14 +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 In-Reply-To: <003901c7a918$05c84a30$1220fea9@amer.cisco.com> Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAA== Message-Id: <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 > > -----Original Message----- > > > > > We cannot use the DSMIP UDP tunnel port number for this. > > The packets > > > have to be handled by IPSec process and not MIP process. So, > > > the IPSec > > > issue Karen raised is common for both option#1 and > option#3, IMO. > > > > => I don't understand this part. If we're using port 4500 and > > following > > 3948, how would the IPsec implementation add that TLV or > > process it at the > > receiving end? > > Assume that a packet (v4 or v6) is passed to IPsec for > > sending, are you > > saying that the TLV is added to that packet before passing it > > to IPsec? If > > so, are you asking that this TLV gets treated as a protocol? > > It might be too > > late at night for me here but I don't follow. > > I don't see this issue in option 1 or 2 because there is no > > confusion about > > adding the TLV. > > > > Assuming that you answer the above issue, how does a packet > > that contains > > the TLV after ESP get processed at the receiving end? I mean, > > after it's > > decapsulated how do you parse the packet? you don't > > necessarily know that > > it's a TLV, it could be an IP packet as described in 3498. > > > > Hesham > > Ok. If there is no TLV header, how does the IPSec process after > decap, demux the packets ? Will it look in the version field > as DSMIP ? How does it know, if it needs to feed the packet > to the IPv4 forwarding engine or IPv6 forwarding engine ? => There is not much listening going on here obviously, my questions reamin unanswered.... To answer your questions, it processes them like any other packet received using 3948, it assumes it's an IP packet and sends it to the stack for normal processing. You get a packet, check with version and send it to ip_input or ip6_input. What's the problem? Incidentally, RFC 3948 says that it works whether the inner packet is v4 or v6. Hesham > > Sri > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 07 11:37: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 1HwK3O-00085l-Oi; Thu, 07 Jun 2007 11:37:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwK3L-0007u8-8N; Thu, 07 Jun 2007 11:37:35 -0400 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwJzV-00011b-Do; Thu, 07 Jun 2007 11:33:37 -0400 Received: from oaamta06ps.mx.bigpond.com ([124.191.178.123]) by omta01ps.mx.bigpond.com with ESMTP id <20070607153334.DIEC19666.omta01ps.mx.bigpond.com@oaamta06ps.mx.bigpond.com>; Thu, 7 Jun 2007 15:33:34 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta06ps.mx.bigpond.com with ESMTP id <20070607153333.XWIH6690.oaamta06ps.mx.bigpond.com@PC20005>; Thu, 7 Jun 2007 15:33:33 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , "'Jari Arkko'" , "'Basavaraj Patil'" , "'Henrik Levkowetz'" Subject: RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus calltocloseissue 93 Date: Fri, 8 Jun 2007 01:33:28 +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 In-Reply-To: <003301c7a917$50538020$1220fea9@amer.cisco.com> Thread-Index: Aceog07TO1La/gT9RhyphyL26IwOawAGttwQAAMam6AAA88QsAAAjlBwABZUbaAAALVYMA== Message-Id: <20070607153333.XWIH6690.oaamta06ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 > > => We discussed this already no? We said that you could > > encapsulate a ping > > in IP or use a dst option if you want to save bytes. So there > > are many ways > > of doing this, I don't see this as a Y2K equivalent. > > > > Yes. Your suggestion will work ! A *minor* side affect is that, > if a user does a manual ping to the HA, the HA will not be > able to differentiate between the user ping to the DSMIP > ping, always DSMIP process gets all the packets. => Well, sure, and it should. Just like a user ping in plain MIP might get tunnelled unless you force the use of the CoA. > > > We need GRE tunnel header for various reasons, "when ever we > > > carry multiple streams within a tunnel, the GRE header for its > > > mature header semantics, the key field and the sequence number > > > field is useful." > > > > => I've added quotes around the area that I'm responding to above > > Are you seriously saying that whenever multiple flows are > > encapsulated in a > > packet GRE is needed? > > If you are then I think this is flat wrong, factually it's > > wrong. I hope you > > can either qualify that or change it or explain it better. > > > > I'll leave it with those comments for now to focus the > > discussion, I have > > other comments on the rest of the text but let's do it piecemeal. > > > > When a tunnel carries multiple flows from different nodes, the > semantics of the outer GRE header are useful. That was my intended > comment. Now, I've cleary given the pointers as where its useful. > > - In Proxy Mobile IPv6, when the MAG is supporting mobile nodes > with overlapping private IPv4 addresses, we need a selector that > can be used by the tunnel peers for differentiating the flows. > > - I've given pointers to the three active drafts, using GRE and > all are mobility related drafts, leveraging GRE header. George's > draft uses GRE key as a way to identify the mobile flows inside. => Yes but you're referencing drafts for PMIP and MIPv4! We know it's needed for IPv4 networks with overlapping IP addresses and we discussed that before (and it's typically used by the infrastructure not the host). None of that applies here. I already said that if for some reason you need it in PMIP then you can use it before the UDP header. Plus, why are we standardising PMIP extensions in this WG? > > My text above may not be convincing to you, but, the use of GRE is > much more than what we think, IMHO. Just these 3 draft and the > support for GRE in MIP4, reflect the same. => I know GRE is used but the use cases do not apply to our scenarios here. Of course you can create a scenario where you use it from a host if you really want to, my point is that we don't *need* it, as your earlier text seemed to imply in no uncertain terms. How many hosts use GRE today? Hesham > > Thanks > Sri > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 07 11:40: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 1HwK5m-0002MX-HY; Thu, 07 Jun 2007 11:40:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwK5l-0002MO-3M; Thu, 07 Jun 2007 11:40:05 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwK5k-0003d1-Mj; Thu, 07 Jun 2007 11:40:05 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1181230803!22511504!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 25588 invoked from network); 7 Jun 2007 15:40:04 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-119.messagelabs.com with SMTP; 7 Jun 2007 15:40:04 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l57Fe3rA008882; Thu, 7 Jun 2007 08:40:03 -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 l57Fe3gG002708; Thu, 7 Jun 2007 10:40:03 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l57Fe1lq002611; Thu, 7 Jun 2007 10:40:01 -0500 (CDT) Message-ID: <466826CB.10405@gmail.com> Date: Thu, 07 Jun 2007 17:39:55 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] issue 93 summary References: <20070607120155.XAZS6690.oaamta06ps.mx.bigpond.com@PC20005> <4667F876.9030109@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000747-3, 06/06/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 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: > This discussion is creating confusion. Obviously if we have > the TLV that comes after the UDP header, we are not really > using RFC 3948 (UDP encapsulation for ESP). It would still > work fine. The port number in UDP header would not point > to ESP. It would point this new TLV (MIP tunnel data message > header). The TLV's port/protocol field will then point to ESP. Mostly yes. > There is *no* problem in encryption or calculating the MAC > in the ESP header. It would work fine with the TLV header. ??? One doesn't know to encrypt any other thing than an IP packet or the payload of an IP packet... and that TLV is neither. Alex > > Vijay > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Thursday, June 07, 2007 5:22 AM >> To: Hesham Soliman >> Cc: nemo@ietf.org; mip6@ietf.org >> Subject: Re: [Mip6] issue 93 summary >> >> Hesham Soliman wrote: >>> > I agree that DS-MIP model for BU ESP protection is: >>> >>> => Perhaps the draft needs clarification because there is >> no reason why this >>> should be the only model. >>> >>> > >>> > > IPv4-header >>> > > UDP >>> > > IPv6-baseheader >>> > > ESP >>> > > IPv6-MobilityHeader >>> > >>> > But what about ESP tunnel payload protection (and >> optional way of BU >>> > protection - read: Section 3 of 4877). >>> > Here it could be appropriate to use UDP ESP 3948 to obtain >>> > >>> > IPv4-header >>> > UDP >>> > ESP >>> > IPv6/4-header >>> > Payload/BU >>> > >>> >>> => Right, which we do support today. >>> >>> > but, then the question for me is - is that also the >>> > intention in case of >>> > option 3 - or >>> > is a different way of ESP tunnel envisaged here. >>> >>> => That's how I understood your original question, it's not >> a general >>> question, it's specific to the option 3 case. Unless I'm >> missing something I >>> don't think the latter format (3948) would work in this >> case due to the >>> additional TLV. >> I don't think either. >> >> If the additional TLV is after ESP then we the existing ESP >> spec may not >> say how to calculate ESP fields across that TLV: >> >> IPv4-header >> UDP >> ESP >> TLV-tunneltypemessage >> IPv6-baseheader >> IPv6-MobilityHeader >> >> If the additional TLV is before the ESP then it is obviously insecure: >> >> IPv4-header >> UDP >> TLV-tunneltypemessage >> ESP >> IPv6-baseheader >> IPv6-MobilityHeader >> >> Alex >> >>> Hesham >>> >>> > >>> > Karen >>> > >>> > > -----Original Message----- >>> > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >>> > > Sent: 7. juni 2007 11:49 >>> > > To: Hesham Soliman >>> > > Cc: Karen E. Nielsen (AH/LMD); mip6@ietf.org; nemo@ietf.org >>> > > Subject: Re: [Mip6] issue 93 summary >>> > > >>> > > Hesham Soliman wrote: >>> > > > Hi Karen, >>> > > > >>> > > > Good question. I don't know actually. Transport ESP >> on the outer >>> > > > header is obviously not a good idea. Transport ESP on the >>> > > inner header >>> > > > is obviously possible. It doesn't seem like UDP >>> > > encapsulated ESP as per 3948 is possible. >>> > > > Anyone else has a comment on this? >>> > > >>> > > YEs. >>> > > >>> > > I don't think implementations of DS-MIPv6 do what rfc3948 >>> > > says when encapsulating IPv6 in UDPv4 with ESP. The rfc3948 >>> > > operations are mainly about re-computing checksums in UDP >>> > > header. Doesn't mean it should be ignored. >>> > > >>> > > I think the differences between RFC3948 (UDP-ESP) and >>> > > DS-MIPv6 use of ESP lie in the style of approach of using >>> > > ESP. It's not only the typical tunnel vs transport mode. >>> > > >>> > > It is about which style of ESP? IPv4-style or IPv6-style >>> > > ESP? The ESP as usually used by UDP in IPv4 (ESP is after >>> > > the UDP header, RFC3948)? >>> > > Or the ESP as used by the inner typical IPv6 packet >>> > > (IPv6baseheader-ESPheader-MobilityHEader). >>> > > >>> > > The exact placing of the ESP header (with respect to >> UDP and IPv6 >>> > > headers) obviously has an impact of the level of protection >>> > > afforded. I believe for maximum protection there may be two >>> > > ESP headers. >>> > > >>> > > I think what DS-MIPv6 assumes is this: >>> > > >>> > > IPv4-header >>> > > UDP >>> > > IPv6-baseheader >>> > > ESP >>> > > IPv6-MobilityHeader >>> > > >>> > > I think what RFC3948 suggests is this: >>> > > >>> > > IPv4-header IPv4-header >>> > > UDP or UDP >>> > > ESP ESP >>> > > IPv6-MobilityHeader IPv6-baseheader >>> > > IPv6-MobilityHeader >>> > > >>> > > Two ESP headers - one IPv4 style and the other IPv6 style - >>> > > would look like this: >>> > > >>> > > IPv4-header >>> > > UDP >>> > > ESP >>> > > IPv6-baseheader >>> > > ESP >>> > > IPv6-MobilityHeader >>> > > >>> > > But that has two ESP headers and UDP is still exposed. So >>> > > better would be: >>> > > >>> > > IPv4-header >>> > > ESP >>> > > IPv4-header >>> > > UDP >>> > > ESP >>> > > IPv6-header >>> > > >>> > > But that doesn't traverse NATs because UDP is not seen by >>> > > NAT :-( (I think this was already discussed recently). >>> > > >>> > > Maybe a shorter-packet alternative is this: >>> > > >>> > > IPv4-header >>> > > UDP >>> > > ESP >>> > > IPv6-MobilityHeader. >>> > > >>> > > I think in practice the implementer will prefer to either use >>> > > IPsec code from that s/he usually uses for IPv4 or for IPv6. >>> > > But packets surely look different. >>> > > >>> > > 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 >> > ______________________________________________________________________ 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 Jun 07 11:53: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 1HwKIj-0006Hj-VQ; Thu, 07 Jun 2007 11:53:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKIj-0006HV-Cw; Thu, 07 Jun 2007 11:53:29 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwKIi-0007t0-2V; Thu, 07 Jun 2007 11:53:29 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 07 Jun 2007 08:53:27 -0700 X-IronPort-AV: i="4.16,395,1175497200"; d="scan'208"; a="2131424:sNHT21429792" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l57FrRht013210; Thu, 7 Jun 2007 08:53:27 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l57FnM0e021554; Thu, 7 Jun 2007 15:53:27 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, 7 Jun 2007 08:53:26 -0700 Received: from sgundavewxp ([10.21.83.232]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 08:53:26 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , "'Karen E. Nielsen \(AH/LMD\)'" , "'Alexandru Petrescu'" References: <003901c7a918$05c84a30$1220fea9@amer.cisco.com> <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005> Subject: RE: [Mip6] issue 93 summary Date: Thu, 7 Jun 2007 08:53:25 -0700 Message-ID: <004001c7a91b$fc2d0b10$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAAPb+g In-Reply-To: <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005> X-OriginalArrivalTime: 07 Jun 2007 15:53:26.0509 (UTC) FILETIME=[FC4749D0:01C7A91B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1595; t=1181231607; x=1182095607; 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[Mip6]=20issue=2093=20summary |Sender:=20; bh=g0bGQQMgvu/HwRcfondDgqBQQRhfpo+ArsqLx3RZoY4=; b=KJHDzkDk0N9eRsRGAePfOcXlJBgVKrjPmT8aBUWcl0rbcmrCL0qx39VxVXAtHwlsFb7Yd+5U 6l919jqIAxCf0voHjTeSzUOoey70FUjrStgFsQmTSbm7DXZiI+hEzvLosCtFYXy67etoFzq8rj zNW88RGMWkzPx74WbOf6iB/XY=; 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: 69a74e02bbee44ab4f8eafdbcedd94a1 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 > > > > Ok. If there is no TLV header, how does the IPSec process after > > decap, demux the packets ? Will it look in the version field > > as DSMIP ? How does it know, if it needs to feed the packet > > to the IPv4 forwarding engine or IPv6 forwarding engine ? > > => There is not much listening going on here obviously, my > questions reamin > unanswered.... No. I'm :) My comment is that, the issue is the same for both. The issue exists and I already agreed to it. Either case, the IPSec process has to parse either the version field of the packet or the TLV header and I dont believe any implementations do either of them today. > To answer your questions, it processes them like any other > packet received > using 3948, it assumes it's an IP packet and sends it to the stack for > normal processing. You get a packet, check with version and send it to > ip_input or ip6_input. What's the problem? Incidentally, RFC > 3948 says that > it works whether the inner packet is v4 or v6. > >From what I interpret from 3948, the mechanism of UDP transport can be used when the outer header and the contained header are both either IPv4 or IPv6. It did not state that the IPSec process has to look in the version field and do the demux to ip_input or ipv6_input. So, it did not talk about a scenario where the payload is IPv6 and the transport is IPv4. If we can get this clarified from the IPSec guys, that will be good. If 3948 can support IPv4, IPv6 payloads in an IPv4-UDP-ESP, then the issue exists is not applicable to option #1. Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 07 11:58: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 1HwKNq-0001MZ-Sw; Thu, 07 Jun 2007 11:58:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKNo-0001KM-LO; Thu, 07 Jun 2007 11:58:44 -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 1HwKNn-00025X-SC; Thu, 07 Jun 2007 11:58:44 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l57FwFFJ031432; Thu, 7 Jun 2007 18:58:37 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 18:58:33 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 10:58:15 -0500 Received: from 172.19.244.148 ([172.19.244.148]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 7 Jun 2007 15:58:15 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 07 Jun 2007 10:58:24 -0500 Subject: Re: [Mip6] issue 93 summary From: Basavaraj Patil To: ext Hesham Soliman , , Message-ID: Thread-Topic: [Mip6] issue 93 summary Thread-Index: Aceorx2gDxKnsRnRRCe92adTSLzcvAAbY/7M In-Reply-To: <20070607025414.RNUJ23012.oaamta07sl.mx.bigpond.com@PC20005> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Jun 2007 15:58:15.0294 (UTC) FILETIME=[A86861E0:01C7A91C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) 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 In the context of DS-MIP6 and the scope or usage of this functionality by MIP6 or NEMO, I do believe that option 1 is sufficient. The type of packets encapsulated in the UDP tunnel are either IPv4 or IPv6. And as the discussion has shown, parising of these packets is not really a problem. There is no need for an explicit indication of the encapsulated packet type via a header. The 4 byte header as proposed by option 3 adds to the overhead since every packet between the MN and HA will now include it. It could be argued that 4 byte overhead in the overall scope of the headers of the tunnelled packets is not a significant percentage but it still is an overhead that can be avoided. Additionally HC schemes that may be applied to the normal IP/UDP headers will need to be updated or will have to consider this 4 byte header as well. So I do not believe option 3 from an efficiency perspective is a good choice for MIP6. It has been mentioned (by Vijay) that we already support option 2 since we have a separate port for the ESP encapsulated packets and we have this port for packets tunnelled over UDP. If GRE or other packets are in the future determined as being essential to be tunnelled over UDP between the MN and HA another port could be reserved as well. I am of the opinion that when the need for carrying GRE or other packet types is demonstrated either in the MIP6 or NEMO WGs or elsewhere and there is agreement on it, a draft could be written that updates the current DS-MIP6 document and proposes a new port that would enable the MN and HA to process those packets. I do not believe this is being short-sighted because the need for GRE in the context of MIP6 and NEMO has not really been proven inspite of the numerous discussions on the ML. Having felxibility in a protocol is also not a good reason (kitchen sink theory). -Raj On 6/6/07 9:54 PM, "ext Hesham Soliman" wrote: > > > In light of the discussions that went on I thought it would be useful to > summarise the issue and discussions so far to give people who haven't kept > up an insight into what this is all about. > > First the issue text discussed the need for a "TLV" type encoding between > the outer IP header and the inner UDP header. The reason specified in the > issue was that the upper layer parsing the packet can't tell what > information follows UDP unless it is explicitly encoded. Upon further > discussion it was clear that this rationale is not true because the upper > layer can always parse the version field in the IP header following UDP. > > However, the following question was "what if the information following UDP > was not an IP header?". One could encode messages (at least in theory) that > follow UDP and that are not IP. But to save space and reading time, the main > (probably only) example for such information is the use of GRE > encapsulation. Some people don't see the need for the use of GRE and some > people do. I suggested that GRE can be used before UDP and not after, but > that was seen as unhelpful for cases where a NAT is present. > > Since I, after substantial effort, still couldn't find out what the > deployment scenario that needs this might be, I won't try to invent a > scenario for GRE on behalf of people who are calling for it and I'll leave > the floor open for that discussion. The point I wanted to highlight here > that practically this is the only reason left for adding TLV encoding. > > Finally, there are 3 options available for us to move forward and I'll use > the same numbers that Raj use to avoid confusing people: > > 1. Do nothing, keep the draft as is. > > 2. Specify a different port number for the different format suggested. > > 3. Add the TLV encoding suggested in the issue. > > > 1) above implies that should there be agreement in future that the format > suggested in this issue is necessary, it can be achieved using option 2 > (i.e. specify a new port that carries that format). This can be used if, for > example, GRE is needed for NETLMM. A MAG can use a different port from the > one used by the MN. The main reasons expressed by people for choosing 1 > were: > a) Adding 4 bytes on every packet is not needed. > b) GRE is not needed. > > 2) above is pretty clear to everyone I think but Karen Nielsen raised some > questions that people should read. > > 3) I believe 3 is also clear for everyone. Going to 3 will not require a > move to 2) later. Of course this comes at the cost mentioned above. I > believe the main reason expressed by people for this option was "future > proof". > > So, hopefully this gives a summary of the discussion so far. I think there > are basically two ways of finding concensus: > 1. Discuss the rationale a lot more to make either side move. For instance, > discuss the deployment scenarios that require GRE, what is "future proof", > why the extra 4 bytes are an issue for those who chose 1) ...etc > 2. Due to current threads more people might express their opionions. > > I'm not too hopeful with 2) above because most of the people that are > actively involved have commented. Plus it would actually be nice to see 1) > being achieved once in a while! So let's try to do that. > > Hesham > > > > _______________________________________________ > 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 Jun 07 11:58: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 1HwKNq-0001MF-HH; Thu, 07 Jun 2007 11:58:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKNo-0001KH-J9; Thu, 07 Jun 2007 11:58:44 -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 1HwKNn-00025Y-Vi; Thu, 07 Jun 2007 11:58:44 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l57FwFDj023596; Thu, 7 Jun 2007 18:58:38 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 18:58:18 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 10:58:16 -0500 Received: from 172.19.244.148 ([172.19.244.148]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 7 Jun 2007 15:58:16 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 07 Jun 2007 10:58:25 -0500 Subject: Re: [Mip6] issue 93 summary (Please review and comment) From: Basavaraj Patil To: ext Hesham Soliman , , Message-ID: Thread-Topic: [Mip6] issue 93 summary (Please review and comment) Thread-Index: Aceorx2gDxKnsRnRRCe92adTSLzcvAAbZCQp In-Reply-To: <20070607025414.RNUJ23012.oaamta07sl.mx.bigpond.com@PC20005> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Jun 2007 15:58:16.0819 (UTC) FILETIME=[A9511430:01C7A91C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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, In order to get a better sense of consensus, I would encourage more people who are on the MIP6 ML to express their opinion on this issue (summarized below by Hesham). -Raj On 6/6/07 9:54 PM, "ext Hesham Soliman" wrote: > > > In light of the discussions that went on I thought it would be useful to > summarise the issue and discussions so far to give people who haven't kept > up an insight into what this is all about. > > First the issue text discussed the need for a "TLV" type encoding between > the outer IP header and the inner UDP header. The reason specified in the > issue was that the upper layer parsing the packet can't tell what > information follows UDP unless it is explicitly encoded. Upon further > discussion it was clear that this rationale is not true because the upper > layer can always parse the version field in the IP header following UDP. > > However, the following question was "what if the information following UDP > was not an IP header?". One could encode messages (at least in theory) that > follow UDP and that are not IP. But to save space and reading time, the main > (probably only) example for such information is the use of GRE > encapsulation. Some people don't see the need for the use of GRE and some > people do. I suggested that GRE can be used before UDP and not after, but > that was seen as unhelpful for cases where a NAT is present. > > Since I, after substantial effort, still couldn't find out what the > deployment scenario that needs this might be, I won't try to invent a > scenario for GRE on behalf of people who are calling for it and I'll leave > the floor open for that discussion. The point I wanted to highlight here > that practically this is the only reason left for adding TLV encoding. > > Finally, there are 3 options available for us to move forward and I'll use > the same numbers that Raj use to avoid confusing people: > > 1. Do nothing, keep the draft as is. > > 2. Specify a different port number for the different format suggested. > > 3. Add the TLV encoding suggested in the issue. > > > 1) above implies that should there be agreement in future that the format > suggested in this issue is necessary, it can be achieved using option 2 > (i.e. specify a new port that carries that format). This can be used if, for > example, GRE is needed for NETLMM. A MAG can use a different port from the > one used by the MN. The main reasons expressed by people for choosing 1 > were: > a) Adding 4 bytes on every packet is not needed. > b) GRE is not needed. > > 2) above is pretty clear to everyone I think but Karen Nielsen raised some > questions that people should read. > > 3) I believe 3 is also clear for everyone. Going to 3 will not require a > move to 2) later. Of course this comes at the cost mentioned above. I > believe the main reason expressed by people for this option was "future > proof". > > So, hopefully this gives a summary of the discussion so far. I think there > are basically two ways of finding concensus: > 1. Discuss the rationale a lot more to make either side move. For instance, > discuss the deployment scenarios that require GRE, what is "future proof", > why the extra 4 bytes are an issue for those who chose 1) ...etc > 2. Due to current threads more people might express their opionions. > > I'm not too hopeful with 2) above because most of the people that are > actively involved have commented. Plus it would actually be nice to see 1) > being achieved once in a while! So let's try to do that. > > Hesham > > > > _______________________________________________ > 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 Jun 07 13:00: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 1HwLLz-0000p7-Ee; Thu, 07 Jun 2007 13:00:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwLLx-0000ov-G1; Thu, 07 Jun 2007 13:00:53 -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 1HwLLt-0006ZH-V6; Thu, 07 Jun 2007 13:00:53 -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 l57H0Son028355; Thu, 7 Jun 2007 20:00:48 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 20:00:34 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 12:00:32 -0500 Received: from 172.19.244.148 ([172.19.244.148]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 7 Jun 2007 17:00:31 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 07 Jun 2007 12:00:41 -0500 Subject: Re: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 From: Basavaraj Patil To: ext Jari Arkko Message-ID: Thread-Topic: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93 Thread-Index: AcepJWEFn1v9MBUYEdyT2wARJNUNiA== In-Reply-To: <466729AE.3000707@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Jun 2007 17:00:32.0217 (UTC) FILETIME=[5BC99490:01C7A925] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Folks, My apologies for the error in the count as well as having missed several people from the count itself. -Raj On 6/6/07 4:39 PM, "ext Jari Arkko" wrote: > All, > The other observation I would make is that in any > case the conclusions sent by the chairs need to > be accurate. I realize that in some cases a response > is unclear or may change/come late. But the counts > need to be right, and contain people who have > sent their opinions to the list. Basavaraj has already > admitted he made a mistake here, and has promised > to get this right in the future. > > > Jari > > > _______________________________________________ > 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 Jun 07 15:53: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 1HwO2X-0005q3-4a; Thu, 07 Jun 2007 15:53:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwO2V-0005i5-CM; Thu, 07 Jun 2007 15:52:59 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwO2O-0002ri-CJ; Thu, 07 Jun 2007 15:52:59 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2007 12:52:15 -0700 X-IronPort-AV: i="4.16,395,1175497200"; d="scan'208"; a="4504428:sNHT23699466" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l57JqFBq017477; Thu, 7 Jun 2007 12:52:15 -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 l57Jpwtx012295; Thu, 7 Jun 2007 19:52:10 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 12:52:04 -0700 Received: from sgundavewxp ([10.21.80.17]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 12:52:03 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , "'Karen E. Nielsen \(AH/LMD\)'" , "'Alexandru Petrescu'" References: <003901c7a918$05c84a30$1220fea9@amer.cisco.com> <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005> Subject: RE: [Mip6] issue 93 summary Date: Thu, 7 Jun 2007 12:52:03 -0700 Message-ID: <001f01c7a93d$51e882c0$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tA In-Reply-To: <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005> X-OriginalArrivalTime: 07 Jun 2007 19:52:03.0725 (UTC) FILETIME=[520113D0:01C7A93D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2728; t=1181245935; x=1182109935; 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]=20issue=2093=20summary |Sender:=20; bh=G+vkiojpMf2bbnuxXzlerprLipmgs2QXV6y8yUFDFrw=; b=PbKpu1i6MrmLeQVIkwyVemZYtEOA+dDoyTycZVCEwF6dx/DG9ioQNwR2vosdRzRwlfo5Jigo 36TjeBm6bqeJr6/bLuNArc+zK8zQ/cE3a1l9K6BaIhg/Hr7joeKrOALF; 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: bdc523f9a54890b8a30dd6fd53d5d024 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 Hesham: > -----Original Message----- > To answer your questions, it processes them like any other > packet received > using 3948, it assumes it's an IP packet and sends it to the stack for > normal processing. You get a packet, check with version and send it to > ip_input or ip6_input. What's the problem? Incidentally, RFC > 3948 says that > it works whether the inner packet is v4 or v6. Clarification to my earlier email on 3948 about the payload identification. The "next header" field in the ESP header identifies the payload. So, there is a proper payload qualifier in ESP header. The packet inside can be IPv4, IPv6 or GRE protocol types. So, when using ESP header, we dont need the additional 4-byte TLV header, as the protocol type qualifier is present. We need the same qualifier when there is no ESP header, when riding on UDP. So, the point to emphasize is that we are asking for a payload qualifier when using UDP, so that we can send GRE packets. We need this: IPv4-UDP-ESP-GRE-(IPv4, IPv6) (This works) IPv4-UDP-TLV-GRE-(IPv4, IPv6) FYI, Cisco's IPSec implementation supports IPv4-UDP-ESP-GRE-IPv6 and not IPv4-UDP-ESP-IPv6, as of now. Just informational. GRE as a generic transport is supported for IPSec in many implementations today. The mode is very popular, IMO. Comments to your other email: > > Yes. Your suggestion will work ! A *minor* side affect is that, > > if a user does a manual ping to the HA, the HA will not be > > able to differentiate between the user ping to the DSMIP > > ping, always DSMIP process gets all the packets. > > => Well, sure, and it should. Just like a user ping in plain > MIP might get > tunnelled unless you force the use of the CoA. So, the user doing a simple ping to the HA, will never pass. The MIP stack on both the ends will capture that and consider that as a keepalive message. Simple side affect, its ok. No big deal, as long as the user understands why his pings to the HA will never pass. => Yes but you're referencing drafts for PMIP and MIPv4! We know it's needed > for IPv4 networks with overlapping IP addresses and we discussed that before > (and it's typically used by the infrastructure not the host). None of that > applies here. I already said that if for some reason you need it in PMIP > then you can use it before the UDP header. Plus, why are we standardizing > PMIP extensions in this WG? DSMIP must be leveraged by PMIP6, that's Jari's direction, as I understand. So, IMO, we need to make sure, what we design here can serve the general MIP6, NEMO and PMIP6 requirements. But, I agree, GRE may not be required for a normal MIP6 tunnel. Regards Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 07 17:18: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 1HwPNP-0005Mb-Oo; Thu, 07 Jun 2007 17:18:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPNO-0005LP-6A for mip6@ietf.org; Thu, 07 Jun 2007 17:18:38 -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 1HwPAl-0002Ub-8K for mip6@ietf.org; Thu, 07 Jun 2007 17:05:36 -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 l57L5MES005096 for ; Fri, 8 Jun 2007 00:05:33 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 00:05:29 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 16:04:57 -0500 Received: from 172.19.244.148 ([172.19.244.148]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 7 Jun 2007 21:04:56 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 07 Jun 2007 16:05:06 -0500 From: Basavaraj Patil To: Mobile IPv6 Mailing List Message-ID: Thread-Topic: IETF69: Soliciting agenda items and time-slot requests for the MIP6 meeting Thread-Index: AcepR4YLxFXojRU6EdyT2wARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Jun 2007 21:04:57.0373 (UTC) FILETIME=[80E6CCD0:01C7A947] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Mip6] IETF69: Soliciting agenda items and time-slot requests for the MIP6 meeting 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 MIP6 WG meeting as per the current agenda is scheduled as follows: MIP6 Session 1 (2 hours) Tuesday, Afternoon Session II 1520-1720 If you need a time-slot to present or discuss an issue at the WG meeting, please send the chairs a request including the following information: 1. I-D information (If it is not a WG doc, please indicate the relevance of the I-D to the charter) 2. Amount of time required In order to make optimal use of the meeting time, it helps if there has been discussion of the I-D on the mailing list prior to the meeting. -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 07 18:10: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 1HwQBa-00017V-Q7; Thu, 07 Jun 2007 18:10:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQBZ-00017Q-J1 for mip6@ietf.org; Thu, 07 Jun 2007 18:10:29 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwQBY-00011b-8i for mip6@ietf.org; Thu, 07 Jun 2007 18:10: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 l57MAPA23478; Thu, 7 Jun 2007 22:10: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] IETF69: Soliciting agenda items and time-slot requests for the MIP6 meeting Date: Thu, 7 Jun 2007 17:10:22 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114C9029E@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] IETF69: Soliciting agenda items and time-slot requests for the MIP6 meeting Thread-Index: AcepR4YLxFXojRU6EdyT2wARJNUNiAAAgByw References: From: "Ahmad Muhanna" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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, May I request a 20 minute slot for presenting/discussing the Binding Revocation for IPv6 Mobility. There has been a good amount of discussion related to this topic/draft on the wg mailing list:=20 http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revocatio n-01.txt=20 Currently HA does not have any semantics for notifying the mobile node of the mobile node's binding termination. This specification defines the mechanism for achieving this which, in general, is applicable to MIPv6 and its general extension protocols such as PMIPv6.=20 Many thanks in advance. Regards, Ahmad =20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Thursday, June 07, 2007 4:05 PM > To: Mobile IPv6 Mailing List > Subject: [Mip6] IETF69: Soliciting agenda items and time-slot=20 > requests for the MIP6 meeting >=20 >=20 > Hello, >=20 > The MIP6 WG meeting as per the current agenda is scheduled as follows: > MIP6 Session 1 (2 hours) > Tuesday, Afternoon Session II 1520-1720 >=20 > If you need a time-slot to present or discuss an issue at the=20 > WG meeting, please send the chairs a request including the=20 > following information: >=20 > 1. I-D information (If it is not a WG doc, please indicate=20 > the relevance of the I-D to the charter) 2. Amount of time required >=20 >=20 > In order to make optimal use of the meeting time, it helps if=20 > there has been discussion of the I-D on the mailing list=20 > prior to the meeting. >=20 > -Chairs >=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 Jun 07 19:30: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 1HwRQu-000414-Vx; Thu, 07 Jun 2007 19:30:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwRQt-00040x-VG for mip6@ietf.org; Thu, 07 Jun 2007 19:30:23 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwRQt-0002d2-KK for mip6@ietf.org; Thu, 07 Jun 2007 19:30:23 -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] I-D ACTION:draft-ietf-mip6-bootstrapping-split-05.txt Date: Thu, 7 Jun 2007 16:30:22 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-split-05.txt thread-index: AceGaaQ59wzxs9kOQLyvd8I/wU3DuAAAKbfwBweF37ABtKfhsA== References: <1FEB9B9F2EC38343955D02B2AE86AACB1C5DD8@lan-ex-02.panasonic.de> From: "Vijay Devarapalli" To: "Kilian Weniger" , "Giaretta, Gerardo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: mip6@ietf.org, James Kempf 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 Kilian, I am cc'ing the MIP6 mailing list.=20 > -----Original Message----- > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com]=20 > Sent: Wednesday, May 30, 2007 12:24 AM > To: Giaretta, Gerardo; Vijay Devarapalli > Cc: Jari Arkko; James Kempf > Subject: (offlist) [Mip6] I-D=20 > ACTION:draft-ietf-mip6-bootstrapping-split-05.txt=20 >=20 > Hi, >=20 > as discussed with Jari, the text about location privacy in section 9.1 > of bootstrapping-split needs some slight modifications. The reason is > that it references bootstrapping-integrated-dhc for more details, but > the related text with details has recently been removed from > bootstrapping-integrated-dhc.=20 I missed this discussion. Why was it removed from the bootstrapping-integrated-dhc draft? > I just noticed that these modifications were not made in the new = version > draft-ietf-mip6-bootstrapping-split-05.txt. For the suggested text, > please see below. >=20 > The current text in draft-ietf-mip6-bootstrapping-split-05.txt only = says > that using a local HA may set up the potential to compromise MN's > location privacy. It doesn't say why (because local HoA contains > location information) and how (if that HoA is disclosed to untrusted > nodes, e.g., by updating DNS) and what the MN can do against this = (don't > reveal local HoA, e.g., don't do DNS update). This was all explained = in > the related (now removed) text in the security considerations section = of > bootstrapping-integrated-dhc. This must be explained, IMO. One more > sentence in section 9.1 of bootstrapping-split (instered after first > sentence of second last paragraph) may already be enough, e.g.,=20 >=20 > "A home address anchored at such home agent contains some information > about the topological location of the mobile node. Consequently, a > mobile node requiring location privacy should not disclose this home > address to nodes that are not authorized to learn the mobile node's > location, e.g., by updating DNS with the new home address."=20 >=20 > Furthermore, the text refers to bootstrapping-integrated-dhc for > details. This reference has to be removed. >=20 > With these changes, the second last paragraph text in section 9.1 in > bootstrapping-split would then be as follows: >=20 > "Finally notice that assignment of an home agent from the serving=20 > network access provider's (local home agent) or a home agent from=20 > a nearby network (nearby home agent) may set up the potential to=20 > compromise a mobile node's location privacy. A home address=20 > anchored at such home agent contains some information about the=20 > topological location of the mobile node. Consequently, a mobile=20 > node requiring location privacy should not disclose this home=20 > address to nodes that are not authorized to learn the mobile=20 > node's location, e.g., by updating DNS with the new home address." This sounds good to me. Modified the text. I will submit revision=20 6 if there are no other comments on this text. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 07 20:27: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 1HwSJp-0004QE-Aw; Thu, 07 Jun 2007 20:27:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwSJo-0004Q6-DI; Thu, 07 Jun 2007 20:27:08 -0400 Received: from omta04ps.mx.bigpond.com ([144.140.83.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwSJn-0003Sf-UL; Thu, 07 Jun 2007 20:27:08 -0400 Received: from oaamta04ps.mx.bigpond.com ([124.191.178.123]) by omta04ps.mx.bigpond.com with ESMTP id <20070608002700.MZES15631.omta04ps.mx.bigpond.com@oaamta04ps.mx.bigpond.com>; Fri, 8 Jun 2007 00:27:00 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta04ps.mx.bigpond.com with ESMTP id <20070608002659.ZHXH20226.oaamta04ps.mx.bigpond.com@PC20005>; Fri, 8 Jun 2007 00:26:59 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , "'Karen E. Nielsen \(AH/LMD\)'" , "'Alexandru Petrescu'" Subject: RE: [Mip6] issue 93 summary Date: Fri, 8 Jun 2007 10:26:55 +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 In-Reply-To: <001f01c7a93d$51e882c0$1220fea9@amer.cisco.com> Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OA= Message-Id: <20070608002659.ZHXH20226.oaamta04ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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 > Clarification to my earlier email on 3948 about the payload > identification. > > The "next header" field in the ESP header identifies the payload. => Ok, so we can't have TLV following that. > So, there is a proper payload qualifier in ESP header. The packet > inside can be IPv4, IPv6 or GRE protocol types. So, when using > ESP header, we dont need the additional 4-byte TLV header, as > the protocol type qualifier is present. => Right, we don't need it and we can't have it anyway. > Comments to your other email: > > > > Yes. Your suggestion will work ! A *minor* side affect is that, > > > if a user does a manual ping to the HA, the HA will not be > > > able to differentiate between the user ping to the DSMIP > > > ping, always DSMIP process gets all the packets. > > > > => Well, sure, and it should. Just like a user ping in plain > > MIP might get > > tunnelled unless you force the use of the CoA. > > So, the user doing a simple ping to the HA, will never pass. > The MIP stack on both the ends will capture that and consider > that as a keepalive message. => I don't know why you think the MIP stack has to capture it. This is getting into a side issue but the basic point is that it's done for the NAT, so it can be processed like any normal ping. If you get too uncomfortable with this there are many other ways of solving it, like DO option...etc. So let's not use this point as a justification for an additional header. > => Yes but you're referencing drafts for PMIP and MIPv4! We > know it's needed > > for IPv4 networks with overlapping IP addresses and we > discussed that > before > > (and it's typically used by the infrastructure not the > host). None of that > > applies here. I already said that if for some reason you > need it in PMIP > > then you can use it before the UDP header. Plus, why are > we standardizing > > PMIP extensions in this WG? > > DSMIP must be leveraged by PMIP6, that's Jari's direction, as I > understand. So, IMO, we need to make sure, what we design here > can serve the general MIP6, NEMO and PMIP6 requirements. => Nope. We have requirements from MIP6 and NEMO. Of course it's nice if we can help any other work (including PMIP) if we can, but I think it's wrong to do that at the cost of making the base spec worse for its primary users. If PMIP needs extensions (and it does in other cases) then it can extend those solutions for its own use and still reference this work. We shouldn't burden the base for the case of PMIP, especially when PMIP was never the main user of this work. But, I > agree, GRE may not be required for a normal MIP6 tunnel. => Great. So I think at least we're making progress in understanding where this is perceived to be needed. The question is whether it needs to be done here or in NETLMM where the beneficiary is. I don't think we should be addressing it here. Hesham > > > Regards > Sri > > > > > > > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 07 21:39: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 1HwTPe-0004ew-Gk; Thu, 07 Jun 2007 21:37:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwTPb-0004X1-2P; Thu, 07 Jun 2007 21:37:11 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwTCs-0003yI-8Q; Thu, 07 Jun 2007 21:24:04 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 07 Jun 2007 18:24:01 -0700 X-IronPort-AV: i="4.16,397,1175497200"; d="scan'208"; a="160838784:sNHT48351987" 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 l581O14f015105; Thu, 7 Jun 2007 18:24:01 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l581O020027140; Fri, 8 Jun 2007 01:24:01 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, 7 Jun 2007 18:24:00 -0700 Received: from sgundavewxp ([10.21.80.17]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 18:24:00 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , "'Karen E. Nielsen \(AH/LMD\)'" , "'Alexandru Petrescu'" References: <001f01c7a93d$51e882c0$1220fea9@amer.cisco.com> <20070608002659.ZHXH20226.oaamta04ps.mx.bigpond.com@PC20005> Subject: RE: [Mip6] issue 93 summary Date: Thu, 7 Jun 2007 18:24:05 -0700 Message-ID: <000601c7a96b$b46ebee0$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <20070608002659.ZHXH20226.oaamta04ps.mx.bigpond.com@PC20005> Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgA== X-OriginalArrivalTime: 08 Jun 2007 01:24:00.0432 (UTC) FILETIME=[B1496300:01C7A96B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3216; t=1181265841; x=1182129841; 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[Mip6]=20issue=2093=20summary |Sender:=20; bh=wigCp7IpxYo0C0a9JXQU6bIn/3AXchiFbQiu8eI4eow=; b=rD+9rDYehtLxmm9lGHRK2eQSBycnCLZc5jF8NI8KQrhh9WTy8GQ4KF1bSVhiHe+gfFJU9W9M v3SCRJCz3asHcA3+K4rifGNDo9A1egZr1+nCczUI0mFXactRyZDJiFfx8ZAeMMA8agN9InWVQE WYS1tocP6A4KB7OgXzF6ZoEhY=; 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: 73734d43604d52d23b3eba644a169745 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 Hi Hesham > > So, there is a proper payload qualifier in ESP header. The packet > > inside can be IPv4, IPv6 or GRE protocol types. So, when using > > ESP header, we dont need the additional 4-byte TLV header, as > > the protocol type qualifier is present. > > => Right, we don't need it and we can't have it anyway. No. We can still have TLV header. But, I'm saying we have a protocol qualifier. I thought, it might be better to avoid atleast for ESP, but, Vijay was suggesting why not have it consistently for all modes ESP or non-ESP modes. This is how the implementation will work: I define tunnel interface with the encap mode of IPv4-UDP-TLV. Now, I apply crypto policy on this interface. All packets GRE, IPv4, IPv6 packets when sent through this interface, will get hit the crypto policy and get the ESP header. As the packets are routed, the tunnel interface will apply the IPv4-UDP-TLV header. For incomming packets, the packets will match the tunnel interface, crypto policy check will remove the ESP header and identify the payloads using the payload qualifier in the "next header" field of the ESP header. This is one way of implementation. With ESP, TLV heeader points to ESP: IPv4-UDP {TLV {ESP (IPv4, IPv6)}} Without ESP, TLV header points to GRE: IPv4-UDP {TLV {GRE (IPv4, IPv6)}} Like I said, we can get some input from the IPSec folks on this, if you disagree with this. We can also avoid TLV header all together, when using ESP. We can carry all protocol types. > > > > DSMIP must be leveraged by PMIP6, that's Jari's direction, as I > > understand. So, IMO, we need to make sure, what we design here > > can serve the general MIP6, NEMO and PMIP6 requirements. > > => Nope. We have requirements from MIP6 and NEMO. Of course > it's nice if we > can help any other work (including PMIP) if we can, but I > think it's wrong > to do that at the cost of making the base spec worse for its > primary users. > If PMIP needs extensions (and it does in other cases) then it > can extend > those solutions for its own use and still reference this > work. We shouldn't > burden the base for the case of PMIP, especially when PMIP > was never the > main user of this work. > > But, I > > agree, GRE may not be required for a normal MIP6 tunnel. > > => Great. So I think at least we're making progress in > understanding where > this is perceived to be needed. The question is whether it > needs to be done > here or in NETLMM where the beneficiary is. I don't think we should be > addressing it here. I think, we can certainly avoid GRE in DSMIP, if we really want to ignore that requirement. There are valid use cases that are there for NETLMM, MIP6 and NEMO, we can solve with a tiny header. As Yoshi pointed out, if some one wants to tunnel legacy IPX or other traffic from the MN to home network, GRE is required. Same thing for routing legacy protocol traffic from a network behind mobile router to the home network. We already talked about the NETLMM requirement. I do not think this 4-byte header will make the "base spec worse", it really addresses all these usecases. Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 07 21:59:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwTl1-0000pM-UY; Thu, 07 Jun 2007 21:59:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwTl0-0000p8-1i; Thu, 07 Jun 2007 21:59:18 -0400 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwTkw-00066G-Ct; Thu, 07 Jun 2007 21:59:18 -0400 Received: from oaamta06ps.mx.bigpond.com ([124.191.178.123]) by omta01ps.mx.bigpond.com with ESMTP id <20070608015911.WEOJ19666.omta01ps.mx.bigpond.com@oaamta06ps.mx.bigpond.com>; Fri, 8 Jun 2007 01:59:11 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta06ps.mx.bigpond.com with ESMTP id <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005>; Fri, 8 Jun 2007 01:59:11 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , "'Karen E. Nielsen \(AH/LMD\)'" , "'Alexandru Petrescu'" Subject: RE: [Mip6] issue 93 summary Date: Fri, 8 Jun 2007 11:59:06 +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 In-Reply-To: <000601c7a96b$b46ebee0$1220fea9@amer.cisco.com> Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3A Message-Id: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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 > > => Right, we don't need it and we can't have it anyway. > > No. We can still have TLV header. But, I'm saying we have a > protocol qualifier. I thought, it might be better to avoid > atleast for ESP, but, Vijay was suggesting why not have it > consistently for all modes ESP or non-ESP modes. This is > how the implementation will work: > > I define tunnel interface with the encap mode of IPv4-UDP-TLV. > Now, I apply crypto policy on this interface. All packets > GRE, IPv4, IPv6 packets when sent through this interface, will > get hit the crypto policy and get the ESP header. As the packets > are routed, the tunnel interface will apply the IPv4-UDP-TLV > header. For incomming packets, the packets will match the > tunnel interface, crypto policy check will remove the ESP > header and identify the payloads using the payload qualifier > in the "next header" field of the ESP header. This is one > way of implementation. > > With ESP, TLV heeader points to ESP: > IPv4-UDP {TLV {ESP (IPv4, IPv6)}} => Do you agree that this is not 3948? The reason we opened this issue was Karen's question about how we'd use 3948 which defines UDP ESP encapsulation. If you run this format on port 4500 then it obviously won't work. Do you also agree now (given your earlier email) that this is only an issue for option 3 and not 2 and 1? > Like I said, we can get some input from the IPSec folks > on this, if you disagree with this. => I don't understand what input you are seeking, this is a different format from the RFC so if you run it on the same port with an implementation of that RFC then it won't work. What am I missing? > > We can also avoid TLV header all together, when using ESP. > We can carry all protocol types. => I think we'll have to. I don't get this "either or" description. Also adding and removing the TLV field based on whether ESP is used or not doesn't seem to be a good way of doing things because it introduces a dependency between the mobility implementation and the way IPsec is being used. > > => Nope. We have requirements from MIP6 and NEMO. Of course > > it's nice if we > > can help any other work (including PMIP) if we can, but I > > think it's wrong > > to do that at the cost of making the base spec worse for its > > primary users. > > If PMIP needs extensions (and it does in other cases) then it > > can extend > > those solutions for its own use and still reference this > > work. We shouldn't > > burden the base for the case of PMIP, especially when PMIP > > was never the > > main user of this work. > > > > But, I > > > agree, GRE may not be required for a normal MIP6 tunnel. > > > > => Great. So I think at least we're making progress in > > understanding where > > this is perceived to be needed. The question is whether it > > needs to be done > > here or in NETLMM where the beneficiary is. I don't think > we should be > > addressing it here. > > > I think, we can certainly avoid GRE in DSMIP, if we really want > to ignore that requirement. There are valid use cases that are > there for NETLMM, MIP6 and NEMO, we can solve with a tiny header. > As Yoshi pointed out, if some one wants to tunnel legacy IPX > or other traffic from the MN to home network, GRE is required. => You mean you can't carry IPX in IP using proto 111? If a node does not implement IP at all then we're not talking about an MN. If the MR want to tunnel IPX in IP then that would work too. I understand you might prefer GRE, but there is a difference between a MUST and a MAY type goal. A MAY type goal need not be in the base and force everyone else to use it. A MUST goal has to be in the base. I'm a bit sceptical about unexplained scenarios that come piecemeal. If you have a scenario in mind where this is needed for the MR/MN then please write it down. I find it difficult to keep up with the discussion when each email contradicts the one before it. In the last email you said you wanted this for PMIP and MIPv6 didn't need it. Now it's a different story. It's hard for me to discuss things this way. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 07 22:15: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 1HwU0C-0005Yi-Cn; Thu, 07 Jun 2007 22:15:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwU09-0005Xn-D6; Thu, 07 Jun 2007 22:14:57 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwU09-0001DU-24; Thu, 07 Jun 2007 22:14:57 -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] issue 93 summary Date: Thu, 7 Jun 2007 19:14:55 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] issue 93 summary thread-index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3AAAFJPuA= References: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> From: "Vijay Devarapalli" To: "Hesham Soliman" , "Sri Gundavelli" , "Karen E. Nielsen \(AH/LMD\)" , "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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 > > No. We can still have TLV header. But, I'm saying we have a > > protocol qualifier. I thought, it might be better to avoid > > atleast for ESP, but, Vijay was suggesting why not have it > > consistently for all modes ESP or non-ESP modes. This is > > how the implementation will work: > >=20 > > I define tunnel interface with the encap mode of IPv4-UDP-TLV. > > Now, I apply crypto policy on this interface. All packets > > GRE, IPv4, IPv6 packets when sent through this interface, will > > get hit the crypto policy and get the ESP header. As the packets > > are routed, the tunnel interface will apply the IPv4-UDP-TLV > > header. For incomming packets, the packets will match the > > tunnel interface, crypto policy check will remove the ESP > > header and identify the payloads using the payload qualifier > > in the "next header" field of the ESP header. This is one > > way of implementation. > >=20 > > With ESP, TLV heeader points to ESP: > > IPv4-UDP {TLV {ESP (IPv4, IPv6)}} >=20 > =3D> Do you agree that this is not 3948?=20 Yes, it is not 3948. > The reason we opened=20 > this issue was > Karen's question about how we'd use 3948 which defines UDP ESP > encapsulation. If you run this format on port 4500 then it=20 > obviously won't > work. Do you also agree now (given your earlier email) that=20 > this is only an > issue for option 3 and not 2 and 1?=20 Port 4500 will not be used. The UDP port number will point to the TLV and the TLV will say ESP follows. Vijay >=20 >=20 > > Like I said, we can get some input from the IPSec folks > > on this, if you disagree with this. >=20 > =3D> I don't understand what input you are seeking, this is a=20 > different format > from the RFC so if you run it on the same port with an=20 > implementation of > that RFC then it won't work. What am I missing?=20 >=20 > >=20 > > We can also avoid TLV header all together, when using ESP. > > We can carry all protocol types. >=20 > =3D> I think we'll have to. I don't get this "either or"=20 > description. Also > adding and removing the TLV field based on whether ESP is used or not > doesn't seem to be a good way of doing things because it introduces a > dependency between the mobility implementation and the way=20 > IPsec is being > used.=20 >=20 > > > =3D> Nope. We have requirements from MIP6 and NEMO. Of course=20 > > > it's nice if we > > > can help any other work (including PMIP) if we can, but I=20 > > > think it's wrong > > > to do that at the cost of making the base spec worse for its=20 > > > primary users. > > > If PMIP needs extensions (and it does in other cases) then it=20 > > > can extend > > > those solutions for its own use and still reference this=20 > > > work. We shouldn't > > > burden the base for the case of PMIP, especially when PMIP=20 > > > was never the > > > main user of this work. > > >=20 > > > But, I > > > > agree, GRE may not be required for a normal MIP6 tunnel. > > >=20 > > > =3D> Great. So I think at least we're making progress in=20 > > > understanding where > > > this is perceived to be needed. The question is whether it=20 > > > needs to be done > > > here or in NETLMM where the beneficiary is. I don't think=20 > > we should be > > > addressing it here.=20 > >=20 > >=20 > > I think, we can certainly avoid GRE in DSMIP, if we really want > > to ignore that requirement. There are valid use cases that are > > there for NETLMM, MIP6 and NEMO, we can solve with a tiny header. > > As Yoshi pointed out, if some one wants to tunnel legacy IPX > > or other traffic from the MN to home network, GRE is required. >=20 > =3D> You mean you can't carry IPX in IP using proto 111? If a=20 > node does not > implement IP at all then we're not talking about an MN. If=20 > the MR want to > tunnel IPX in IP then that would work too.=20 > I understand you might prefer GRE, but there is a difference=20 > between a MUST > and a MAY type goal. A MAY type goal need not be in the base and force > everyone else to use it. A MUST goal has to be in the base.=20 >=20 > I'm a bit sceptical about unexplained scenarios that come=20 > piecemeal. If you > have a scenario in mind where this is needed for the MR/MN=20 > then please write > it down. I find it difficult to keep up with the discussion=20 > when each email > contradicts the one before it. In the last email you said you=20 > wanted this > for PMIP and MIPv6 didn't need it. Now it's a different=20 > story. It's hard for > me to discuss things this way. >=20 > Hesham >=20 >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 07 22:27: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 1HwUCg-00049i-DX; Thu, 07 Jun 2007 22:27:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwUCe-0003zw-Ss; Thu, 07 Jun 2007 22:27:52 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwUCd-0005O5-GR; Thu, 07 Jun 2007 22:27:52 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 07 Jun 2007 19:27:51 -0700 X-IronPort-AV: i="4.16,397,1175497200"; d="scan'208"; a="160867009:sNHT45962172" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l582RovQ010089; Thu, 7 Jun 2007 19:27:50 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l582Ro07003645; Fri, 8 Jun 2007 02:27:50 GMT Date: Thu, 7 Jun 2007 19:27:50 -0700 (PDT) From: Sri Gundavelli To: Hesham Soliman Subject: RE: [Mip6] issue 93 summary In-Reply-To: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> Message-ID: References: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> 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=2868; t=1181269670; x=1182133670; c=relaxed/simple; s=sjdkim4002; 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]=20issue=2093=20summary |Sender:=20; bh=8E1GOau+IQL0oHPUJrYPJ3isfZ5WlOC1+W3hHh6KBM0=; b=otus8LXfEr9UBZ6iHUV9jMcXy1+7E1IYfd38hvWgkfFR5CrNV/YpYd8ru2y0PkIjR+yZtT1q KPKmLkwpuTfoKaFmBC9NKQ8pzUc5K3dSUXFz5mL3tukUzFeK5IxhPuCi; 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: 92df29fa99cf13e554b84c8374345c17 Cc: nemo@ietf.org, 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 Hesham: On Fri, 8 Jun 2007, Hesham Soliman wrote: > > => Do you agree that this is not 3948? The reason we opened this issue was > Karen's question about how we'd use 3948 which defines UDP ESP > encapsulation. If you run this format on port 4500 then it obviously won't > work. Do you also agree now (given your earlier email) that this is only an > issue for option 3 and not 2 and 1? > I'm again saying, we need a protocol qualifier. That is the title of the issue. We just need a way to identify the payload that is carried in a UDP header. ESP provides that and we dont need the TLV for that mode. When ESP is not there, we need the TLV header. Now, with respect to 3948, if it does not permit TLV on top of UDP, fine. No issue, as we dont need it. If using TLV after UDP is not 3948, as Vijay says, I agree. We dont have to use the TLV for that mode. > > > Like I said, we can get some input from the IPSec folks > > on this, if you disagree with this. > > => I don't understand what input you are seeking, this is a different format > from the RFC so if you run it on the same port with an implementation of > that RFC then it won't work. What am I missing? > > > > > We can also avoid TLV header all together, when using ESP. > > We can carry all protocol types. > > => I think we'll have to. I don't get this "either or" description. Also > adding and removing the TLV field based on whether ESP is used or not > doesn't seem to be a good way of doing things because it introduces a > dependency between the mobility implementation and the way IPsec is being > used. I disagree. We can skip the encap, if its not required. > > => You mean you can't carry IPX in IP using proto 111? If a node does not > implement IP at all then we're not talking about an MN. If the MR want to > tunnel IPX in IP then that would work too. > I understand you might prefer GRE, but there is a difference between a MUST > and a MAY type goal. A MAY type goal need not be in the base and force > everyone else to use it. A MUST goal has to be in the base. > Its not about preference. When using IPv4-UDP tunnel, to carry IPX or other payloads, we need GRE. If there is no NAT, I've no issue, GRE can be carried in IPv4, IPv6. > I'm a bit sceptical about unexplained scenarios that come piecemeal. If you > have a scenario in mind where this is needed for the MR/MN then please write > it down. I find it difficult to keep up with the discussion when each email > contradicts the one before it. In the last email you said you wanted this > for PMIP and MIPv6 didn't need it. Now it's a different story. It's hard for > me to discuss things this way. > Lets hear from others. Its my word against your word. We both know exactly what the requirements are and why this is required not required. Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 08 01:43: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 1HwXFc-00088J-It; Fri, 08 Jun 2007 01:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwXFa-00085s-Pl for mip6@ietf.org; Fri, 08 Jun 2007 01:43:06 -0400 Received: from mail-v031.telia.se ([81.236.34.31] helo=teliasonera.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwXFZ-00060J-Vc for mip6@ietf.org; Fri, 08 Jun 2007 01:43:06 -0400 Received: from sehan001bb.han.telia.se (sehan001bb.han.telia.se [131.115.18.152]) by mail3.han.telia.se (Telia CleanIT) with ESMTP id B6103928000AB64B for ; Fri, 8 Jun 2007 07:43:04 +0200 (CEST) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 07:42:06 +0200 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_01C7A98F.BFA20C25" Date: Fri, 8 Jun 2007 07:42:05 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301F26A01@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-korhonen-mip6-service-02.txt Thread-Index: AcepPU56zCVYT+rkSVa9sbSDpeNePwAR/q4A From: To: X-OriginalArrivalTime: 08 Jun 2007 05:42:06.0467 (UTC) FILETIME=[BFAECD30:01C7A98F] Received-SPF: none X-Spam-Score: 0.2 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [Mip6] FW: I-D ACTION:draft-korhonen-mip6-service-02.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_01C7A98F.BFA20C25 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI.. The I-D on service selection for MIP6 has been revised based on the received comments & feedback. Cheers, Jouni > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Thursday, June 07, 2007 10:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-korhonen-mip6-service-02.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : Service Selection for Mobile IPv6 > Author(s) : J. Korhonen, et al. > Filename : draft-korhonen-mip6-service-02.txt > Pages : 9 > Date : 2007-6-7 > =09 > In some Mobile IPv6 deployments identifying the mobile node or the > mobility service subscriber is not enough to distinguish between > multiple services possibly provisioned to the said mobile node and > its mobility service subscription. A capability to=20 > specify different > services in addition to the mobile node identity can be=20 > leveraged to > provide flexibility for mobility service providers on provisioning >=20 > multiple services to one mobility service subscription. This > document describes a Service Selection Mobility Option for both > conventional Mobile IPv6 or Proxy Mobile IPv6 that is intended to > assist home agents to make a specific service selection for the > mobility service subscription during the binding update procedure. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-korhonen-mip6-service-02.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-korhonen-mip6-service-02.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-korhonen-mip6-service-02.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 ------_=_NextPart_001_01C7A98F.BFA20C25 Content-Type: text/plain; charset="us-ascii"; name="draft-korhonen-mip6-service-02.txt" Content-Transfer-Encoding: base64 Content-Description: draft-korhonen-mip6-service-02.txt Content-Disposition: attachment; filename="draft-korhonen-mip6-service-02.txt" RklMRSBRVUFSQU5USU5FRA0KLS0tLS0tLS0tLS0tLS0tLQ0KDQpBbnRpZ2VuIGZvciBFeGNoYW5n ZSByZW1vdmVkIGRyYWZ0LWtvcmhvbmVuLW1pcDYtc2VydmljZS0wMi5VUkwgc2luY2UgaXQNCndh cyBmb3VuZCB0byBtYXRjaCB0aGUgRklMRSBGSUxURVI9IHVubmFtZWQ6ICoudXJsIGZpbGUgZmls dGVyLg0K ------_=_NextPart_001_01C7A98F.BFA20C25 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_01C7A98F.BFA20C25-- From mip6-bounces@ietf.org Fri Jun 08 03:03: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 1HwYUr-0006Pd-GL; Fri, 08 Jun 2007 03:02:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYUo-0006PL-Hw; Fri, 08 Jun 2007 03:02:54 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwYUm-0001gs-Su; Fri, 08 Jun 2007 03:02:54 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 34DBB2166C; Fri, 8 Jun 2007 09:02:52 +0200 (CEST) X-AuditID: c1b4fb3e-b01efbb0000061ca-ab-4668ff1c9eb4 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 04C4C2166B; Fri, 8 Jun 2007 09:02:52 +0200 (CEST) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 09:02:51 +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] issue 93 summary Date: Fri, 8 Jun 2007 09:02:47 +0200 Message-ID: In-Reply-To: <004001c7a91b$fc2d0b10$1220fea9@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] issue 93 summary Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAAPb+gACAoi8A= References: <003901c7a918$05c84a30$1220fea9@amer.cisco.com> <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005> <004001c7a91b$fc2d0b10$1220fea9@amer.cisco.com> From: "Karen E. Nielsen (AH/LMD)" To: "Sri Gundavelli" , "Hesham Soliman" , "Alexandru Petrescu" X-OriginalArrivalTime: 08 Jun 2007 07:02:51.0822 (UTC) FILETIME=[07BD4CE0:01C7A99B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Hi, Our (Ericsson) implementation of 3948 supports IPv6 in UPD ESP IPv4 tunnel. BR, Karen=20 > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: 7. juni 2007 17:53 > To: 'Hesham Soliman'; Karen E. Nielsen (AH/LMD); 'Alexandru Petrescu' > Cc: nemo@ietf.org; mip6@ietf.org > Subject: RE: [Mip6] issue 93 summary >=20 > =20 > > > > > > Ok. If there is no TLV header, how does the IPSec=20 > process after >=20 > > decap, demux the packets ? Will it look in the version field > as=20 > > DSMIP ? How does it know, if it needs to feed the packet > to the=20 > > IPv4 forwarding engine or IPv6 forwarding engine ? > >=20 > > =3D> There is not much listening going on here obviously, my=20 > questions=20 > > reamin unanswered.... >=20 > No. I'm :) My comment is that, the issue is the same for both. > The issue exists and I already agreed to it. Either case, the=20 > IPSec process has to parse either the version field of the=20 > packet or the TLV header and I dont believe any=20 > implementations do either of them today. >=20 > > To answer your questions, it processes them like any other packet=20 > > received using 3948, it assumes it's an IP packet and sends=20 > it to the=20 > > stack for normal processing. You get a packet, check with=20 > version and=20 > > send it to ip_input or ip6_input. What's the problem? Incidentally,=20 > > RFC >=20 > > 3948 says that > > it works whether the inner packet is v4 or v6. > >=20 >=20 > From what I interpret from 3948, the mechanism of UDP=20 > transport can be used when the outer header and the contained=20 > header are both either IPv4 or IPv6. It did not state that=20 > the IPSec process has to look in the version field and do the=20 > demux to ip_input or ipv6_input. So, it did not talk about a=20 > scenario where the payload is IPv6 and the transport is IPv4.=20 > If we can get this clarified from the IPSec guys, that will=20 > be good. If 3948 can support IPv4, > IPv6 payloads in an IPv4-UDP-ESP, then the issue exists is=20 > not applicable to option #1. >=20 > Sri >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 08 03:14: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 1HwYgQ-0000Dd-6A; Fri, 08 Jun 2007 03:14:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYgO-0000DQ-P0; Fri, 08 Jun 2007 03:14:52 -0400 Received: from netcore.fi ([193.94.160.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HwYgM-0007iQ-6W; Fri, 08 Jun 2007 03:14:52 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l587EYc4007889; Fri, 8 Jun 2007 10:14:34 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l587EYEr007886; Fri, 8 Jun 2007 10:14:34 +0300 Date: Fri, 8 Jun 2007 10:14:34 +0300 (EEST) From: Pekka Savola To: Hesham Soliman Subject: RE: [Mip6] issue 93 summary - IKE/IPsec In-Reply-To: <20070607083314.UIHJ22348.oaamta03ps.mx.bigpond.com@PC20005> Message-ID: References: <20070607083314.UIHJ22348.oaamta03ps.mx.bigpond.com@PC20005> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.3/3377/Thu Jun 7 23:20:29 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 On Thu, 7 Jun 2007, Hesham Soliman wrote: > Good question. I don't know actually. Transport ESP on the outer header is > obviously not a good idea. Transport ESP on the inner header is obviously > possible. It doesn't seem like UDP encapsulated ESP as per 3948 is possible. > Anyone else has a comment on this? FWIW, when we were writing RFC 4891 ("Using IPsec to Secure IPv6-in-IPv4 Tunnels") Mohan realized that the same issues we were seeing (that were specific to "IKE runs on v4, but tunnel is v6" scenario; converse IP versions is also true) would likely come up with DS-MIP effort as well. This significantly affected our recommendation to use transport mode. RFC 4891 provides some discussion and references on this issue. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 08 03: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 1HwZCv-00086R-19; Fri, 08 Jun 2007 03:48:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZCt-00086I-W2; Fri, 08 Jun 2007 03:48:27 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwZCs-0007EU-70; Fri, 08 Jun 2007 03:48:27 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 68F7B21663; Fri, 8 Jun 2007 09:48:25 +0200 (CEST) X-AuditID: c1b4fb3e-af1edbb0000061ca-bb-466909c94373 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3834B20539; Fri, 8 Jun 2007 09:48:25 +0200 (CEST) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 09:48:24 +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] issue 93 summary Date: Fri, 8 Jun 2007 09:48:20 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] issue 93 summary Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3AAAFJPuAACqQx0A== References: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> From: "Karen E. Nielsen (AH/LMD)" To: "Vijay Devarapalli" , "Hesham Soliman" , "Sri Gundavelli" , "Alexandru Petrescu" X-OriginalArrivalTime: 08 Jun 2007 07:48:24.0931 (UTC) FILETIME=[64CCA330:01C7A9A1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 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 Hi, How do you envisage to negotiate the ESP SA for=20 IPv4-UDP {TLV {ESP (IPv4, IPv6)}} - ?? - and should IP Sec now be made to understand Ipv4 UDP TVL ESP encapsulation - Or how do you intend to trick IPSec to respectively decrypt and extract and encrypt and insert the ESP header ? In our "fast" IP stack implementation we use 4500 UDP port number scanning to intercept UDP ESP packets for IPSec processing. Option 2 with a specified port for IPv4/IPv6 would be a straightforward extension of this. Option 1 and Option 3 both require scanning of the UDP payload for ALL UDP packets. As a starting point this does not seem very nice. Karen=20 > -----Original Message----- > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com]=20 > Sent: 8. juni 2007 04:15 > To: Hesham Soliman; Sri Gundavelli; Karen E. Nielsen=20 > (AH/LMD); Alexandru Petrescu > Cc: nemo@ietf.org; mip6@ietf.org > Subject: RE: [nemo] RE: [Mip6] issue 93 summary >=20 > > > No. We can still have TLV header. But, I'm saying we have a >=20 > > protocol qualifier. I thought, it might be better to avoid =20 > > atleast=20 > > for ESP, but, Vijay was suggesting why not have it >=20 > consistently for=20 > > all modes ESP or non-ESP modes. This is > how the=20 > implementation will=20 > > work: > > > > > > I define tunnel interface with the encap mode of IPv4-UDP-TLV. > > > Now, I apply crypto policy on this interface. All=20 > packets > GRE,=20 > > IPv4, IPv6 packets when sent through this interface, will =20 > > get hit=20 > > the crypto policy and get the ESP header. As the packets > are=20 > > routed, the tunnel interface will apply the IPv4-UDP-TLV >=20 > header. =20 > > For incomming packets, the packets will match the > tunnel=20 > interface,=20 > > crypto policy check will remove the ESP > header and identify the=20 > > payloads using the payload qualifier > in the "next=20 > header" field of=20 > > the ESP header. This is one > way of implementation. > > > > > > With ESP, TLV heeader points to ESP: > > > IPv4-UDP {TLV {ESP (IPv4, IPv6)}} > >=20 > > =3D> Do you agree that this is not 3948?=20 >=20 > Yes, it is not 3948. >=20 > > The reason we opened > > this issue was > > Karen's question about how we'd use 3948 which defines UDP ESP=20 > > encapsulation. If you run this format on port 4500 then it=20 > obviously=20 > > won't work. Do you also agree now (given your earlier=20 > email) that this=20 > > is only an issue for option 3 and not 2 and 1? >=20 > Port 4500 will not be used. The UDP port number will point to=20 > the TLV and the TLV will say ESP follows. >=20 > Vijay >=20 > >=20 > >=20 > > > Like I said, we can get some input from the IPSec folks =20 > > on this,=20 > > if you disagree with this. > >=20 > > =3D> I don't understand what input you are seeking, this is a=20 > different=20 > > format from the RFC so if you run it on the same port with an=20 > > implementation of that RFC then it won't work. What am I missing? > >=20 > > > > > > We can also avoid TLV header all together, when using ESP. > > > We can carry all protocol types. > >=20 > > =3D> I think we'll have to. I don't get this "either or"=20 > > description. Also > > adding and removing the TLV field based on whether ESP is=20 > used or not=20 > > doesn't seem to be a good way of doing things because it=20 > introduces a=20 > > dependency between the mobility implementation and the way IPsec is=20 > > being used. > >=20 > > > > =3D> Nope. We have requirements from MIP6 and NEMO. Of=20 > course > >=20 > > it's nice if we > > can help any other work (including PMIP) if we=20 > > can, but I > > think it's wrong > > to do that at the=20 > cost of making=20 > > the base spec worse for its > > primary users. > > > > If PMIP needs extensions (and it does in other cases)=20 > then it >=20 > > > can extend > > those solutions for its own use and still=20 > reference=20 > > this > > work. We shouldn't > > burden the base for the case of=20 > > PMIP, especially when PMIP > > was never the > > main=20 > user of this=20 > > work. > > > > > > > > But, I > > > > > agree, GRE may not be required for a normal MIP6 tunnel. > > > > > > > > =3D> Great. So I think at least we're making progress in > >=20 > > understanding where > > this is perceived to be needed.=20 > The question=20 > > is whether it > > needs to be done > > here or in NETLMM=20 > where the=20 > > beneficiary is. I don't think > we should be > >=20 > addressing it here. > > > > > > > > > I think, we can certainly avoid GRE in DSMIP, if we=20 > really want >=20 > > to ignore that requirement. There are valid use cases that are >=20 > > there for NETLMM, MIP6 and NEMO, we can solve with a tiny header. > > > As Yoshi pointed out, if some one wants to tunnel legacy=20 > IPX > or=20 > > other traffic from the MN to home network, GRE is required. > >=20 > > =3D> You mean you can't carry IPX in IP using proto 111? If a=20 > node does=20 > > not implement IP at all then we're not talking about an MN.=20 > If the MR=20 > > want to tunnel IPX in IP then that would work too. > > I understand you might prefer GRE, but there is a=20 > difference between a=20 > > MUST and a MAY type goal. A MAY type goal need not be in=20 > the base and=20 > > force everyone else to use it. A MUST goal has to be in the base. > >=20 > > I'm a bit sceptical about unexplained scenarios that come=20 > piecemeal.=20 > > If you have a scenario in mind where this is needed for the=20 > MR/MN then=20 > > please write it down. I find it difficult to keep up with the=20 > > discussion when each email contradicts the one before it.=20 > In the last=20 > > email you said you wanted this for PMIP and MIPv6 didn't=20 > need it. Now=20 > > it's a different story. It's hard for me to discuss things this way. > >=20 > > Hesham > >=20 > >=20 > >=20 > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 08 07:59: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 1Hwd7Q-0005jk-DR; Fri, 08 Jun 2007 07:59:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwd7P-0005jb-Kb; Fri, 08 Jun 2007 07:59:03 -0400 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwd7O-0008ED-6P; Fri, 08 Jun 2007 07:59:03 -0400 Received: from oaamta01ps.mx.bigpond.com ([124.191.178.123]) by omta01ps.mx.bigpond.com with ESMTP id <20070608115859.XFBK19666.omta01ps.mx.bigpond.com@oaamta01ps.mx.bigpond.com>; Fri, 8 Jun 2007 11:58:59 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta01ps.mx.bigpond.com with ESMTP id <20070608115859.IETK26563.oaamta01ps.mx.bigpond.com@PC20005>; Fri, 8 Jun 2007 11:58:59 +0000 From: "Hesham Soliman" To: "'Pekka Savola'" Subject: RE: [Mip6] issue 93 summary - IKE/IPsec Date: Fri, 8 Jun 2007 21:58:53 +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 In-Reply-To: Thread-Index: AcepnK8Je1WVgNzgS2yG/nxV+jOwtAAJ6mZw Message-Id: <20070608115859.IETK26563.oaamta01ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Thanks for the pointer Pekka, it's good to know. I'll take a look. Hesham > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Friday, June 08, 2007 5:15 PM > To: Hesham Soliman > Cc: 'Karen E. Nielsen (AH/LMD)'; mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] issue 93 summary - IKE/IPsec > > On Thu, 7 Jun 2007, Hesham Soliman wrote: > > Good question. I don't know actually. Transport ESP on the > outer header is > > obviously not a good idea. Transport ESP on the inner > header is obviously > > possible. It doesn't seem like UDP encapsulated ESP as per > 3948 is possible. > > Anyone else has a comment on this? > > FWIW, when we were writing RFC 4891 ("Using IPsec to Secure > IPv6-in-IPv4 Tunnels") Mohan realized that the same issues we were > seeing (that were specific to "IKE runs on v4, but tunnel is v6" > scenario; converse IP versions is also true) would likely > come up with > DS-MIP effort as well. This significantly affected our > recommendation > to use transport mode. > > RFC 4891 provides some discussion and references on this issue. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 08 08:03: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 1HwdBN-0001KF-9b; Fri, 08 Jun 2007 08:03:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdBL-0001AN-MY; Fri, 08 Jun 2007 08:03:07 -0400 Received: from omta03ps.mx.bigpond.com ([144.140.82.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwdBK-0002jX-TR; Fri, 08 Jun 2007 08:03:07 -0400 Received: from oaamta03ps.mx.bigpond.com ([124.191.178.123]) by omta03ps.mx.bigpond.com with ESMTP id <20070608120304.YIVP8709.omta03ps.mx.bigpond.com@oaamta03ps.mx.bigpond.com>; Fri, 8 Jun 2007 12:03:04 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta03ps.mx.bigpond.com with ESMTP id <20070608120303.GMKZ22348.oaamta03ps.mx.bigpond.com@PC20005>; Fri, 8 Jun 2007 12:03:03 +0000 From: "Hesham Soliman" To: "'Karen E. Nielsen \(AH/LMD\)'" , "'Vijay Devarapalli'" , "'Sri Gundavelli'" , "'Alexandru Petrescu'" Subject: RE: [nemo] RE: [Mip6] issue 93 summary Date: Fri, 8 Jun 2007 22:02:57 +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 In-Reply-To: Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3AAAFJPuAACqQx0AAJ4m4g Message-Id: <20070608120303.GMKZ22348.oaamta03ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 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 Hi Karen, > Option 1 and Option 3 both require scanning of the UDP > payload for ALL > UDP packets. => I don't understand why option 1 requires that. You can negotiate the IPsec SA and run over port 4500 with the following format: IPv4 UDP ESP IPv6 ...etc Where do you foresee the need for scanning all UDP packets? I don't think option 3 is applicable to 3948 as I mentioned in other emails. Hesham As a starting point > this does not seem very nice. > > Karen > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com] > > Sent: 8. juni 2007 04:15 > > To: Hesham Soliman; Sri Gundavelli; Karen E. Nielsen > > (AH/LMD); Alexandru Petrescu > > Cc: nemo@ietf.org; mip6@ietf.org > > Subject: RE: [nemo] RE: [Mip6] issue 93 summary > > > > > > No. We can still have TLV header. But, I'm saying we > have a > > > > protocol qualifier. I thought, it might be better to avoid > > > atleast > > > for ESP, but, Vijay was suggesting why not have it > > > consistently for > > > all modes ESP or non-ESP modes. This is > how the > > implementation will > > > work: > > > > > > > > I define tunnel interface with the encap mode of IPv4-UDP-TLV. > > > > Now, I apply crypto policy on this interface. All > > packets > GRE, > > > IPv4, IPv6 packets when sent through this interface, will > > > get hit > > > the crypto policy and get the ESP header. As the packets > are > > > routed, the tunnel interface will apply the IPv4-UDP-TLV > > > header. > > > For incomming packets, the packets will match the > tunnel > > interface, > > > crypto policy check will remove the ESP > header and > identify the > > > payloads using the payload qualifier > in the "next > > header" field of > > > the ESP header. This is one > way of implementation. > > > > > > > > With ESP, TLV heeader points to ESP: > > > > IPv4-UDP {TLV {ESP (IPv4, IPv6)}} > > > > > > => Do you agree that this is not 3948? > > > > Yes, it is not 3948. > > > > > The reason we opened > > > this issue was > > > Karen's question about how we'd use 3948 which defines UDP ESP > > > encapsulation. If you run this format on port 4500 then it > > obviously > > > won't work. Do you also agree now (given your earlier > > email) that this > > > is only an issue for option 3 and not 2 and 1? > > > > Port 4500 will not be used. The UDP port number will point to > > the TLV and the TLV will say ESP follows. > > > > Vijay > > > > > > > > > > > > Like I said, we can get some input from the IPSec folks > > > on this, > > > if you disagree with this. > > > > > > => I don't understand what input you are seeking, this is a > > different > > > format from the RFC so if you run it on the same port with an > > > implementation of that RFC then it won't work. What am I missing? > > > > > > > > > > > We can also avoid TLV header all together, when using ESP. > > > > We can carry all protocol types. > > > > > > => I think we'll have to. I don't get this "either or" > > > description. Also > > > adding and removing the TLV field based on whether ESP is > > used or not > > > doesn't seem to be a good way of doing things because it > > introduces a > > > dependency between the mobility implementation and the > way IPsec is > > > being used. > > > > > > > > => Nope. We have requirements from MIP6 and NEMO. Of > > course > > > > > it's nice if we > > can help any other work (including > PMIP) if we > > > can, but I > > think it's wrong > > to do that at the > > cost of making > > > the base spec worse for its > > primary users. > > > > > If PMIP needs extensions (and it does in other cases) > > then it > > > > > can extend > > those solutions for its own use and still > > reference > > > this > > work. We shouldn't > > burden the base for > the case of > > > PMIP, especially when PMIP > > was never the > > main > > user of this > > > work. > > > > > > > > > > But, I > > > > > > agree, GRE may not be required for a normal MIP6 tunnel. > > > > > > > > > > => Great. So I think at least we're making progress in > > > > > understanding where > > this is perceived to be needed. > > The question > > > is whether it > > needs to be done > > here or in NETLMM > > where the > > > beneficiary is. I don't think > we should be > > > > addressing it here. > > > > > > > > > > > > I think, we can certainly avoid GRE in DSMIP, if we > > really want > > > > to ignore that requirement. There are valid use cases > that are > > > > there for NETLMM, MIP6 and NEMO, we can solve with a tiny header. > > > > As Yoshi pointed out, if some one wants to tunnel legacy > > IPX > or > > > other traffic from the MN to home network, GRE is required. > > > > > > => You mean you can't carry IPX in IP using proto 111? If a > > node does > > > not implement IP at all then we're not talking about an MN. > > If the MR > > > want to tunnel IPX in IP then that would work too. > > > I understand you might prefer GRE, but there is a > > difference between a > > > MUST and a MAY type goal. A MAY type goal need not be in > > the base and > > > force everyone else to use it. A MUST goal has to be in the base. > > > > > > I'm a bit sceptical about unexplained scenarios that come > > piecemeal. > > > If you have a scenario in mind where this is needed for the > > MR/MN then > > > please write it down. I find it difficult to keep up with the > > > discussion when each email contradicts the one before it. > > In the last > > > email you said you wanted this for PMIP and MIPv6 didn't > > need it. Now > > > it's a different story. It's hard for me to discuss > things this way. > > > > > > Hesham > > > > > > > > > > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 08 08:14: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 1HwdMP-0004o8-0t; Fri, 08 Jun 2007 08:14:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdMN-0004kb-UI; Fri, 08 Jun 2007 08:14:31 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwdMM-0006iG-Ij; Fri, 08 Jun 2007 08:14:31 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1181304869!1201997!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 14397 invoked from network); 8 Jun 2007 12:14:29 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-153.messagelabs.com with SMTP; 8 Jun 2007 12:14:29 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l58CETtS018355; Fri, 8 Jun 2007 05:14:29 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l58CESEC005856; Fri, 8 Jun 2007 07:14:28 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l58CEQ4Y005796; Fri, 8 Jun 2007 07:14:26 -0500 (CDT) Message-ID: <4669481C.1050205@gmail.com> Date: Fri, 08 Jun 2007 14:14:20 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Karen E. Nielsen (AH/LMD)" Subject: Re: [Mip6] issue 93 summary References: <003901c7a918$05c84a30$1220fea9@amer.cisco.com> <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005> <004001c7a91b$fc2d0b10$1220fea9@amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000748-0, 07/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 Karen E. Nielsen (AH/LMD) wrote: > Hi, > > Our (Ericsson) implementation of 3948 supports IPv6 in UPD ESP IPv4 > tunnel. For sake of completeness, my implementation of Mobile IPv6 over IPv4 traversing NATs does this for BU/BAck: IPv4 UDP IPv6 AH ESP DO/RH/etc MobilityHader And this for app: IPv4 UDP IPv6 AH ESP DO/RH/etc payload This is not an implementation of DS-MIPv6 however, it's just Mobile IPv6 and NAT traversal. Alex > > BR, Karen > >> -----Original Message----- >> From: Sri Gundavelli [mailto:sgundave@cisco.com] >> Sent: 7. juni 2007 17:53 >> To: 'Hesham Soliman'; Karen E. Nielsen (AH/LMD); 'Alexandru Petrescu' >> Cc: nemo@ietf.org; mip6@ietf.org >> Subject: RE: [Mip6] issue 93 summary >> >> >>> > >>> > Ok. If there is no TLV header, how does the IPSec >> process after > >>> decap, demux the packets ? Will it look in the version field > as >>> DSMIP ? How does it know, if it needs to feed the packet > to the >>> IPv4 forwarding engine or IPv6 forwarding engine ? >>> >>> => There is not much listening going on here obviously, my >> questions >>> reamin unanswered.... >> No. I'm :) My comment is that, the issue is the same for both. >> The issue exists and I already agreed to it. Either case, the >> IPSec process has to parse either the version field of the >> packet or the TLV header and I dont believe any >> implementations do either of them today. >> >>> To answer your questions, it processes them like any other packet >>> received using 3948, it assumes it's an IP packet and sends >> it to the >>> stack for normal processing. You get a packet, check with >> version and >>> send it to ip_input or ip6_input. What's the problem? Incidentally, >>> RFC >>> 3948 says that >>> it works whether the inner packet is v4 or v6. >>> >> From what I interpret from 3948, the mechanism of UDP >> transport can be used when the outer header and the contained >> header are both either IPv4 or IPv6. It did not state that >> the IPSec process has to look in the version field and do the >> demux to ip_input or ipv6_input. So, it did not talk about a >> scenario where the payload is IPv6 and the transport is IPv4. >> If we can get this clarified from the IPSec guys, that will >> be good. If 3948 can support IPv4, >> IPv6 payloads in an IPv4-UDP-ESP, then the issue exists is >> not applicable to option #1. >> >> 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 Fri Jun 08 08:48: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 1Hwdsn-0002jE-Eo; Fri, 08 Jun 2007 08:48:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwdsl-0002j6-W1; Fri, 08 Jun 2007 08:47:59 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwdsl-0002rd-9H; Fri, 08 Jun 2007 08:47:59 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9657D20CAB; Fri, 8 Jun 2007 14:47:58 +0200 (CEST) X-AuditID: c1b4fb3c-a84eabb0000073d5-3b-46694ffef44a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7B43B20B73; Fri, 8 Jun 2007 14:47:58 +0200 (CEST) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 14:47:58 +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] issue 93 summary Date: Fri, 8 Jun 2007 14:47:57 +0200 Message-ID: In-Reply-To: <4669481C.1050205@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] issue 93 summary Thread-Index: AcepxpLO/yDLHgl1Tkyi058VdDmxwgAAHf2w References: <003901c7a918$05c84a30$1220fea9@amer.cisco.com> <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005> <004001c7a91b$fc2d0b10$1220fea9@amer.cisco.com> <4669481C.1050205@gmail.com> From: "Karen E. Nielsen (AH/LMD)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 08 Jun 2007 12:47:58.0018 (UTC) FILETIME=[3D981220:01C7A9CB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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, Just so that we are all clear, the below is ESP IPSec in transport mode and has nothing to do with 3948 ESP UDP tunnel encapsulation, :-). If I understand you correct. Then in your implementation=20 payload data is only protected at the HA-MN by virtue of end to end IPSec protection to CN peer - Right ? BR, Karen > For sake of completeness, my implementation of Mobile IPv6=20 > over IPv4 traversing NATs does this for BU/BAck: >=20 > IPv4 > UDP > IPv6 > AH > ESP > DO/RH/etc > MobilityHader >=20 > And this for app: >=20 > IPv4 > UDP > IPv6 > AH > ESP > DO/RH/etc > payload >=20 > This is not an implementation of DS-MIPv6 however, it's just=20 > Mobile IPv6 > and NAT traversal. >=20 > Alex >=20 > >=20 > > BR, Karen > >=20 > >> -----Original Message----- > >> From: Sri Gundavelli [mailto:sgundave@cisco.com] > >> Sent: 7. juni 2007 17:53 > >> To: 'Hesham Soliman'; Karen E. Nielsen (AH/LMD);=20 > 'Alexandru Petrescu' > >> Cc: nemo@ietf.org; mip6@ietf.org > >> Subject: RE: [Mip6] issue 93 summary > >> > >> =20 > >>> > > >>> > Ok. If there is no TLV header, how does the IPSec > >> process after > > >>> decap, demux the packets ? Will it look in the version=20 > field > as=20 > >>> DSMIP ? How does it know, if it needs to feed the packet > to the > >>> IPv4 forwarding engine or IPv6 forwarding engine ? > >>> > >>> =3D> There is not much listening going on here obviously, my > >> questions > >>> reamin unanswered.... > >> No. I'm :) My comment is that, the issue is the same for both. > >> The issue exists and I already agreed to it. Either case,=20 > the IPSec=20 > >> process has to parse either the version field of the packet or the=20 > >> TLV header and I dont believe any implementations do=20 > either of them=20 > >> today. > >> > >>> To answer your questions, it processes them like any other packet=20 > >>> received using 3948, it assumes it's an IP packet and sends > >> it to the > >>> stack for normal processing. You get a packet, check with > >> version and > >>> send it to ip_input or ip6_input. What's the problem?=20 > Incidentally,=20 > >>> RFC > >>> 3948 says that > >>> it works whether the inner packet is v4 or v6. > >>> > >> From what I interpret from 3948, the mechanism of UDP=20 > transport can=20 > >> be used when the outer header and the contained header are both=20 > >> either IPv4 or IPv6. It did not state that the IPSec=20 > process has to=20 > >> look in the version field and do the demux to ip_input or=20 > ipv6_input.=20 > >> So, it did not talk about a scenario where the payload is IPv6 and=20 > >> the transport is IPv4. > >> If we can get this clarified from the IPSec guys, that=20 > will be good.=20 > >> If 3948 can support IPv4, > >> IPv6 payloads in an IPv4-UDP-ESP, then the issue exists is not=20 > >> applicable to option #1. > >> > >> Sri > >> > >=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 Fri Jun 08 12:37: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 1HwhSh-0004Ah-BT; Fri, 08 Jun 2007 12:37:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwhSg-00042X-0U; Fri, 08 Jun 2007 12:37:18 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwhSf-0002hy-Ko; Fri, 08 Jun 2007 12:37:17 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1181320636!915578!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 15605 invoked from network); 8 Jun 2007 16:37:16 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-12.tower-153.messagelabs.com with SMTP; 8 Jun 2007 16:37:16 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l58GbF42009690; Fri, 8 Jun 2007 09:37:15 -0700 (MST) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l58GbEvT024617; Fri, 8 Jun 2007 11:37:14 -0500 (CDT) Received: from [127.0.0.1] ([10.129.40.175]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l58GbABl024557; Fri, 8 Jun 2007 11:37:11 -0500 (CDT) Message-ID: <466985B6.1060108@gmail.com> Date: Fri, 08 Jun 2007 18:37:10 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Karen E. Nielsen (AH/LMD)" Subject: Re: [Mip6] issue 93 summary References: <003901c7a918$05c84a30$1220fea9@amer.cisco.com> <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005> <004001c7a91b$fc2d0b10$1220fea9@amer.cisco.com> <4669481C.1050205@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000748-0, 07/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: nemo@ietf.org, mip6@ietf.org, Alexandru Petrescu , 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 Karen E. Nielsen (AH/LMD) wrote: > Hi, > > Just so that we are all clear, the below is ESP IPSec in transport > mode and has nothing to do with 3948 ESP UDP tunnel encapsulation, > :-). Right, it's just a way of implementing Mobile IPv6 over IPv4. > If I understand you correct. Then in your implementation payload data > is only protected at the HA-MN by virtue of end to end IPSec > protection to CN peer - Right ? Sorry no IPsec at CN is assumed. The payload is protected by MN and HA with rfc3776. Alex > > BR, Karen > >> For sake of completeness, my implementation of Mobile IPv6 over >> IPv4 traversing NATs does this for BU/BAck: >> >> IPv4 UDP IPv6 AH ESP DO/RH/etc MobilityHader >> >> And this for app: >> >> IPv4 UDP IPv6 AH ESP DO/RH/etc payload >> >> This is not an implementation of DS-MIPv6 however, it's just Mobile >> IPv6 and NAT traversal. >> >> Alex >> >>> BR, Karen >>> >>>> -----Original Message----- From: Sri Gundavelli >>>> [mailto:sgundave@cisco.com] Sent: 7. juni 2007 17:53 To: >>>> 'Hesham Soliman'; Karen E. Nielsen (AH/LMD); >> 'Alexandru Petrescu' >>>> Cc: nemo@ietf.org; mip6@ietf.org Subject: RE: [Mip6] issue 93 >>>> summary >>>> >>>> >>>>>> >>>>>> Ok. If there is no TLV header, how does the IPSec >>>> process after > >>>>> decap, demux the packets ? Will it look in the version >> field > as >>>>> DSMIP ? How does it know, if it needs to feed the packet > >>>>> to the IPv4 forwarding engine or IPv6 forwarding engine ? >>>>> >>>>> => There is not much listening going on here obviously, my >>>> questions >>>>> reamin unanswered.... >>>> No. I'm :) My comment is that, the issue is the same for both. >>>> The issue exists and I already agreed to it. Either case, >> the IPSec >>>> process has to parse either the version field of the packet or >>>> the TLV header and I dont believe any implementations do >> either of them >>>> today. >>>> >>>>> To answer your questions, it processes them like any other >>>>> packet received using 3948, it assumes it's an IP packet and >>>>> sends >>>> it to the >>>>> stack for normal processing. You get a packet, check with >>>> version and >>>>> send it to ip_input or ip6_input. What's the problem? >> Incidentally, >>>>> RFC 3948 says that it works whether the inner packet is v4 or >>>>> v6. >>>>> >>>> From what I interpret from 3948, the mechanism of UDP >> transport can >>>> be used when the outer header and the contained header are both >>>> either IPv4 or IPv6. It did not state that the IPSec >> process has to >>>> look in the version field and do the demux to ip_input or >> ipv6_input. >>>> So, it did not talk about a scenario where the payload is IPv6 >>>> and the transport is IPv4. If we can get this clarified from >>>> the IPSec guys, that >> will be good. >>>> If 3948 can support IPv4, IPv6 payloads in an IPv4-UDP-ESP, >>>> then the issue exists is not applicable to option #1. >>>> >>>> Sri >>>> >> >> ______________________________________________________________________ >> 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 Jun 08 13:07: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 1Hwhw5-0006wA-Vk; Fri, 08 Jun 2007 13:07:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwhw4-0006w3-Sm; Fri, 08 Jun 2007 13:07:40 -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 1Hwhw4-0003Y8-3l; Fri, 08 Jun 2007 13:07:40 -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 l58H7Z8J022561; Fri, 8 Jun 2007 20:07:36 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 20:07:31 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 12:07:28 -0500 Received: from 10.241.58.45 ([10.241.58.45]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 8 Jun 2007 17:07:27 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 08 Jun 2007 12:07:37 -0500 From: Basavaraj Patil To: ext Jari Arkko , ext Mark Townsley , Message-ID: Thread-Topic: Request to progress WG I-D: draft-ietf-mip6-bootstrapping-integrated-04.txt Thread-Index: Acep74NkwcTplhXiEdyT2wARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Jun 2007 17:07:28.0660 (UTC) FILETIME=[7E6B7D40:01C7A9EF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: Gopal Dommety , Mobile IPv6 Mailing List Subject: [Mip6] Request to progress WG I-D: draft-ietf-mip6-bootstrapping-integrated-04.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 Hello, The MIP6 WG I-D: MIP6-bootstrapping for the Integrated Scenario has completed working group last call in March, 07. Intended status for this I-D: Standards track The I-D has been revised based on comments received on the list and comments mailed to the authors. It is ready for AD and IESG review and to be progressed to RFC status. Below is the completed writeup (per RFC4858) as required for WG documents: (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document shepherd: Basavaraj Patil Yes, I have reviewed this version of the I-D and believe it is ready for forwarding to IESG. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed within the MIP6 WG. It was developed by a design team and then subsequently discussed as an open WG document on the mailing list. It has been reviewed by WG members as well as non-WG members. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I believe the document has had sufficient review and by people who understand various aspects other than Mobile IPv6. There is no need to have further review from other areas. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I do not have any concerns or issues with the document. All issues have been addressed in revisions of the document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is WG consensus on this bootstrapping mechanism. Strong consensus comes from a few active WG members as is the case for most documents. The WG I believe understands this document and the need for the solution specified in this I-D. There are no major objections at least to the I-D. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. I have verified the I-D for ID-nits via the tool provided in tools.ietf.org. The I-D does not specify a MIB or media type. Hence no formal review of such aspects in the I-D are required. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? No IANA action is required from this document. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Not applicable. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Mobile IPv6 bootstrapping can be categorized into two primary scenarios, the split scenario and the integrated scenario. In the split scenario, the mobile node's mobility service is authorized by a different service authorizer than the network access authorizer. In the the integrated scenario, the mobile node's mobility service is authorized by the same service authorizer as the network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The design team had some differences regarding the integrated scenario and use of DHCP as a means for bootstrapping. However these issues have subsequently been clarified. The current I-D in a previous version included several DHCP options which are required for bootstrapping. These have now been specified in a separate I-D (draft-ietf-mip6-hiopt-03.txt). This I-D is dependent on the DHCP options specified in the companion MIP6 WG Doc: draft-ietf-mip6-hiopt-03.txt Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? No known implementations of this protocol exist at the current time. However some vendors have indicated plans to implement this specification. This specification is also of interest in other SDOs such as 3GPP2 and WiMAX forum. Acknowledgements to the key reviewers and contributors have been noted. -Raj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 08 13:50: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 1Hwib3-00089j-Cn; Fri, 08 Jun 2007 13:50:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwib2-00089M-3v; Fri, 08 Jun 2007 13:50:00 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwib1-0004Lu-Ik; Fri, 08 Jun 2007 13:50:00 -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] issue 93 summary Date: Fri, 8 Jun 2007 10:49:58 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] issue 93 summary thread-index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3AAAFJPuAACqQx0AAJ4m4gAAwoTCA= References: <20070608120303.GMKZ22348.oaamta03ps.mx.bigpond.com@PC20005> From: "Vijay Devarapalli" To: "Hesham Soliman" , "Karen E. Nielsen \(AH/LMD\)" , "Sri Gundavelli" , "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 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 Hesham,=20 > > Option 1 and Option 3 both require scanning of the UDP=20 > > payload for ALL > > UDP packets.=20 >=20 > =3D> I don't understand why option 1 requires that. You can=20 > negotiate the > IPsec SA and run over port 4500 with the following format: >=20 > IPv4 > UDP > ESP > IPv6 > ...etc This is option 2. The UDP port here will point to 4500, different from the UDP port reserved for DS-MIPv6. Vijay >=20 > Where do you foresee the need for scanning all UDP packets? I=20 > don't think > option 3 is applicable to 3948 as I mentioned in other emails. >=20 > Hesham >=20 > As a starting point > > this does not seem very nice. > >=20 > > Karen=20 > >=20 > > > -----Original Message----- > > > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com]=20 > > > Sent: 8. juni 2007 04:15 > > > To: Hesham Soliman; Sri Gundavelli; Karen E. Nielsen=20 > > > (AH/LMD); Alexandru Petrescu > > > Cc: nemo@ietf.org; mip6@ietf.org > > > Subject: RE: [nemo] RE: [Mip6] issue 93 summary > > >=20 > > > > > No. We can still have TLV header. But, I'm saying we=20 > > have a >=20 > > > > protocol qualifier. I thought, it might be better to avoid =20 > > > > atleast=20 > > > > for ESP, but, Vijay was suggesting why not have it >=20 > > > consistently for=20 > > > > all modes ESP or non-ESP modes. This is > how the=20 > > > implementation will=20 > > > > work: > > > > > > > > > > I define tunnel interface with the encap mode of=20 > IPv4-UDP-TLV. > > > > > Now, I apply crypto policy on this interface. All=20 > > > packets > GRE,=20 > > > > IPv4, IPv6 packets when sent through this interface, will =20 > > > > get hit=20 > > > > the crypto policy and get the ESP header. As the=20 > packets > are=20 > > > > routed, the tunnel interface will apply the IPv4-UDP-TLV >=20 > > > header. =20 > > > > For incomming packets, the packets will match the > tunnel=20 > > > interface,=20 > > > > crypto policy check will remove the ESP > header and=20 > > identify the=20 > > > > payloads using the payload qualifier > in the "next=20 > > > header" field of=20 > > > > the ESP header. This is one > way of implementation. > > > > > > > > > > With ESP, TLV heeader points to ESP: > > > > > IPv4-UDP {TLV {ESP (IPv4, IPv6)}} > > > >=20 > > > > =3D> Do you agree that this is not 3948?=20 > > >=20 > > > Yes, it is not 3948. > > >=20 > > > > The reason we opened > > > > this issue was > > > > Karen's question about how we'd use 3948 which defines UDP ESP=20 > > > > encapsulation. If you run this format on port 4500 then it=20 > > > obviously=20 > > > > won't work. Do you also agree now (given your earlier=20 > > > email) that this=20 > > > > is only an issue for option 3 and not 2 and 1? > > >=20 > > > Port 4500 will not be used. The UDP port number will point to=20 > > > the TLV and the TLV will say ESP follows. > > >=20 > > > Vijay > > >=20 > > > >=20 > > > >=20 > > > > > Like I said, we can get some input from the IPSec folks =20 > > > > on this,=20 > > > > if you disagree with this. > > > >=20 > > > > =3D> I don't understand what input you are seeking, this is a=20 > > > different=20 > > > > format from the RFC so if you run it on the same port with an=20 > > > > implementation of that RFC then it won't work. What am=20 > I missing? > > > >=20 > > > > > > > > > > We can also avoid TLV header all together, when using ESP. > > > > > We can carry all protocol types. > > > >=20 > > > > =3D> I think we'll have to. I don't get this "either or"=20 > > > > description. Also > > > > adding and removing the TLV field based on whether ESP is=20 > > > used or not=20 > > > > doesn't seem to be a good way of doing things because it=20 > > > introduces a=20 > > > > dependency between the mobility implementation and the=20 > > way IPsec is=20 > > > > being used. > > > >=20 > > > > > > =3D> Nope. We have requirements from MIP6 and NEMO. Of=20 > > > course > >=20 > > > > it's nice if we > > can help any other work (including=20 > > PMIP) if we=20 > > > > can, but I > > think it's wrong > > to do that at the=20 > > > cost of making=20 > > > > the base spec worse for its > > primary users. > > > > > > If PMIP needs extensions (and it does in other cases)=20 > > > then it >=20 > > > > > can extend > > those solutions for its own use and still=20 > > > reference=20 > > > > this > > work. We shouldn't > > burden the base for=20 > > the case of=20 > > > > PMIP, especially when PMIP > > was never the > > main=20 > > > user of this=20 > > > > work. > > > > > > > > > > > > But, I > > > > > > > agree, GRE may not be required for a normal=20 > MIP6 tunnel. > > > > > > > > > > > > =3D> Great. So I think at least we're making=20 > progress in > >=20 > > > > understanding where > > this is perceived to be needed.=20 > > > The question=20 > > > > is whether it > > needs to be done > > here or in NETLMM=20 > > > where the=20 > > > > beneficiary is. I don't think > we should be > >=20 > > > addressing it here. > > > > > > > > > > > > > > > I think, we can certainly avoid GRE in DSMIP, if we=20 > > > really want >=20 > > > > to ignore that requirement. There are valid use cases=20 > > that are >=20 > > > > there for NETLMM, MIP6 and NEMO, we can solve with a=20 > tiny header. > > > > > As Yoshi pointed out, if some one wants to tunnel legacy=20 > > > IPX > or=20 > > > > other traffic from the MN to home network, GRE is required. > > > >=20 > > > > =3D> You mean you can't carry IPX in IP using proto 111? If a=20 > > > node does=20 > > > > not implement IP at all then we're not talking about an MN.=20 > > > If the MR=20 > > > > want to tunnel IPX in IP then that would work too. > > > > I understand you might prefer GRE, but there is a=20 > > > difference between a=20 > > > > MUST and a MAY type goal. A MAY type goal need not be in=20 > > > the base and=20 > > > > force everyone else to use it. A MUST goal has to be=20 > in the base. > > > >=20 > > > > I'm a bit sceptical about unexplained scenarios that come=20 > > > piecemeal.=20 > > > > If you have a scenario in mind where this is needed for the=20 > > > MR/MN then=20 > > > > please write it down. I find it difficult to keep up with the=20 > > > > discussion when each email contradicts the one before it.=20 > > > In the last=20 > > > > email you said you wanted this for PMIP and MIPv6 didn't=20 > > > need it. Now=20 > > > > it's a different story. It's hard for me to discuss=20 > > things this way. > > > >=20 > > > > Hesham > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > >=20 > >=20 >=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 From mip6-bounces@ietf.org Fri Jun 08 14:04:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwiow-0001WD-4H; Fri, 08 Jun 2007 14:04:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwiov-0001Vh-5g; Fri, 08 Jun 2007 14:04:21 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwiou-0006Dp-7B; Fri, 08 Jun 2007 14:04: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] issue 93 summary Date: Fri, 8 Jun 2007 11:04:19 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] issue 93 summary thread-index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3AAAFJPuAACqQx0AAWFjcg References: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> From: "Vijay Devarapalli" To: "Karen E. Nielsen \(AH/LMD\)" , "Hesham Soliman" , "Sri Gundavelli" , "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 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 > How do you envisage to negotiate the ESP SA for=20 >=20 > IPv4-UDP {TLV {ESP (IPv4, IPv6)}} - ?? You negotiate as if you are negotiating for NAT traversal. > - and should IP Sec now be made to understand > Ipv4 UDP TVL ESP encapsulation - Or how do you intend to trick > IPSec to respectively decrypt and extract and encrypt and=20 > insert the ESP > header ? The IPsec implementation shouldn't have to insert the TLV. It would be done by Mobile IPv6. (similar to how Mobile IPv6 inserts the=20 home address option after IPsec is done with adding the ESP header). > In our "fast" IP stack implementation we use 4500 UDP port number > scanning to intercept > UDP ESP packets for IPSec processing. > Option 2 with a specified port for IPv4/IPv6 would be a=20 > straightforward > extension of this. > Option 1 and Option 3 both require scanning of the UDP payload for ALL > UDP packets. As a starting point > this does not seem very nice. You don't have to scan for all UDP ports. Your "fast" IP stack implementation, in addition to port 4500, would need to look for=20 the UDP port that points to the TLV and the TLV port/protocol=20 field that identifies ESP. Vijay >=20 > Karen=20 >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com]=20 > > Sent: 8. juni 2007 04:15 > > To: Hesham Soliman; Sri Gundavelli; Karen E. Nielsen=20 > > (AH/LMD); Alexandru Petrescu > > Cc: nemo@ietf.org; mip6@ietf.org > > Subject: RE: [nemo] RE: [Mip6] issue 93 summary > >=20 > > > > No. We can still have TLV header. But, I'm saying we have a >=20 > > > protocol qualifier. I thought, it might be better to avoid =20 > > > atleast=20 > > > for ESP, but, Vijay was suggesting why not have it >=20 > > consistently for=20 > > > all modes ESP or non-ESP modes. This is > how the=20 > > implementation will=20 > > > work: > > > > > > > > I define tunnel interface with the encap mode of IPv4-UDP-TLV. > > > > Now, I apply crypto policy on this interface. All=20 > > packets > GRE,=20 > > > IPv4, IPv6 packets when sent through this interface, will =20 > > > get hit=20 > > > the crypto policy and get the ESP header. As the packets > are=20 > > > routed, the tunnel interface will apply the IPv4-UDP-TLV >=20 > > header. =20 > > > For incomming packets, the packets will match the > tunnel=20 > > interface,=20 > > > crypto policy check will remove the ESP > header and=20 > identify the=20 > > > payloads using the payload qualifier > in the "next=20 > > header" field of=20 > > > the ESP header. This is one > way of implementation. > > > > > > > > With ESP, TLV heeader points to ESP: > > > > IPv4-UDP {TLV {ESP (IPv4, IPv6)}} > > >=20 > > > =3D> Do you agree that this is not 3948?=20 > >=20 > > Yes, it is not 3948. > >=20 > > > The reason we opened > > > this issue was > > > Karen's question about how we'd use 3948 which defines UDP ESP=20 > > > encapsulation. If you run this format on port 4500 then it=20 > > obviously=20 > > > won't work. Do you also agree now (given your earlier=20 > > email) that this=20 > > > is only an issue for option 3 and not 2 and 1? > >=20 > > Port 4500 will not be used. The UDP port number will point to=20 > > the TLV and the TLV will say ESP follows. > >=20 > > Vijay > >=20 > > >=20 > > >=20 > > > > Like I said, we can get some input from the IPSec folks =20 > > > on this,=20 > > > if you disagree with this. > > >=20 > > > =3D> I don't understand what input you are seeking, this is a=20 > > different=20 > > > format from the RFC so if you run it on the same port with an=20 > > > implementation of that RFC then it won't work. What am I missing? > > >=20 > > > > > > > > We can also avoid TLV header all together, when using ESP. > > > > We can carry all protocol types. > > >=20 > > > =3D> I think we'll have to. I don't get this "either or"=20 > > > description. Also > > > adding and removing the TLV field based on whether ESP is=20 > > used or not=20 > > > doesn't seem to be a good way of doing things because it=20 > > introduces a=20 > > > dependency between the mobility implementation and the=20 > way IPsec is=20 > > > being used. > > >=20 > > > > > =3D> Nope. We have requirements from MIP6 and NEMO. Of=20 > > course > >=20 > > > it's nice if we > > can help any other work (including=20 > PMIP) if we=20 > > > can, but I > > think it's wrong > > to do that at the=20 > > cost of making=20 > > > the base spec worse for its > > primary users. > > > > > If PMIP needs extensions (and it does in other cases)=20 > > then it >=20 > > > > can extend > > those solutions for its own use and still=20 > > reference=20 > > > this > > work. We shouldn't > > burden the base for the case of=20 > > > PMIP, especially when PMIP > > was never the > > main=20 > > user of this=20 > > > work. > > > > > > > > > > But, I > > > > > > agree, GRE may not be required for a normal MIP6 tunnel. > > > > > > > > > > =3D> Great. So I think at least we're making progress in > > = > > > understanding where > > this is perceived to be needed.=20 > > The question=20 > > > is whether it > > needs to be done > > here or in NETLMM=20 > > where the=20 > > > beneficiary is. I don't think > we should be > >=20 > > addressing it here. > > > > > > > > > > > > I think, we can certainly avoid GRE in DSMIP, if we=20 > > really want >=20 > > > to ignore that requirement. There are valid use cases that are >=20 > > > there for NETLMM, MIP6 and NEMO, we can solve with a tiny header. > > > > As Yoshi pointed out, if some one wants to tunnel legacy=20 > > IPX > or=20 > > > other traffic from the MN to home network, GRE is required. > > >=20 > > > =3D> You mean you can't carry IPX in IP using proto 111? If a=20 > > node does=20 > > > not implement IP at all then we're not talking about an MN.=20 > > If the MR=20 > > > want to tunnel IPX in IP then that would work too. > > > I understand you might prefer GRE, but there is a=20 > > difference between a=20 > > > MUST and a MAY type goal. A MAY type goal need not be in=20 > > the base and=20 > > > force everyone else to use it. A MUST goal has to be in the base. > > >=20 > > > I'm a bit sceptical about unexplained scenarios that come=20 > > piecemeal.=20 > > > If you have a scenario in mind where this is needed for the=20 > > MR/MN then=20 > > > please write it down. I find it difficult to keep up with the=20 > > > discussion when each email contradicts the one before it.=20 > > In the last=20 > > > email you said you wanted this for PMIP and MIPv6 didn't=20 > > need it. Now=20 > > > it's a different story. It's hard for me to discuss=20 > things this way. > > >=20 > > > Hesham > > >=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 Jun 08 15:45: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 1HwkOb-0003ig-Pf; Fri, 08 Jun 2007 15:45:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwkOZ-0003iU-VL; Fri, 08 Jun 2007 15:45:15 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwkOZ-0005iU-1L; Fri, 08 Jun 2007 15:45:15 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1A36B200E7; Fri, 8 Jun 2007 21:45:14 +0200 (CEST) X-AuditID: c1b4fb3e-b1a1dbb0000061ca-e8-4669b1c9d890 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EE3D22008A; Fri, 8 Jun 2007 21:45:13 +0200 (CEST) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 21:45:13 +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] issue 93 summary Date: Fri, 8 Jun 2007 21:45:11 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] issue 93 summary Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3AAAFJPuAACqQx0AAWFjcgAAL+6SA= References: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> From: "Karen E. Nielsen (AH/LMD)" To: "Vijay Devarapalli" , "Hesham Soliman" , "Sri Gundavelli" , "Alexandru Petrescu" X-OriginalArrivalTime: 08 Jun 2007 19:45:13.0647 (UTC) FILETIME=[87FDE3F0:01C7AA05] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 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 Hi, Thanks! I understand the port scanning issue=20 as well as the insertion/extraction of TLV header much better now. Sorry to have caused any confusion. So would it be correct to say that the real difference IPSec-wise, in-between=20 option 1,2 and option 3 is that with option 3, then logically MIP need=20 "to come in" before inbound and after outbound IPSec processing=20 to extract/insert TLV and update length fields. Whereas this is not the case with option 1 and 2. As it is also not the case in standard MIPv6 with IPSec tunneling to HA. Karen > -----Original Message----- > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com]=20 > Sent: 8. juni 2007 20:04 > To: Karen E. Nielsen (AH/LMD); Hesham Soliman; Sri=20 > Gundavelli; Alexandru Petrescu > Cc: nemo@ietf.org; mip6@ietf.org > Subject: RE: [nemo] RE: [Mip6] issue 93 summary >=20 > > How do you envisage to negotiate the ESP SA for > >=20 > > IPv4-UDP {TLV {ESP (IPv4, IPv6)}} - ?? >=20 > You negotiate as if you are negotiating for NAT traversal. >=20 > > - and should IP Sec now be made to understand > > Ipv4 UDP TVL ESP encapsulation - Or how do you intend to=20 > trick IPSec=20 > > to respectively decrypt and extract and encrypt and insert the ESP=20 > > header ? >=20 > The IPsec implementation shouldn't have to insert the TLV. It=20 > would be done by Mobile IPv6. (similar to how Mobile IPv6=20 > inserts the home address option after IPsec is done with=20 > adding the ESP header). >=20 > > In our "fast" IP stack implementation we use 4500 UDP port number=20 > > scanning to intercept UDP ESP packets for IPSec processing. > > Option 2 with a specified port for IPv4/IPv6 would be a=20 > > straightforward extension of this. > > Option 1 and Option 3 both require scanning of the UDP=20 > payload for ALL=20 > > UDP packets. As a starting point this does not seem very nice. >=20 > You don't have to scan for all UDP ports. Your "fast" IP=20 > stack implementation, in addition to port 4500, would need to=20 > look for the UDP port that points to the TLV and the TLV=20 > port/protocol field that identifies ESP. >=20 > Vijay >=20 > >=20 > > Karen > >=20 > > > -----Original Message----- > > > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com] > > > Sent: 8. juni 2007 04:15 > > > To: Hesham Soliman; Sri Gundavelli; Karen E. Nielsen (AH/LMD);=20 > > > Alexandru Petrescu > > > Cc: nemo@ietf.org; mip6@ietf.org > > > Subject: RE: [nemo] RE: [Mip6] issue 93 summary > > >=20 > > > > > No. We can still have TLV header. But, I'm saying we=20 > have a >=20 > > > > protocol qualifier. I thought, it might be better to=20 > avoid atleast=20 > > > > for ESP, but, Vijay was suggesting why not have it > > > > consistently for > > > > all modes ESP or non-ESP modes. This is > how the > > > implementation will > > > > work: > > > > > > > > > > I define tunnel interface with the encap mode of=20 > IPv4-UDP-TLV. > > > > > Now, I apply crypto policy on this interface. All > > > packets > GRE, > > > > IPv4, IPv6 packets when sent through this interface,=20 > will get hit=20 > > > > the crypto policy and get the ESP header. As the packets > are=20 > > > > routed, the tunnel interface will apply the IPv4-UDP-TLV > > > > header. =20 > > > > For incomming packets, the packets will match the > tunnel > > > interface, > > > > crypto policy check will remove the ESP > header and > > identify the > > > > payloads using the payload qualifier > in the "next > > > header" field of > > > > the ESP header. This is one > way of implementation. > > > > > > > > > > With ESP, TLV heeader points to ESP: > > > > > IPv4-UDP {TLV {ESP (IPv4, IPv6)}} > > > >=20 > > > > =3D> Do you agree that this is not 3948?=20 > > >=20 > > > Yes, it is not 3948. > > >=20 > > > > The reason we opened > > > > this issue was > > > > Karen's question about how we'd use 3948 which defines UDP ESP=20 > > > > encapsulation. If you run this format on port 4500 then it > > > obviously > > > > won't work. Do you also agree now (given your earlier > > > email) that this > > > > is only an issue for option 3 and not 2 and 1? > > >=20 > > > Port 4500 will not be used. The UDP port number will point to the=20 > > > TLV and the TLV will say ESP follows. > > >=20 > > > Vijay > > >=20 > > > >=20 > > > >=20 > > > > > Like I said, we can get some input from the IPSec folks on=20 > > > > this, if you disagree with this. > > > >=20 > > > > =3D> I don't understand what input you are seeking, this is a > > > different > > > > format from the RFC so if you run it on the same port with an=20 > > > > implementation of that RFC then it won't work. What am=20 > I missing? > > > >=20 > > > > > > > > > > We can also avoid TLV header all together, when using ESP. > > > > > We can carry all protocol types. > > > >=20 > > > > =3D> I think we'll have to. I don't get this "either or"=20 > > > > description. Also > > > > adding and removing the TLV field based on whether ESP is > > > used or not > > > > doesn't seem to be a good way of doing things because it > > > introduces a > > > > dependency between the mobility implementation and the > > way IPsec is > > > > being used. > > > >=20 > > > > > > =3D> Nope. We have requirements from MIP6 and NEMO. Of > > > course > > > > > > it's nice if we > > can help any other work (including > > PMIP) if we > > > > can, but I > > think it's wrong > > to do that at the > > > cost of making > > > > the base spec worse for its > > primary users. > > > > > > If PMIP needs extensions (and it does in other cases) > > > then it > > > > > > can extend > > those solutions for its own use and still > > > reference > > > > this > > work. We shouldn't > > burden the base for=20 > the case of=20 > > > > PMIP, especially when PMIP > > was never the > > main > > > user of this > > > > work. > > > > > > > > > > > > But, I > > > > > > > agree, GRE may not be required for a normal MIP6 tunnel. > > > > > > > > > > > > =3D> Great. So I think at least we're making=20 > progress in > >=20 > > > > understanding where > > this is perceived to be needed. > > > The question > > > > is whether it > > needs to be done > > here or in NETLMM > > > where the > > > > beneficiary is. I don't think > we should be > > > > > addressing it here. > > > > > > > > > > > > > > > I think, we can certainly avoid GRE in DSMIP, if we > > > really want > > > > > to ignore that requirement. There are valid use cases=20 > that are >=20 > > > > there for NETLMM, MIP6 and NEMO, we can solve with a=20 > tiny header. > > > > > As Yoshi pointed out, if some one wants to tunnel legacy > > > IPX > or > > > > other traffic from the MN to home network, GRE is required. > > > >=20 > > > > =3D> You mean you can't carry IPX in IP using proto 111? If a > > > node does > > > > not implement IP at all then we're not talking about an MN.=20 > > > If the MR > > > > want to tunnel IPX in IP then that would work too. > > > > I understand you might prefer GRE, but there is a > > > difference between a > > > > MUST and a MAY type goal. A MAY type goal need not be in > > > the base and > > > > force everyone else to use it. A MUST goal has to be in=20 > the base. > > > >=20 > > > > I'm a bit sceptical about unexplained scenarios that come > > > piecemeal.=20 > > > > If you have a scenario in mind where this is needed for the > > > MR/MN then > > > > please write it down. I find it difficult to keep up with the=20 > > > > discussion when each email contradicts the one before it. > > > In the last > > > > email you said you wanted this for PMIP and MIPv6 didn't > > > need it. Now > > > > it's a different story. It's hard for me to discuss > > things this way. > > > >=20 > > > > Hesham > > > >=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 Fri Jun 08 17:15: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 1Hwlnz-0000bA-CB; Fri, 08 Jun 2007 17:15:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwlnx-0000ac-HW; Fri, 08 Jun 2007 17:15:33 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwlnx-0001WB-0J; Fri, 08 Jun 2007 17:15:33 -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] issue 93 summary Date: Fri, 8 Jun 2007 14:15:32 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] issue 93 summary thread-index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3AAAFJPuAACqQx0AAWFjcgAAL+6SAABAoGQA== References: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> From: "Vijay Devarapalli" To: "Karen E. Nielsen \(AH/LMD\)" , "Hesham Soliman" , "Sri Gundavelli" , "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 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 =20 > Thanks! I understand the port scanning issue=20 > as well as the insertion/extraction of TLV > header much better now. Sorry to have caused any confusion. >=20 > So would it be correct to say that the real difference IPSec-wise, > in-between=20 > option 1,2 and option 3 is that with option 3, then logically=20 > MIP need=20 > "to come in" before inbound and after outbound IPSec processing=20 > to extract/insert TLV and update length fields. > Whereas this is not the case with option 1 and 2. Yes. The TVL would be added for all packets that are sent through=20 a tunnel setup by DS-MIPv6, when the mobile node is on an IPv4=20 access network. >=20 > As it is also not the case in standard MIPv6 with IPSec=20 > tunneling to HA. Well, we kind of have tighter integration between MIPv6 and IPsec already. For e.g, the insertation of home address option and=20 routing header is done by MIPv6 after IPsec processing is done.=20 The use of 'K' bit (to update the tunnel end point) also requires this. I am not suggesting we continue doing this, but adding TLV shouldn't be a big issue. :) Vijay >=20 > Karen >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com]=20 > > Sent: 8. juni 2007 20:04 > > To: Karen E. Nielsen (AH/LMD); Hesham Soliman; Sri=20 > > Gundavelli; Alexandru Petrescu > > Cc: nemo@ietf.org; mip6@ietf.org > > Subject: RE: [nemo] RE: [Mip6] issue 93 summary > >=20 > > > How do you envisage to negotiate the ESP SA for > > >=20 > > > IPv4-UDP {TLV {ESP (IPv4, IPv6)}} - ?? > >=20 > > You negotiate as if you are negotiating for NAT traversal. > >=20 > > > - and should IP Sec now be made to understand > > > Ipv4 UDP TVL ESP encapsulation - Or how do you intend to=20 > > trick IPSec=20 > > > to respectively decrypt and extract and encrypt and=20 > insert the ESP=20 > > > header ? > >=20 > > The IPsec implementation shouldn't have to insert the TLV. It=20 > > would be done by Mobile IPv6. (similar to how Mobile IPv6=20 > > inserts the home address option after IPsec is done with=20 > > adding the ESP header). > >=20 > > > In our "fast" IP stack implementation we use 4500 UDP port number=20 > > > scanning to intercept UDP ESP packets for IPSec processing. > > > Option 2 with a specified port for IPv4/IPv6 would be a=20 > > > straightforward extension of this. > > > Option 1 and Option 3 both require scanning of the UDP=20 > > payload for ALL=20 > > > UDP packets. As a starting point this does not seem very nice. > >=20 > > You don't have to scan for all UDP ports. Your "fast" IP=20 > > stack implementation, in addition to port 4500, would need to=20 > > look for the UDP port that points to the TLV and the TLV=20 > > port/protocol field that identifies ESP. > >=20 > > Vijay > >=20 > > >=20 > > > Karen > > >=20 > > > > -----Original Message----- > > > > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com] > > > > Sent: 8. juni 2007 04:15 > > > > To: Hesham Soliman; Sri Gundavelli; Karen E. Nielsen (AH/LMD);=20 > > > > Alexandru Petrescu > > > > Cc: nemo@ietf.org; mip6@ietf.org > > > > Subject: RE: [nemo] RE: [Mip6] issue 93 summary > > > >=20 > > > > > > No. We can still have TLV header. But, I'm saying we=20 > > have a >=20 > > > > > protocol qualifier. I thought, it might be better to=20 > > avoid atleast=20 > > > > > for ESP, but, Vijay was suggesting why not have it > > > > > consistently for > > > > > all modes ESP or non-ESP modes. This is > how the > > > > implementation will > > > > > work: > > > > > > > > > > > > I define tunnel interface with the encap mode of=20 > > IPv4-UDP-TLV. > > > > > > Now, I apply crypto policy on this interface. All > > > > packets > GRE, > > > > > IPv4, IPv6 packets when sent through this interface,=20 > > will get hit=20 > > > > > the crypto policy and get the ESP header. As the=20 > packets > are=20 > > > > > routed, the tunnel interface will apply the IPv4-UDP-TLV > > > > > header. =20 > > > > > For incomming packets, the packets will match the > tunnel > > > > interface, > > > > > crypto policy check will remove the ESP > header and > > > identify the > > > > > payloads using the payload qualifier > in the "next > > > > header" field of > > > > > the ESP header. This is one > way of implementation. > > > > > > > > > > > > With ESP, TLV heeader points to ESP: > > > > > > IPv4-UDP {TLV {ESP (IPv4, IPv6)}} > > > > >=20 > > > > > =3D> Do you agree that this is not 3948?=20 > > > >=20 > > > > Yes, it is not 3948. > > > >=20 > > > > > The reason we opened > > > > > this issue was > > > > > Karen's question about how we'd use 3948 which=20 > defines UDP ESP=20 > > > > > encapsulation. If you run this format on port 4500 then it > > > > obviously > > > > > won't work. Do you also agree now (given your earlier > > > > email) that this > > > > > is only an issue for option 3 and not 2 and 1? > > > >=20 > > > > Port 4500 will not be used. The UDP port number will=20 > point to the=20 > > > > TLV and the TLV will say ESP follows. > > > >=20 > > > > Vijay > > > >=20 > > > > >=20 > > > > >=20 > > > > > > Like I said, we can get some input from the IPSec folks on=20 > > > > > this, if you disagree with this. > > > > >=20 > > > > > =3D> I don't understand what input you are seeking, this is a > > > > different > > > > > format from the RFC so if you run it on the same port with an=20 > > > > > implementation of that RFC then it won't work. What am=20 > > I missing? > > > > >=20 > > > > > > > > > > > > We can also avoid TLV header all together, when using ESP. > > > > > > We can carry all protocol types. > > > > >=20 > > > > > =3D> I think we'll have to. I don't get this "either or"=20 > > > > > description. Also > > > > > adding and removing the TLV field based on whether ESP is > > > > used or not > > > > > doesn't seem to be a good way of doing things because it > > > > introduces a > > > > > dependency between the mobility implementation and the > > > way IPsec is > > > > > being used. > > > > >=20 > > > > > > > =3D> Nope. We have requirements from MIP6 and NEMO. Of > > > > course > > > > > > > it's nice if we > > can help any other work (including > > > PMIP) if we > > > > > can, but I > > think it's wrong > > to do that at the > > > > cost of making > > > > > the base spec worse for its > > primary users. > > > > > > > If PMIP needs extensions (and it does in other cases) > > > > then it > > > > > > > can extend > > those solutions for its own use and still > > > > reference > > > > > this > > work. We shouldn't > > burden the base for=20 > > the case of=20 > > > > > PMIP, especially when PMIP > > was never the > > main > > > > user of this > > > > > work. > > > > > > > > > > > > > > But, I > > > > > > > > agree, GRE may not be required for a normal=20 > MIP6 tunnel. > > > > > > > > > > > > > > =3D> Great. So I think at least we're making=20 > > progress in > >=20 > > > > > understanding where > > this is perceived to be needed. > > > > The question > > > > > is whether it > > needs to be done > > here or in NETLMM > > > > where the > > > > > beneficiary is. I don't think > we should be > > > > > > addressing it here. > > > > > > > > > > > > > > > > > > I think, we can certainly avoid GRE in DSMIP, if we > > > > really want > > > > > > to ignore that requirement. There are valid use cases=20 > > that are >=20 > > > > > there for NETLMM, MIP6 and NEMO, we can solve with a=20 > > tiny header. > > > > > > As Yoshi pointed out, if some one wants to tunnel legacy > > > > IPX > or > > > > > other traffic from the MN to home network, GRE is required. > > > > >=20 > > > > > =3D> You mean you can't carry IPX in IP using proto 111? If a > > > > node does > > > > > not implement IP at all then we're not talking about an MN.=20 > > > > If the MR > > > > > want to tunnel IPX in IP then that would work too. > > > > > I understand you might prefer GRE, but there is a > > > > difference between a > > > > > MUST and a MAY type goal. A MAY type goal need not be in > > > > the base and > > > > > force everyone else to use it. A MUST goal has to be in=20 > > the base. > > > > >=20 > > > > > I'm a bit sceptical about unexplained scenarios that come > > > > piecemeal.=20 > > > > > If you have a scenario in mind where this is needed for the > > > > MR/MN then > > > > > please write it down. I find it difficult to keep up with the=20 > > > > > discussion when each email contradicts the one before it. > > > > In the last > > > > > email you said you wanted this for PMIP and MIPv6 didn't > > > > need it. Now > > > > > it's a different story. It's hard for me to discuss > > > things this way. > > > > >=20 > > > > > Hesham > > > > >=20 > > > > >=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 Jun 09 07:28:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwz7C-00068L-WD; Sat, 09 Jun 2007 07:28:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwz7B-00067s-7R; Sat, 09 Jun 2007 07:28:17 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwz79-0007S3-J6; Sat, 09 Jun 2007 07:28:17 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 17363204F5; Sat, 9 Jun 2007 13:28:14 +0200 (CEST) X-AuditID: c1b4fb3e-b01efbb0000061ca-73-466a8eccd747 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E11002040B; Sat, 9 Jun 2007 13:28:12 +0200 (CEST) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Jun 2007 13:28:12 +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] issue 93 summary Date: Sat, 9 Jun 2007 13:28:10 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] issue 93 summary Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3AAAFJPuAACqQx0AAWFjcgAAL+6SAABAoGQAAdWWUg References: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> From: "Karen E. Nielsen (AH/LMD)" To: "Vijay Devarapalli" , "Hesham Soliman" , "Sri Gundavelli" , "Alexandru Petrescu" X-OriginalArrivalTime: 09 Jun 2007 11:28:12.0687 (UTC) FILETIME=[43BA41F0:01C7AA89] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 Hi, =20 >=20 > >=20 > > As it is also not the case in standard MIPv6 with IPSec=20 > tunneling to=20 > > HA. >=20 > Well, we kind of have tighter integration between MIPv6 and=20 > IPsec already. For e.g, the insertation of home address=20 > option and routing header is done by MIPv6 after IPsec=20 > processing is done.=20 > The use of 'K' bit (to update the tunnel end point) also=20 > requires this. I am not suggesting we continue doing this,=20 > but adding TLV shouldn't be a big issue. :) >=20 > Vijay >=20 Yes, :-). I do not want to be twisting straws here about the pros and cons. I am simply trying to understand the differences. However, (now you may see this as twisting straws, but the angle is different), the extraction and insertion of RH/DO is a mobility thing and there is a very good reason IPSec shouldn't know about those as we exactly want the movement to be transparent to IPSec SAs anchored on the MN's home address. The TLV header is not a mobility thing, per se, as I understand it.=20 So the insertion and extraction outside IPSec seems more like a hack to allow this new encapsulation header type IP-UDP-TLV to use IPSec UDP ESP encapsulation.=20 I agree that it is feasible from an implementation perspective.=20 It is not a very nice, though. But perhaps need is a better keyword, than nice here. Karen _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Jun 09 10: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 1Hx1u3-0006GR-T5; Sat, 09 Jun 2007 10:26:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx1u2-0006G8-4v; Sat, 09 Jun 2007 10:26:54 -0400 Received: from omta05ps.mx.bigpond.com ([144.140.83.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hx1u0-0002Q5-6w; Sat, 09 Jun 2007 10:26:54 -0400 Received: from oaamta07ps.mx.bigpond.com ([124.191.178.123]) by omta05ps.mx.bigpond.com with ESMTP id <20070609142649.NMVN23363.omta05ps.mx.bigpond.com@oaamta07ps.mx.bigpond.com>; Sat, 9 Jun 2007 14:26:49 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta07ps.mx.bigpond.com with ESMTP id <20070609142649.MWDH5648.oaamta07ps.mx.bigpond.com@PC20005>; Sat, 9 Jun 2007 14:26:49 +0000 From: "Hesham Soliman" To: "'Karen E. Nielsen \(AH/LMD\)'" , "'Vijay Devarapalli'" , "'Sri Gundavelli'" , "'Alexandru Petrescu'" Subject: RE: [nemo] RE: [Mip6] issue 93 summary Date: Sun, 10 Jun 2007 00:26:43 +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 In-Reply-To: Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3AAAFJPuAACqQx0AAWFjcgAAL+6SAABAoGQAAdWWUgAAa2WeA= Message-Id: <20070609142649.MWDH5648.oaamta07ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 > > Well, we kind of have tighter integration between MIPv6 and > > IPsec already. For e.g, the insertation of home address > > option and routing header is done by MIPv6 after IPsec > > processing is done. > > The use of 'K' bit (to update the tunnel end point) also > > requires this. I am not suggesting we continue doing this, > > but adding TLV shouldn't be a big issue. :) > > > > Vijay > > > > Yes, :-). I do not want to be twisting straws here about the pros and > cons. I > am simply trying to understand the differences. > > However, (now you may see this as twisting straws, but the angle is > different), > the extraction and insertion of RH/DO is a mobility thing > and there is a > very good reason > IPSec shouldn't know about those as we exactly want the > movement to be > transparent to > IPSec SAs anchored on the MN's home address. => Which does not at all result in tight integration with IPsec, quite the opposite in fact. It is done to be transparent to IPsec. There is no extraction/insertion, we swap the content with the src/dst address. Having tight integration with IPsec means that we would require IPsec to know these mobility specific events. Hesham > > The TLV header is not a mobility thing, per se, as I understand it. > So the insertion and extraction outside IPSec seems more > like a hack to > allow this > new encapsulation header type IP-UDP-TLV to use IPSec UDP ESP > encapsulation. > > I agree that it is feasible from an implementation perspective. > It is not a very nice, though. But perhaps need is a better keyword, > than nice here. > > Karen > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Jun 09 11:46: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 1Hx38z-0005Ri-Ft; Sat, 09 Jun 2007 11:46:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx38x-0005OW-Ez; Sat, 09 Jun 2007 11:46:23 -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 1Hx38x-000806-4X; Sat, 09 Jun 2007 11:46:23 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 09 Jun 2007 08:46:22 -0700 X-IronPort-AV: i="4.16,403,1175497200"; d="scan'208"; a="492196043:sNHT51688704" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l59FkMDv031546; Sat, 9 Jun 2007 08:46:22 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l59Fk9tV002554; Sat, 9 Jun 2007 15:46:13 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); Sat, 9 Jun 2007 08:46:09 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Jun 2007 08:46:08 -0700 From: "Sri Gundavelli" To: "'Karen E. Nielsen \(AH/LMD\)'" , "'Vijay Devarapalli'" , "'Hesham Soliman'" , "'Alexandru Petrescu'" References: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> Subject: RE: [nemo] RE: [Mip6] issue 93 summary Date: Sat, 9 Jun 2007 08:46:08 -0700 Message-ID: <000001c7aaad$4c40ae80$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3AAAFJPuAACqQx0AAWFjcgAAL+6SAABAoGQAAdWWUgAAkb6CA= In-Reply-To: X-OriginalArrivalTime: 09 Jun 2007 15:46:09.0022 (UTC) FILETIME=[4C5791E0:01C7AAAD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2491; t=1181403982; x=1182267982; 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[nemo]=20RE=3A=20[Mip6]=20issue=2093=20summary |Sender:=20; bh=ERa2cK6TqBjqT+OAKRL4FK70exoS77+CX4tJcONSAoU=; b=Jca25yozwbwoyXP1N9S6f7QAypZ8lIphVLaFPSaLhYgK/uJFJ1qYP+3tWpBwJ1GOM/g2f4A6 Wg8DV9cB1gdTLAlBslAzNPBy6MrIu+zgukX0ybVi0/8n/h6V3VuiAvSu; 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: 00e94c813bef7832af255170dca19e36 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 Hi Karen, > -----Original Message----- > From: Karen E. Nielsen (AH/LMD) [mailto:karen.e.nielsen@ericsson.com] > Sent: Saturday, June 09, 2007 4:28 AM > To: Vijay Devarapalli; Hesham Soliman; Sri Gundavelli; > Alexandru Petrescu > Cc: nemo@ietf.org; mip6@ietf.org > Subject: RE: [nemo] RE: [Mip6] issue 93 summary > > Hi, > > > > > > > > > > As it is also not the case in standard MIPv6 with IPSec > > tunneling to > > > HA. > > > > Well, we kind of have tighter integration between MIPv6 and > > IPsec already. For e.g, the insertation of home address > > option and routing header is done by MIPv6 after IPsec > > processing is done. > > The use of 'K' bit (to update the tunnel end point) also > > requires this. I am not suggesting we continue doing this, > > but adding TLV shouldn't be a big issue. :) > > > > Vijay > > > > Yes, :-). I do not want to be twisting straws here about the pros and > cons. I > am simply trying to understand the differences. > > However, (now you may see this as twisting straws, but the angle is > different), > the extraction and insertion of RH/DO is a mobility thing and > there is a > very good reason > IPSec shouldn't know about those as we exactly want the movement to be > transparent to > IPSec SAs anchored on the MN's home address. > > The TLV header is not a mobility thing, per se, as I understand it. > So the insertion and extraction outside IPSec seems more like > a hack to > allow this > new encapsulation header type IP-UDP-TLV to use IPSec UDP ESP > encapsulation. > > I agree that it is feasible from an implementation perspective. > It is not a very nice, though. But perhaps need is a better keyword, > than nice here. > When 3948 is used, ie if the port is 4500 and not DSMIP port, the TLV header is not required, as we can carry other protocol payloads and the required headers are present for that mode. So, the behaviour is consistent to 3948 and its the same for both option#1 and option#3. If we prefer both the ESP and non ESP traffic to be handled as a IP-UDP-TLV traffic on DSMIP port, the MIP is the handler for this traffic and will remove the tunnel encapsulations and pass it the the IPSec process. So, its about the registered handlers, IPSec is the handler on 4500 and MIP on the DSMIP port. MIP understands all the encapsulation formats and hence can do the proper decaps and pass it to the crypto system. Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jun 10 19:38: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 1HxWzH-0006FF-CP; Sun, 10 Jun 2007 19:38:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxWzG-0006F2-M7; Sun, 10 Jun 2007 19:38:22 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxWzF-0004GU-DD; Sun, 10 Jun 2007 19:38:22 -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] issue 93 summary Date: Sun, 10 Jun 2007 16:38:19 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] issue 93 summary thread-index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3AAAFJPuAACqQx0AAWFjcgAAL+6SAABAoGQAAdWWUgAExIkyA= References: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> From: "Vijay Devarapalli" To: "Karen E. Nielsen \(AH/LMD\)" , "Hesham Soliman" , "Sri Gundavelli" , "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 =20 > > > As it is also not the case in standard MIPv6 with IPSec=20 > > tunneling to=20 > > > HA. > >=20 > > Well, we kind of have tighter integration between MIPv6 and=20 > > IPsec already. For e.g, the insertation of home address=20 > > option and routing header is done by MIPv6 after IPsec=20 > > processing is done.=20 > > The use of 'K' bit (to update the tunnel end point) also=20 > > requires this. I am not suggesting we continue doing this,=20 > > but adding TLV shouldn't be a big issue. :) > >=20 > > Vijay > >=20 >=20 > Yes, :-). I do not want to be twisting straws here about the pros and > cons. I > am simply trying to understand the differences. >=20 > However, (now you may see this as twisting straws, but the angle is > different), > the extraction and insertion of RH/DO is a mobility thing and there is = a > very good reason > IPSec shouldn't know about those as we exactly want the movement to be > transparent to > IPSec SAs anchored on the MN's home address. >=20 > The TLV header is not a mobility thing, per se, as I understand it.=20 > So the insertion and extraction outside IPSec seems more like a hack = to > allow this > new encapsulation header type IP-UDP-TLV to use IPSec UDP ESP > encapsulation.=20 Well, the TLV is specific to DS-MIPv6 tunnels setup over IPv4.=20 No other protocol is using the TLV.=20 Vijay >=20 > I agree that it is feasible from an implementation perspective.=20 > It is not a very nice, though. But perhaps need is a better keyword, > than nice here. >=20 > Karen >=20 >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 11 04:07: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 1Hxevf-0005wW-M8; Mon, 11 Jun 2007 04:07:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxevd-0005wG-V1; Mon, 11 Jun 2007 04:07:09 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxevc-00010Z-8j; Mon, 11 Jun 2007 04:07:09 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DE03A21158; Mon, 11 Jun 2007 10:07:06 +0200 (CEST) X-AuditID: c1b4fb3e-ad9eabb0000061ca-fb-466d02aa9f55 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B6E152101B; Mon, 11 Jun 2007 10:07:06 +0200 (CEST) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 10:07:06 +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] issue 93 summary Date: Mon, 11 Jun 2007 10:07:05 +0200 Message-ID: In-Reply-To: <000001c7aaad$4c40ae80$d5f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] issue 93 summary Thread-Index: Aceo6RbVYor/wG2xQgGFIweriARZVAAAjG+gAAP/PqAABmB7QAAAWPHwAABc1aAAAGglAAAFC/tAAA0y9OAAAWLNgAABaV3AAAFJPuAACqQx0AAWFjcgAAL+6SAABAoGQAAdWWUgAAkb6CAAVGh/IA== References: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> <000001c7aaad$4c40ae80$d5f6200a@amer.cisco.com> From: "Karen E. Nielsen (AH/LMD)" To: "Sri Gundavelli" , "Vijay Devarapalli" , "Hesham Soliman" , "Alexandru Petrescu" X-OriginalArrivalTime: 11 Jun 2007 08:07:06.0505 (UTC) FILETIME=[808C7F90:01C7ABFF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Hi Sri, > >=20 >=20 > When 3948 is used, ie if the port is 4500 and not DSMIP port,=20 > the TLV header is not required, as we can carry other=20 > protocol payloads and the required headers are present for=20 > that mode. So, the behaviour is consistent to 3948 and its=20 > the same for both option#1 and option#3. >=20 > If we prefer both the ESP and non ESP traffic to be handled=20 > as a IP-UDP-TLV traffic on DSMIP port, the MIP is the handler=20 > for this traffic and will remove the tunnel encapsulations=20 > and pass it the the IPSec process. So, its about the=20 > registered handlers, IPSec is the handler on 4500 and MIP on=20 > the DSMIP port. MIP understands all the encapsulation formats=20 > and hence can do the proper decaps and pass it to the crypto system.=20 >=20 Yes. It is feasible and yes it is a matter of implementation and whether you see IPSec as a simple insert/extract IPSEc headers or whether IPSec is considered also to handle the outer headers (the nature of the latter which is given in the IPSec policies). Anyway, I will rest here. I have understood the issues - Thanks !! >From an implementation perspective we can handle all options. For simplicity, interoperability issues, robustness and such, I do prefer to keep the IPSec and non-IPSec tunnel dialects as=20 few as possible and would rather see option 1 and option 2, than option 3. But I can live with all options. Karen > Sri=20 >=20 >=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 Mon Jun 11 07:19: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 1Hxhvo-0007EA-Tp; Mon, 11 Jun 2007 07:19:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxhvo-0007Dx-90 for mip6@ietf.org; Mon, 11 Jun 2007 07:19:32 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxhvm-0006Ut-Sr for mip6@ietf.org; Mon, 11 Jun 2007 07:19:32 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AA3FA19868B; Mon, 11 Jun 2007 14:19:29 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 64BC119868A; Mon, 11 Jun 2007 14:19:29 +0300 (EEST) Message-ID: <466D2FC1.60006@piuha.net> Date: Mon, 11 Jun 2007 14:19:29 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: draft-ietf-mip6-bootstrapping-integrated-dhc@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 1.1 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Mobile IPv6 Mailing List Subject: [Mip6] AD review of draft-ietf-mip6-bootstrapping-integrated-dhc 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 have made my AD review on this document. It is generally in good shape, but I would like to raise the following two issues: 1. The document assumes that there is communication between the NAS and the DHCP server/relay parts in the visited network. From what I can see, such communication is only needed, however, if the assigned home agent information is going to differ between mobile nodes in a certain way. Specifically, if the assignment decision depends on local criteria (load in different home agents, round-robin status) and policy that does not differ between AAAHs or mobile nodes, then no such communication is needed. Not having to assume co-location or communication would simplify the implementation of this considerably. This would also cover one important use case that I can see, an access network that offers local home agents without any specific additional agreements or roaming services. Has such a case been considered in the discussion? Is it feasible to allow devices to implement such a simplified mode of operation? 2. A review in DHC WG needs to happen to ensure that the planned model is in line with what the DHCP experts feel is achievable. I will ask the chairs to arrange this before we go to IETF Last Call. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 11 12:39: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 1Hxmv6-00033V-DS; Mon, 11 Jun 2007 12:39:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxmv5-00030k-AL for mip6@ietf.org; Mon, 11 Jun 2007 12:39:07 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxmv4-0005CT-S8 for mip6@ietf.org; Mon, 11 Jun 2007 12:39:07 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id CC34790037 for ; Mon, 11 Jun 2007 12:39:02 -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 26335-10 for ; Mon, 11 Jun 2007 12:39:02 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Mon, 11 Jun 2007 12:39:02 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 12:39:07 -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 Date: Mon, 11 Jun 2007 12:38:54 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA174@exchtewks2.starentnetworks.com> In-Reply-To: <466D2FC1.60006@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-mip6-bootstrapping-integrated-dhc Thread-Index: AcesGmUjjUEqh3ODRZq/Z0mlQK+viwAKb+YQ From: "Chowdhury, Kuntal" To: "Jari Arkko" , X-OriginalArrivalTime: 11 Jun 2007 16:39:07.0554 (UTC) FILETIME=[07B89020:01C7AC47] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 1.1 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Mobile IPv6 Mailing List Subject: [Mip6] RE: AD review of draft-ietf-mip6-bootstrapping-integrated-dhc 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 Jari, Thanks for reviewing the document. Please see my comments inline.... BR, Kuntal > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Monday, June 11, 2007 6:19 AM > To: draft-ietf-mip6-bootstrapping-integrated-dhc@tools.ietf.org > Cc: Mobile IPv6 Mailing List > Subject: AD review of draft-ietf-mip6-bootstrapping-integrated-dhc >=20 >=20 > Hi all, >=20 > I have made my AD review on this document. It is generally > in good shape, but I would like to raise the following two > issues: >=20 > 1. The document assumes that there is communication between > the NAS and the DHCP server/relay parts in the visited > network. From what I can see, such communication is > only needed, however, if the assigned home agent information > is going to differ between mobile nodes in a certain > way. Specifically, if the assignment decision depends on > local criteria (load in different home agents, round-robin > status) and policy that does not differ between AAAHs > or mobile nodes, then no such communication is needed. >=20 [KC>] Home Agent assignment in the local network is covered in section 4.2.2 (Home Agent allocation in the ASP). In this scenario, the Home Agent is assigned by the DHCP server in the local network. The HA assignment policy in the ASP can be based on the criteria that you mentioned (HA load status, round robin etc.) in the DHCP server. The criteria that AAAH uses to pick a HA can be different and independent of the same in DHCP server. Regarding NAS - DHCP relay communication: if we assume that there is no communication between these two functions, conveyance of the received information from the AAAH to the DHCP system will be an issue. > Not having to assume co-location or communication > would simplify the implementation of this considerably. > This would also cover one important use case that I > can see, an access network that offers local home > agents without any specific additional agreements > or roaming services. >=20 [KC>] I agree with you that if collocation assumption of NAS and DHCP relay can be removed, the solution will become simpler. However, the assignment of the HA in the home MSP (other than the ASP) will be unresolved in that case. May be we can clarify this by adding a statement like this: if assignment of home agent in the home MSP is not required by a deployment, collocation of NAS and the DHCP relay functions won't be necessary. In such a case, implementation of the options and procedures defined in [HIOPT] should suffice. > Has such a case been considered in the discussion? > Is it feasible to allow devices to implement > such a simplified mode of operation? >=20 [KC>] Simple [HIOPT] based bootstrapping of the local home agent address is feasible. It was discussed at the time of developing this solution. May be in the current I-D we should explicitly mention about the simpler mode of operation. > 2. A review in DHC WG needs to happen to ensure that > the planned model is in line with what the DHCP experts > feel is achievable. I will ask the chairs to arrange this > before we go to IETF Last Call. >=20 [KC>] That will be good. > Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 11 13:17: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 1HxnVg-00078U-F3; Mon, 11 Jun 2007 13:16:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxnVf-00076s-GL for mip6@ietf.org; Mon, 11 Jun 2007 13:16:55 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxnVe-0002ir-3z for mip6@ietf.org; Mon, 11 Jun 2007 13:16:55 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id E85259003F for ; Mon, 11 Jun 2007 13:16:49 -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 27595-01 for ; Mon, 11 Jun 2007 13:16:46 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Mon, 11 Jun 2007 13:16:46 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 13:16:50 -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 Date: Mon, 11 Jun 2007 13:16:38 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA177@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: host config options via MIP6 Thread-Index: AcesTEaE8Q9oZwp/RiK/ISM8vXELuA== From: "Chowdhury, Kuntal" To: "Mobile IPv6 Mailing List" X-OriginalArrivalTime: 11 Jun 2007 17:16:50.0835 (UTC) FILETIME=[4CBDD630:01C7AC4C] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Mip6] host config options via MIP6 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 folks, We posted the following draft before last IETF. Since then we did not have much discussion. We would really appreciate your comments and suggestions on this draft. http://www.ietf.org/internet-drafts/draft-bharatia-mip6-gen-ext-01.txt Here is the abstract: " Abstract This document describes the mechanism for providing the host configuration information during Mobile IPv6 Binding Update procedure. The Configuration Options extension may be included in the Mobile IPv6 Binding Update message for requesting the home agent to include configuration parameters needed for network service usage (e.g. DNS). The requested information is provided by the Home Agent in one or more Configuration Options extensions. " Please note that similar capability is being defined for MIP4 protocol. BR, Kuntal _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 11 13:32: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 1Hxnks-0005hJ-3j; Mon, 11 Jun 2007 13:32:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxnkq-0005hD-Nv for mip6@ietf.org; Mon, 11 Jun 2007 13:32:36 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxnkp-0004x2-F2 for mip6@ietf.org; Mon, 11 Jun 2007 13:32:36 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D228C19868B; Mon, 11 Jun 2007 20:32:34 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6E6E9198689; Mon, 11 Jun 2007 20:32:34 +0300 (EEST) Message-ID: <466D8732.9090806@piuha.net> Date: Mon, 11 Jun 2007 20:32:34 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Chowdhury, Kuntal" References: <7CCD07160348804497EF29E9EA5560D7024DA174$0001@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024DA174$0001@exchtewks2.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 1.1 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Mobile IPv6 Mailing List , draft-ietf-mip6-bootstrapping-integrated-dhc@tools.ietf.org Subject: [Mip6] Re: AD review of draft-ietf-mip6-bootstrapping-integrated-dhc 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, > . In such a case, implementation of the > options and procedures defined in [HIOPT] should suffice. > > ... > [KC>] Simple [HIOPT] based bootstrapping of the local home agent address > is feasible. It was discussed at the time of developing this solution. > May be in the current I-D we should explicitly mention about the simpler > mode of operation. > This would be enough for me to move the document forward. Care to suggest text? Please ensure that its clear to the reader what the requirements are for an implementation that conforms to this specification. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 11 13:41: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 1Hxnsx-0001Sl-Gn; Mon, 11 Jun 2007 13:40:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxnsv-0001MG-SR for mip6@ietf.org; Mon, 11 Jun 2007 13:40:57 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hxnsu-0005i6-Km for mip6@ietf.org; Mon, 11 Jun 2007 13:40:57 -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 l5BHemc21658; Mon, 11 Jun 2007 17:40:48 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] Comments on draft-muhanna-mip6-binding-revocation-01.txt Date: Mon, 11 Jun 2007 12:40:46 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114D69C21@zrc2hxm2.corp.nortel.com> In-Reply-To: <46654666.5000701@alcatel-lucent.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Comments on draft-muhanna-mip6-binding-revocation-01.txt Thread-Index: AcenYzRUfZbiGnIPQj6yDLAFC28LIQE6+7Sw References: <46654666.5000701@alcatel-lucent.fr> From: "Ahmad Muhanna" To: "Bruno Mongazon-Cazavet" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4f585e1bcd209294c6b9386034cecfc6 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 Bruno, Thanks for your detailed review and comments. My apologies for the late response, please see comments inline. Regards, Ahmad =20 >=20 > Dear writers, >=20 > Here are my comments/questions to your draft (ed. 01). > Sorry, this is a long review but i think its needed if we want to do a > good job! >=20 > Bruno. >=20 >=20 > Abstract section > ************ >=20 > [opinion] I don't see the need to say that revocation is missing in=20 > other drafts. Should just say that the draft "defines" a revocation=20 > mechanism that applies to mobile IPv6 and its extensions (PMIP6). [Ahmad] Ok. >=20 > [opinion] Draft says: >=20 > 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. >=20 > I don't think it is the main focus of the draft. It introduces some=20 > confusion for the reader. The revocation mechanism has a semantic and=20 > the abstract raises first implementation aspects. Revocation is=20 > independent of a generic messaging between "any two mobility=20 > entities". [Ahmad] I guess the idea here is that these messages can be used by the HA, MAG, LMA, and probably the MN. That is probably what we want to communicate and I am not sure if we succeeded. However, we will look into it to improve the abstract. =20 > Moreover, reading further the draft, the revocation appears to be=20 > mainly initiated by HA or LMA (CN?) and thus might not require a=20 > generic messaging. [Ahmad] That is not necessarily true. Use case 3 shows a scenario where the revocation is initiated by the MAG. I mean we tried to present some of the relevant use cases in our initial revision. Hopefully, when this draft becomes a wg item, then we will cover all related scenarios and use cases. >=20 > You might have a look at the abstract of draft-ietf-reg-revok-07.txt.=20 > I think it is a perfect abstract of a revocation mechanism. [Ahmad] Ok, you mean RFC3543. will look into that too. >=20 > [question] Is the example of PMIP6 usage pertinent in the abstract=20 > section? Would a regular MIP6 example not be simpler? [Ahmad] I see your point. I guess we can capture the MIP6 example there too or make it either or to capture both examples. >=20 > Protocol overview section (3.) > *********************** >=20 > [opinion] Usage of the term "Binding Revocation Indication Message"=20 > is not consistent with the term "Binding Revocation Message" used in=20 > IPv4 revocation draft. Not critical. [Ahmad] Thanks for raising this. Actually we were thinking of Binding Revocation Request (BRR) but that conflicts with the Binding Refresh Request message and also, it is not a request. Our thoughts was that since this is an optional functionality and acknowledgement is kind of optional too, we thought an indication make more sense, especially, for example, if this is used during MN handoff for example, LMA may send an indication to the source MAG to cleanup resources. In reality the MN BCE has not been revoked at the LMA but we use the message to help MAG clean unused resources. >=20 > [question] HA/LMA can issue BRI, but can a CN (Correspondant > Node) issue a BRI? [Ahmad] We did not think of this scenario and it would depends on the group consensus if it make sense to extend revocation to CN, for example. >=20 > BRI message > ********** >=20 > [question] possible senders and receivers of BRI? > My understanding is: > -HA can send BRI to MN (MIP6) > -LMA can send BRI to MAG (PMIP6) > Is that correct? [Ahmad] Yes. > I don't get it that way when reading the section intro. > It seems MAG can send BRI to LMA also, right? [Ahmad] Yes. > It seems MN can cend BRI to HA also, right? [Ahmad] That is not the intention. If you can point me to the exact text, we would try to eliminate the confusion. Anyway, we will look into the text more closely one more time, to make sure that is not the case. > If so, i would rather suggest MAG sends regular deregistration PBU to=20 > release the binding rather than revocation. > I would also suggest (as recommended by RFC 3775) that MN sends=20 > deregistration BU to release the binding rather than revocation. [Ahmad] As far as the MN, yes MN should use deregistration BU with lifetime of zero. In the case of the MAG, we probably can make it optional to use either or. Since the MAG needs to support receiving a BRI, it also can send it. But we can look into that and modify it as per group consensus. >=20 > [opinion] "sessions" in Global Per-Peer Bindings (G bit) should be=20 > "bindings". The term "session" is confusing. > Same in Mobility Options and several places in the draft. [Ahmad] Thanks. Appreciate it. Will take care of them. >=20 > [opinion+question] lack of BRI semantics in the section. > If P bit (Proxy) is set, binding identification shall be present in=20 > Mobility Options. How is a PBU identified? [Ahmad] I am not sure about the question here, do you mean how we distinguish PBU from BU?, or How we identify a MN BCE? > Is it > possible to include multiple PBU identifications in a BRI. If P bit=20 > not set, same problem to identify a binding. [Ahmad] That is a good topic for discussion. Our thoughts, initially, is the ability to revoke multiple BCEs as long as they share a common criteria, however, I think we can look into that during the discussion of the protocol details. > If G bit (global) is set, does the revocation concerns all BU and PBU? [Ahmad] The G bit is introduced to communicate the need to delete all sessions at one of the mobility agents. For example LMA or MAG. However, this should be applicable to Proxy BCE only, IMO. > Identification of the BU/PBU in Mobility options is critical.=20 > I doubt solely the HoA is enough, thoughts? [Ahmad] I agree. We can discuss this in more details later when we get deeper in the protocol. However, we probably need more than HoA in some cases. >=20 > BRA message > *********** >=20 > [question] how do you handle the case where G bit has been set in the=20 > BRI and revocation is partially successful (some BU/PBU revoked,=20 > others don't)? [Ahmad] I am not sure what you mean by partially successful? The MAG should be able to release all sessions. You may meant that probably the number of sessions that the MAG release is not the same as those at the LMA/HA for example. But in that case, it does not matter. IMO. > [opinion] lack of semantics for the Mobility Options field in BRA=20 > ("usually match..."). [Ahmad] Not necessarily. Because all what we need is for the sending mobility entity is able to match the returned BRA to the outstanding BRI. > [opinion] lack of semantics for the Status code (BU/PBU=20 > discrimination). > BCE term is confusing. [Ahmad] Why do we need to discriminate between the two types? >=20 > Use cases > ******** >=20 > [opinion+question] You say that revocation no longer authorizes to=20 > receive mobility services. What does it mean exactly "authorizes to=20 > receive mobility service"? [Ahmad] There are many reasons that the Home domain would like to revoke a user service. There is currently I think a Disconnect message identified that AAA can send to the HA. Basically the user is no longer able to receive MIPv6 services and be able to access the internet as a mobile. > To revocation terminates prematurely an established BU/PBU with the=20 > following consequences: > -no more data will be tunneled by the revoker (HA/LMA) toward the peer > mobility agent -no more data will be accepted from the revokee for=20 > tunneling to the network by the revoker -BU/PBU need to be=20 > reestablished Thus revocation implies deregistration at both revoker=20 > and revokee level. > I think this could be said in the draft before to go into use case=20 > details. [Ahmad] That is a good idea and we can capture some of these details. >=20 > =3D=3D=3D> Use Case 1 (HA to MN) >=20 > [question] Why is the P bit (Proxy bit) set while PMIP6 is not=20 > involved? [Ahmad] It should not. If it is in the text, we will correct it. Can you point me to the exact text. Thanks. > [question] Is the HoA sufficient to identify the binding? > I doubt it. If the MN has multiple CoA (primary and non-primary),=20 > multiple BU can exist at HA level. In such case the (CoA, HoA) couple=20 > is needed to identify the BU to revoke. [Ahmad] This is a very Good point. Thanks again. Will address the details when we dive into the protocol details. However, this is a good scenario. >=20 > =3D=3D=3D> Use Case 2 (LMA to MAG) >=20 > [question] Looks like the A bit is required for PBU revocation. Is it=20 > stated previously in revocation message semantics? [Ahmad] I guess we left it up to the HA local policy but we do not want to mandate it. Unless there is a very strong reason and the group agrees on that. > [opinion] the sending of the RA to terminate the prefix of the MN=20 > should be optional (as in IPv4 with the I bit). [Ahmad] Actually you are bringing very good points. I really thanks you for your detailed review. There is only one difference from MIPv4 revocation. In our case it is possibly a PMIP session and the MN is not involved in the mobility aspect. Since MN depends on RA to identify if it moves, still have a valid IP address etc., I am thinking at least, for certain scenarios, we need to mandate that the MAG need to send a RA with HNP lifetime is set to zero. =20 > Ideally, the support of sending such RA when a BRI is received shall=20 > be an option of the PBU message (the MAG indicates its capability). In > addition, the BRI shall indicate if RA sending is requested on a BRI=20 > basis and according to MAG capability. This of course, will require=20 > additional working on the draft if a BRI targets multiple BU/PBU with=20 > the G bit. [Ahmad] We assume in order for the MAG to be able to support PMIPv6, it should be able to send RA. However, I agree with you, we may need to have an indication to the MAG in certain cases that MAG must send a RA as I said above. Probably another bit or identify that scenario specifically. We will work out the details. >=20 >=20 > =3D=3D=3D> Use Case 3 (MAG to LMA) >=20 > [opinion] BRI/BRA is not required in that case. The MAG can send a=20 > regular deregistration BU/PBU to the LMA with suited CoA and HoA. To=20 > me the case does not really correspond to a revocation but more to=20 > regular behavior of MIP6/PMIP6. > Thoughts on this? [Ahmad] I guess I addressed this above in one of your questions. In general, I would like the MAG to send BRI since if the MAG support revocation, there is not much extra in doing that. However, I am sure this point needs the group consensus and we will address it at the proper time. =20 >=20 > [question] What is the need for Handoff timer? > I have in mind that you can let BU from sMAG expire in LMA and accept=20 > new BU from tMAG in LMA. When new BU is in LMA, data gets to MN=20 > through tMAG. In the meantime (handoff) data will try to get to MN=20 > through sMAG (no guarantee since MN might not be anymore on the sMAG=20 > link). [Ahmad] This is a tricky points. It is possible that the MAG would not be able sometimes to identify if the MN moved to another MAG or exited the network. In the case of MN exited the network, it is useful for the MAG to send revocation. However, in the case of inter-AGW handoff, the sMAG may skip sending BRI. However, as I said before, if the MAG sometimes is not certain what happened, then MAG MAY send a BRI anyway. In that case, we need the LMA to take an extra precaution before deleting the BCE. Assuming that BRI arrived at the LMA before the PBU form the tMAG. Also, we will have enough time to address the fine details of this scenario. >=20 > Bulk termination > ************ >=20 > [opinion] please use the term "bindings" instead of "sessions". [Ahmad] No problem. > [question] How is the HA address is provided in the BRI? As a specific > Mobility Option? Is this what you mean by Home Address Option? If so,=20 > is it the same option than the one used to sepcify the HoA in the BRI? > I guess a specific Mobility Option is required to distinguish HoA from > HA address. [Ahmad] I guess we can still use the HoA address. Since the HA address is already known to the MAG. But a new option is possible depending on group agreement. > [opinion] also note that this section introduces an additional=20 > semantic for the G bit (all bindings of a HA/LMA) that was not=20 > specified in the field semantic before. >=20 > MAG Operational summary > ********************* >=20 > [question] if MAG sends a BRI to LMA for maintenance purpose and uses=20 > the MAG IP address as the CoA address option (Mobility Option i=20 > presume), how does the LMA find the related bindings? I don't see a=20 > necessary relationship between MAG IP address and the CoA managed by=20 > the MAG. The MAG IP address is not necessarily stored on LMA side, is=20 > it? [Ahmad] Actually what I meant is the CoA. Now if the MAG happens to use several CoA, then we either specify multiple of them or use something else. TBD. >=20 > [opinion] i think that using the HNP in the PMIP6 binding management=20 > is not a good idea. Any binding can be identified by the couple (CoA,=20 > HoA). [Ahmad] According to PMIPv6 semantics, there is a possibility that the HA does not know the exact HoA for the MN. Using the HoA and CoA is very good. However, if the HoA is not available we need to use HNP but most probably in combination with CoA. > The identification of binding should be consistent in the draft. The=20 > usage of HNP is equivalent because the per-MN prefix model is used in > PMIPv6 for now. Should this change in the future, this would cause=20 > problems with your draft. [Ahmad] Well, I understand that but, please see the above comment. >=20 > Binding revocation signaling in global mobility > ********************************** >=20 > [question] Do you mean that revocation can be used to avoid unexpected > mobility service interruption? So, when a BRI is received because the=20 > user runs out of money, the user puts additional money and sends a BRA > with status "refunded" and the revocation process is relinquished? [Ahmad] In the case of prepaid, Notification should have been sent earlier to the user to refill its account. However, I foresee this scenario for the MN to ack and it may does whatever it needs and then try to register later. I do not see revocation being used in the semantics you mentioned. >=20 > [opinion] i disagree with the usage of BRI/BRA when returning home=20 > while this can be done using RFC 3775 as recommended. [Ahmad] Just in case some MNs do not send de-registration when returning home. If MN sends de-registration, then HA wont send revocation anyway. >=20 > Other points > ********* >=20 > -support of the revocation mechanism should be optional as this has=20 > been done in IPv4. That is the BU or PBU should be extended with a=20 > capability bit. HA/LMA should not send BRA for BU or PBU if MN/MAG=20 > does not support it. > -not clear if the draft allows a CN (Correspondant Node) to issue a=20 > BRI when RO is in effect (MIP6 case) =20 {Ahmad] This needs the group consensus and we can discuss during the protocol details. > -missing MN > Operational summary section to describe MIP6 MN behavior supported by=20 > the draft. [Ahmad] We will add that section. Thx. >=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 Mon Jun 11 13:50: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 1Hxo27-0000KO-K3; Mon, 11 Jun 2007 13:50:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxo26-0000KJ-5V for mip6@ietf.org; Mon, 11 Jun 2007 13:50:26 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxo24-0000Kk-TY for mip6@ietf.org; Mon, 11 Jun 2007 13:50: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 l5BHn4s12816; Mon, 11 Jun 2007 17:49: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] Comments on draft-muhanna-mip6-binding-revocation-01.txt Date: Mon, 11 Jun 2007 12:50:13 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B5F6C80@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437114D69C21@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Comments on draft-muhanna-mip6-binding-revocation-01.txt Thread-Index: AcenYzRUfZbiGnIPQj6yDLAFC28LIQE6+7SwAABXi8A= From: "Mohamed Khalil" To: "Ahmad Muhanna" , "Bruno Mongazon-Cazavet" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 Bruno, not clear if the draft allows a CN (Correspondant Node) to issue a=20 > BRI when RO is in effect (MIP6 case) =20 Mohamed>> can you elaborate more on why we need this feature. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 11 14:31: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 1HxofR-0006K1-JA; Mon, 11 Jun 2007 14:31:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxofQ-0006Jv-FW for mip6@ietf.org; Mon, 11 Jun 2007 14:31:04 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxofO-0000tA-5j for mip6@ietf.org; Mon, 11 Jun 2007 14:31:04 -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] AD review of draft-ietf-mip6-bootstrapping-integrated-dhc Date: Mon, 11 Jun 2007 11:31:01 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] AD review of draft-ietf-mip6-bootstrapping-integrated-dhc thread-index: AcesGmxsiFMzrzPtSKmWDKU5FwDAcAAOvzXw References: <466D2FC1.60006@piuha.net> From: "Vijay Devarapalli" To: "Jari Arkko" , X-Spam-Score: 1.1 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Jari,=20 > 1. The document assumes that there is communication between > the NAS and the DHCP server/relay parts in the visited > network. From what I can see, such communication is > only needed, however, if the assigned home agent information > is going to differ between mobile nodes in a certain > way. Specifically, if the assignment decision depends on > local criteria (load in different home agents, round-robin > status) and policy that does not differ between AAAHs > or mobile nodes, then no such communication is needed. The main focus of this document is to be able to assign home agents from different MSPs dynamically. The NAS should be able to dynamically figure out which MSP to contact (based on the MN's identity) and fetch the home agent information, and deliver that information to the mobile node. The assigned home agent information could even vary between two=20 mobile nodes that belong to the same MSP. Assigning home agents from the local network is an "add-on" feature. So the NAS - DHCP server/relay communication is very important. > Not having to assume co-location or communication > would simplify the implementation of this considerably. > This would also cover one important use case that I > can see, an access network that offers local home > agents without any specific additional agreements > or roaming services. >=20 > Has such a case been considered in the discussion? > Is it feasible to allow devices to implement > such a simplified mode of operation? Yes, this is possible. But we have to consider whether the mobile node necessarily wants this service from the visited network.=20 And it should be possible for the mobile node and the home agent in the visited network to be able to authenticate each other for sending binding updates.=20 Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 11 14:42: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 1Hxoq1-0004Xc-0Q; Mon, 11 Jun 2007 14:42:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxoq0-0004XJ-H5 for mip6@ietf.org; Mon, 11 Jun 2007 14:42:00 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxopy-0003BQ-7I for mip6@ietf.org; Mon, 11 Jun 2007 14:42:00 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D88AF19868B; Mon, 11 Jun 2007 21:41:56 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7CEA5198689; Mon, 11 Jun 2007 21:41:56 +0300 (EEST) Message-ID: <466D9774.5090504@piuha.net> Date: Mon, 11 Jun 2007 21:41:56 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] AD review of draft-ietf-mip6-bootstrapping-integrated-dhc References: <466D2FC1.60006@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 1.1 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Mobile IPv6 Mailing List , draft-ietf-mip6-bootstrapping-integrated-dhc@tools.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, > And it should be possible for the mobile node and the home agent > in the visited network to be able to authenticate each other for > sending binding updates. > Sure. But I don't see the problem in achieving that, even if the home agents are statically assigned in the local network. If the access authentication can be performed somehow, the mobility authentication should be possible too, e.g., with the same credentials and using IKEv2 EAP mode. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 11 14:48:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxovz-0004Qe-OS; Mon, 11 Jun 2007 14:48:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxovy-0004QY-3l for mip6@ietf.org; Mon, 11 Jun 2007 14:48:10 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxovw-0004H0-Rr for mip6@ietf.org; Mon, 11 Jun 2007 14:48:10 -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] AD review of draft-ietf-mip6-bootstrapping-integrated-dhc Date: Mon, 11 Jun 2007 11:48:07 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] AD review of draft-ietf-mip6-bootstrapping-integrated-dhc thread-index: AcesWDJVSo+DxPfCQCqbd3s8R9jLAAAAJTyw References: <466D2FC1.60006@piuha.net> <466D9774.5090504@piuha.net> From: "Vijay Devarapalli" To: "Jari Arkko" X-Spam-Score: 1.1 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Mobile IPv6 Mailing List , draft-ietf-mip6-bootstrapping-integrated-dhc@tools.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 > > And it should be possible for the mobile node and the home agent > > in the visited network to be able to authenticate each other for > > sending binding updates.=20 > > =20 >=20 > Sure. But I don't see the problem in achieving that, even if the > home agents are statically assigned in the local network. If > the access authentication can be performed somehow, the > mobility authentication should be possible too, e.g., > with the same credentials and using IKEv2 EAP mode. Right. But you had said something about "... without any specific additional agreements or roaming services." There is no issue,=20 protocol-wise, it is more of a deployment issue.=20 Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 11 15:50: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 1Hxpue-0003R9-6i; Mon, 11 Jun 2007 15:50:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxptr-00010g-AA; Mon, 11 Jun 2007 15:50:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxptq-0007Vp-Pf; Mon, 11 Jun 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id BD46D3290B; Mon, 11 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hxptq-00057c-LM; Mon, 11 Jun 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: Mon, 11 Jun 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-04.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-04.txt Pages : 20 Date : 2007-6-11 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-04.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-04.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-04.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-6-11124537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-hiopt-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-hiopt-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-11124537.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 Mon Jun 11 16:44: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 1Hxqkf-0003QR-QL; Mon, 11 Jun 2007 16:44:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxqkc-0003MF-2B; Mon, 11 Jun 2007 16:44:34 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hxqkb-0003GK-Qa; Mon, 11 Jun 2007 16:44:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id C11C0175EF; Mon, 11 Jun 2007 20:44:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hxqk7-0005kk-Hm; Mon, 11 Jun 2007 16:44:03 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 11 Jun 2007 16:44:03 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mip6@ietf.org Subject: [Mip6] Last Call: draft-ietf-mip6-bootstrapping-split (Mobile IPv6 bootstrapping in split scenario) to Proposed Standard X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The IESG has received a request from the Mobility for IPv6 WG (mip6) to consider the following document: - 'Mobile IPv6 bootstrapping in split scenario ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-06-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13262&rfc_flag=0 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 11 17:23: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 1HxrLy-0006sd-0O; Mon, 11 Jun 2007 17:23:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxrLw-0006my-Vq for mip6@ietf.org; Mon, 11 Jun 2007 17:23:08 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxrLv-00063y-Lx for mip6@ietf.org; Mon, 11 Jun 2007 17:23:08 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 2F16D90060 for ; Mon, 11 Jun 2007 17:23:00 -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 31014-16 for ; Mon, 11 Jun 2007 17:22:59 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Mon, 11 Jun 2007 17:22:59 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 17:23:05 -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 Date: Mon, 11 Jun 2007 17:22:52 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA17C@exchtewks2.starentnetworks.com> In-Reply-To: <466D8732.9090806@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-mip6-bootstrapping-integrated-dhc Thread-Index: AcesTn/4vmVYs7PYRP+2a23+asaFcgAHqlRg From: "Chowdhury, Kuntal" To: "Jari Arkko" X-OriginalArrivalTime: 11 Jun 2007 21:23:05.0257 (UTC) FILETIME=[B2FBB990:01C7AC6E] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 1.1 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Mobile IPv6 Mailing List , draft-ietf-mip6-bootstrapping-integrated-dhc@tools.ietf.org Subject: [Mip6] RE: AD review of draft-ietf-mip6-bootstrapping-integrated-dhc 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 Jari, Please see inline... > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Monday, June 11, 2007 12:33 PM > To: Chowdhury, Kuntal > Cc: draft-ietf-mip6-bootstrapping-integrated-dhc@tools.ietf.org; Mobile > IPv6 Mailing List > Subject: Re: AD review of draft-ietf-mip6-bootstrapping-integrated-dhc >=20 > Hi Kuntal, >=20 > > . In such a case, implementation of the > > options and procedures defined in [HIOPT] should suffice. > > > > ... > > [KC>] Simple [HIOPT] based bootstrapping of the local home agent address > > is feasible. It was discussed at the time of developing this solution. > > May be in the current I-D we should explicitly mention about the simpler > > mode of operation. > > >=20 > This would be enough for me to move the document forward. > Care to suggest text?=20 [KC>] May be it did not come clear, but I proposed the following text in my earlier email: " if assignment of home agent in the home MSP is not required by a deployment, collocation of NAS and the DHCP relay functions won't be necessary. In such a case, the implementation of the options and procedures defined in [HIOPT] should suffice. " > Please ensure that its clear to the reader > what the requirements are for an implementation that conforms > to this specification. >=20 [KC>] We have a section called "Assumptions", section 3. This was added during WGLC. May be we can add the proposed sentence to the assumption number c as a caveat: " c. DHCP relay and NAS are collocated or there is a mechanism to pass received AAA information from the NAS to the DHCP relay. " Do you suggest we rename this section and call it "Requirements of the solution" instead? > Jari >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 12 08: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 1Hy5va-0002PZ-Bn; Tue, 12 Jun 2007 08:56:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy5vZ-0002PR-Id for mip6@ietf.org; Tue, 12 Jun 2007 08:56:53 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy5vN-0000Pg-RH for mip6@ietf.org; Tue, 12 Jun 2007 08:56:53 -0400 Received: from rly20b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly20b.srv.mailcontrol.com (MailControl) with ESMTP id l5CCu8t4003388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Jun 2007 13:56:32 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly20b.srv.mailcontrol.com (MailControl) id l5CCtDEF030664 for mip6@ietf.org; Tue, 12 Jun 2007 13:55:13 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly20b-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l5CCt6QT030073; Tue, 12 Jun 2007 13:55:13 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 4232_593ce7d6_18e2_11dc_9932_0030482aac25; Tue, 12 Jun 2007 14:42:14 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007061214550229-1079608 ; Tue, 12 Jun 2007 14:55:02 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.136,BAYES_00: -1.665,TOTAL_SCORE: -1.529 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Tue, 12 Jun 2007 14:53:51 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: I-D ACTION:draft-ietf-mip6-hiopt-04.txt thread-index: Aces8Ec5JK3qqsOZSA+fheeeaPR8yA== To: Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB1C6420@lan-ex-02.panasonic.de> Date: Tue, 12 Jun 2007 14:54:31 +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.130 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: mip6@ietf.org Subject: [Mip6] RE: I-D ACTION:draft-ietf-mip6-hiopt-04.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, The draft looks much better now, however, I think I found one oversight in section 3.1, second last paragraph: "This type can be used to discover home agents that are hosted by a user's home domain or target MSP (as indicated by his/her NAI-based username -- user@HomeRealm). The Home Network Identifier field can be a home MSP or a MSP which has trust roaming relationship with the mobile node's home MSP." The sentence in brackets is wrong at this place IMO, since the target MSP can be different from the NAI's home realm. It should be after "home domain".=20 Furthermore, strictly speaking the trust relationship should be between target MSP and MSA (not home MSP), since there may be MSAs that do not provide mobility services (in which case there is no home MSP). The correct sentence should be as follows: "This type can be used to discover home agents that are hosted by a user's home=20 domain (MSA domain, as indicated by his/her NAI-based username -- user@HomeRealm) or by any target domain. The requested domain is specified in the Home Network Identifier field and can be a mobile node's home MSP or any MSP which has trust roaming relationship with the mobile node's MSA." BR, Kilian > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Montag, 11. Juni 2007 21:50 > To: i-d-announce@ietf.org > Cc: mip6@ietf.org > Subject: I-D ACTION:draft-ietf-mip6-hiopt-04.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-04.txt > Pages : 20 > Date : 2007-6-11 > =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. -------------------------------------------- Dr. Kilian Weniger Panasonic R&D Center Germany Monzastr. 4c, 63225 Langen, Germany phone: +49 (0)6103 766 137 fax: +49 (0)6103 766 166 e-mail: kilian.weniger@eu.panasonic.com -------------------------------------------- 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 Tue Jun 12 09:12: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 1Hy6An-0005Fe-Ob; Tue, 12 Jun 2007 09:12:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy6Am-0005FZ-Cy for mip6@ietf.org; Tue, 12 Jun 2007 09:12:36 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy6Al-00055g-4h for mip6@ietf.org; Tue, 12 Jun 2007 09:12:36 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E029E198689; Tue, 12 Jun 2007 16:12:33 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A0097198688; Tue, 12 Jun 2007 16:12:33 +0300 (EEST) Message-ID: <466E9BC2.9080105@piuha.net> Date: Tue, 12 Jun 2007 16:12:34 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] AD review of draft-ietf-mip6-bootstrapping-integrated-dhc References: <466D2FC1.60006@piuha.net> <466D9774.5090504@piuha.net> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 1.1 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Mobile IPv6 Mailing List , draft-ietf-mip6-bootstrapping-integrated-dhc@tools.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, > Right. But you had said something about "... without any specific > additional agreements or roaming services." There is no issue, > protocol-wise, it is more of a deployment issue. > Ah, sorry. You are right. I'm fine with this as long as we explain the issue in the document. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 12 09:12: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 1Hy6B2-0005Ll-9y; Tue, 12 Jun 2007 09:12:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy6B1-0005Ld-Qc for mip6@ietf.org; Tue, 12 Jun 2007 09:12:51 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy6B0-00057Z-0f for mip6@ietf.org; Tue, 12 Jun 2007 09:12:51 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6C464198689; Tue, 12 Jun 2007 16:12:49 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 22638198688; Tue, 12 Jun 2007 16:12:49 +0300 (EEST) Message-ID: <466E9BD2.5050108@piuha.net> Date: Tue, 12 Jun 2007 16:12:50 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Chowdhury, Kuntal" References: <7CCD07160348804497EF29E9EA5560D7024DA17C$0001@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024DA17C$0001@exchtewks2.starentnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 1.1 (+) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Mobile IPv6 Mailing List , draft-ietf-mip6-bootstrapping-integrated-dhc@tools.ietf.org Subject: [Mip6] Re: AD review of draft-ietf-mip6-bootstrapping-integrated-dhc 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, > [KC>] May be it did not come clear, but I proposed the following text in > my earlier email: > > " > if assignment of home agent in the home MSP is not required by a > deployment, collocation of NAS and the DHCP relay functions won't be > necessary. In such a case, the implementation of the options and > procedures defined in [HIOPT] should suffice. > " > OK. > >> Please ensure that its clear to the reader >> what the requirements are for an implementation that conforms >> to this specification. >> >> > [KC>] We have a section called "Assumptions", section 3. This was added > during WGLC. May be we can add the proposed sentence to the assumption > number c as a caveat: > > " > c. DHCP relay and NAS are collocated or there is a mechanism to pass > received AAA information from the NAS to the DHCP relay. > " > > Do you suggest we rename this section and call it "Requirements of the > solution" instead? > No, the issue is whether to claim conformance to your spec a device needs to have those interfaces or not. Perhaps you can say something on the lines of "A minimal implementation of this specification supports only the delivery of information from the DHCP server or relay through [HIOPT]. However, an implementation MAY also support assignment of home agent in MSP. In this case the NAS and relay parts need to be collocated, or they need to have means to communicate." Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 12 12:02: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 1Hy8om-0005DG-IA; Tue, 12 Jun 2007 12:02:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy8ol-00059N-P1 for mip6@ietf.org; Tue, 12 Jun 2007 12:02:03 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy8ol-0007sj-Dq for mip6@ietf.org; Tue, 12 Jun 2007 12:02:03 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 184A890051 for ; Tue, 12 Jun 2007 12:02:00 -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 27052-02 for ; Tue, 12 Jun 2007 12:01:59 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 12 Jun 2007 12:01:59 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 12:02:05 -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 Date: Tue, 12 Jun 2007 12:01:52 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA18D@exchtewks2.starentnetworks.com> In-Reply-To: <466E9BD2.5050108@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-mip6-bootstrapping-integrated-dhc Thread-Index: Aces82BUa8YukAmgQmaRVLUO8X642gAFwjaw From: "Chowdhury, Kuntal" To: "Jari Arkko" X-OriginalArrivalTime: 12 Jun 2007 16:02:05.0382 (UTC) FILETIME=[059DC660:01C7AD0B] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 1.1 (+) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Mobile IPv6 Mailing List , draft-ietf-mip6-bootstrapping-integrated-dhc@tools.ietf.org Subject: [Mip6] RE: AD review of draft-ietf-mip6-bootstrapping-integrated-dhc 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 Jari, > No, the issue is whether to claim conformance to your spec > a device needs to have those interfaces or not. Perhaps > you can say something on the lines of "A minimal implementation > of this specification supports only the delivery of information > from the DHCP server or relay through [HIOPT]. However, > an implementation MAY also support assignment of home > agent in MSP. In this case the NAS and relay parts need to be > collocated, or they need to have means to communicate." > I think home agent assignment in Home MSP is a very important aspect of the solution. For that matter, "MAY also support...." seems to be a rather weak statement. Can we use a SHOULD instead? BR, Kuntal > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Tuesday, June 12, 2007 8:13 AM > To: Chowdhury, Kuntal > Cc: draft-ietf-mip6-bootstrapping-integrated-dhc@tools.ietf.org; Mobile > IPv6 Mailing List > Subject: Re: AD review of draft-ietf-mip6-bootstrapping-integrated-dhc >=20 > Kuntal, >=20 > > [KC>] May be it did not come clear, but I proposed the following text in > > my earlier email: > > > > " > > if assignment of home agent in the home MSP is not required by a > > deployment, collocation of NAS and the DHCP relay functions won't be > > necessary. In such a case, the implementation of the options and > > procedures defined in [HIOPT] should suffice. > > " > > >=20 > OK. >=20 > > > >> Please ensure that its clear to the reader > >> what the requirements are for an implementation that conforms > >> to this specification. > >> > >> > > [KC>] We have a section called "Assumptions", section 3. This was added > > during WGLC. May be we can add the proposed sentence to the assumption > > number c as a caveat: > > > > " > > c. DHCP relay and NAS are collocated or there is a mechanism to pass > > received AAA information from the NAS to the DHCP relay. > > " > > > > Do you suggest we rename this section and call it "Requirements of the > > solution" instead? > > >=20 > No, the issue is whether to claim conformance to your spec > a device needs to have those interfaces or not. Perhaps > you can say something on the lines of "A minimal implementation > of this specification supports only the delivery of information > from the DHCP server or relay through [HIOPT]. However, > an implementation MAY also support assignment of home > agent in MSP. In this case the NAS and relay parts need to be > collocated, or they need to have means to communicate." >=20 > Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 12 13:55: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 1HyAai-0005CS-NJ; Tue, 12 Jun 2007 13:55:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyAah-00058g-Vi for mip6@ietf.org; Tue, 12 Jun 2007 13:55:39 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyAaf-0002jz-N6 for mip6@ietf.org; Tue, 12 Jun 2007 13:55:39 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 57E7C198691; Tue, 12 Jun 2007 20:55:36 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 06E2319868B; Tue, 12 Jun 2007 20:55:35 +0300 (EEST) Message-ID: <466EDE19.7080205@piuha.net> Date: Tue, 12 Jun 2007 20:55:37 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Chowdhury, Kuntal" References: <7CCD07160348804497EF29E9EA5560D7024DA18D$0001@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024DA18D$0001@exchtewks2.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 1.1 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Mobile IPv6 Mailing List , draft-ietf-mip6-bootstrapping-integrated-dhc@tools.ietf.org Subject: [Mip6] Re: AD review of draft-ietf-mip6-bootstrapping-integrated-dhc 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, > I think home agent assignment in Home MSP is a very important aspect of > the solution. For that matter, "MAY also support...." seems to be a > rather weak statement. Can we use a SHOULD instead? > Sure. As long as you are clear what is required, feel free to use any suitable keyword... Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 12 14:23: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 1HyB1u-0000QS-Ly; Tue, 12 Jun 2007 14:23:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyB1t-0000Nb-Mo for mip6@ietf.org; Tue, 12 Jun 2007 14:23:45 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyB1t-0002qR-A1 for mip6@ietf.org; Tue, 12 Jun 2007 14:23:45 -0400 Received: from [10.1.201.34] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 11:23:43 -0700 Message-ID: <466EE2AC.1070501@azairenet.com> Date: Tue, 12 Jun 2007 11:15:08 -0700 From: Vijay Devarapalli User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [Mip6] RE: AD review of draft-ietf-mip6-bootstrapping-integrated-dhc References: <7CCD07160348804497EF29E9EA5560D7024DA18D@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024DA18D@exchtewks2.starentnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2007 18:23:43.0953 (UTC) FILETIME=[CF28CC10:01C7AD1E] X-Spam-Score: 1.1 (+) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Mobile IPv6 Mailing List , draft-ietf-mip6-bootstrapping-integrated-dhc@tools.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 Chowdhury, Kuntal wrote: > Hi Jari, > >> No, the issue is whether to claim conformance to your spec >> a device needs to have those interfaces or not. Perhaps >> you can say something on the lines of "A minimal implementation >> of this specification supports only the delivery of information >> from the DHCP server or relay through [HIOPT]. However, >> an implementation MAY also support assignment of home >> agent in MSP. In this case the NAS and relay parts need to be >> collocated, or they need to have means to communicate." >> > > I think home agent assignment in Home MSP is a very important aspect of > the solution. For that matter, "MAY also support...." seems to be a > rather weak statement. Can we use a SHOULD instead? It has to be a 'MUST'. The main focus of the document is to still be able to assign a home agent from the MSP. Assigning a local home agent is an additional feature we have in the spec. Vijay > > BR, > Kuntal > > >> -----Original Message----- >> From: Jari Arkko [mailto:jari.arkko@piuha.net] >> Sent: Tuesday, June 12, 2007 8:13 AM >> To: Chowdhury, Kuntal >> Cc: draft-ietf-mip6-bootstrapping-integrated-dhc@tools.ietf.org; > Mobile >> IPv6 Mailing List >> Subject: Re: AD review of draft-ietf-mip6-bootstrapping-integrated-dhc >> >> Kuntal, >> >>> [KC>] May be it did not come clear, but I proposed the following > text in >>> my earlier email: >>> >>> " >>> if assignment of home agent in the home MSP is not required by a >>> deployment, collocation of NAS and the DHCP relay functions won't be >>> necessary. In such a case, the implementation of the options and >>> procedures defined in [HIOPT] should suffice. >>> " >>> >> OK. >> >>>> Please ensure that its clear to the reader >>>> what the requirements are for an implementation that conforms >>>> to this specification. >>>> >>>> >>> [KC>] We have a section called "Assumptions", section 3. This was > added >>> during WGLC. May be we can add the proposed sentence to the > assumption >>> number c as a caveat: >>> >>> " >>> c. DHCP relay and NAS are collocated or there is a mechanism to > pass >>> received AAA information from the NAS to the DHCP relay. >>> " >>> >>> Do you suggest we rename this section and call it "Requirements of > the >>> solution" instead? >>> >> No, the issue is whether to claim conformance to your spec >> a device needs to have those interfaces or not. Perhaps >> you can say something on the lines of "A minimal implementation >> of this specification supports only the delivery of information >> from the DHCP server or relay through [HIOPT]. However, >> an implementation MAY also support assignment of home >> agent in MSP. In this case the NAS and relay parts need to be >> collocated, or they need to have means to communicate." >> >> Jari > > > _______________________________________________ > 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 Jun 12 15:45: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 1HyCIx-0005sI-Ee; Tue, 12 Jun 2007 15:45:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCIw-0005sC-0a for mip6@ietf.org; Tue, 12 Jun 2007 15:45:26 -0400 Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyCIv-0003j0-Jt for mip6@ietf.org; Tue, 12 Jun 2007 15:45:25 -0400 Received: from [88.233.215.108] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1HyCIk1aEp-0001Zl; Tue, 12 Jun 2007 15:45:21 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" , "'Chowdhury, Kuntal'" Subject: RE: [Mip6] RE: AD review ofdraft-ietf-mip6-bootstrapping-integrated-dhc Date: Tue, 12 Jun 2007 22:45:01 +0300 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: AcetHtD5VbKD0JoZS6Cwqic0Wo8N0gACkC9Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <466EE2AC.1070501@azairenet.com> Message-ID: <0MKpCa-1HyCIk1aEp-0001Zl@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18wR06ORthnWXlOIjw55KBSijB6eEET2yb6Nwg GM1ol+LrFP79/p8Ypmm1jiXJ/XJa2gL7IIVDTgNQB2Prt5nk1U Z9NyCT2Jet2Hh1MOos9Bg== X-Spam-Score: 1.1 (+) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: 'Mobile IPv6 Mailing List' , draft-ietf-mip6-bootstrapping-integrated-dhc@tools.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 > It has to be a 'MUST'. The main focus of the document is to still be > able to assign a home agent from the MSP. Assigning a local home agent > is an additional feature we have in the spec. "Assigning local HA" is the default capability of draft-ietf-mip6-hiopt-04.txt. Through AAA plumbing, as described in draft-ietf-mip6-bootstrapping-integrated-04, now the HA delivered via DHCP can be from a remote network. Alper > > Vijay > > > > > BR, > > Kuntal > > > > > >> -----Original Message----- > >> From: Jari Arkko [mailto:jari.arkko@piuha.net] > >> Sent: Tuesday, June 12, 2007 8:13 AM > >> To: Chowdhury, Kuntal > >> Cc: draft-ietf-mip6-bootstrapping-integrated-dhc@tools.ietf.org; > > Mobile > >> IPv6 Mailing List > >> Subject: Re: AD review of draft-ietf-mip6-bootstrapping-integrated-dhc > >> > >> Kuntal, > >> > >>> [KC>] May be it did not come clear, but I proposed the following > > text in > >>> my earlier email: > >>> > >>> " > >>> if assignment of home agent in the home MSP is not required by a > >>> deployment, collocation of NAS and the DHCP relay functions won't be > >>> necessary. In such a case, the implementation of the options and > >>> procedures defined in [HIOPT] should suffice. > >>> " > >>> > >> OK. > >> > >>>> Please ensure that its clear to the reader > >>>> what the requirements are for an implementation that conforms > >>>> to this specification. > >>>> > >>>> > >>> [KC>] We have a section called "Assumptions", section 3. This was > > added > >>> during WGLC. May be we can add the proposed sentence to the > > assumption > >>> number c as a caveat: > >>> > >>> " > >>> c. DHCP relay and NAS are collocated or there is a mechanism to > > pass > >>> received AAA information from the NAS to the DHCP relay. > >>> " > >>> > >>> Do you suggest we rename this section and call it "Requirements of > > the > >>> solution" instead? > >>> > >> No, the issue is whether to claim conformance to your spec > >> a device needs to have those interfaces or not. Perhaps > >> you can say something on the lines of "A minimal implementation > >> of this specification supports only the delivery of information > >> from the DHCP server or relay through [HIOPT]. However, > >> an implementation MAY also support assignment of home > >> agent in MSP. In this case the NAS and relay parts need to be > >> collocated, or they need to have means to communicate." > >> > >> Jari > > > > > > _______________________________________________ > > 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 Jun 13 00:15: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 1HyKGM-00039q-V7; Wed, 13 Jun 2007 00:15:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyKGL-00033L-QN for mip6@ietf.org; Wed, 13 Jun 2007 00:15:17 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyKGL-0007hb-CW for mip6@ietf.org; Wed, 13 Jun 2007 00:15:17 -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 <0JJK008QC3TFAW@mailout2.samsung.com> for mip6@ietf.org; Wed, 13 Jun 2007 13:15:15 +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 <0JJK00B803TFMC@ms5.samsung.com> for mip6@ietf.org; Wed, 13 Jun 2007 13:15:15 +0900 (KST) Content-return: prohibited Date: Wed, 13 Jun 2007 04:15:15 +0000 (GMT) From: Heejin Jang To: Kilian Weniger Message-id: <6743998.1418621181708115497.JavaMail.weblogic@ep_ml26> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20070613041515496@heejin.jang X-MTR: 20070613041515496@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: 7aafa0432175920a4b3e118e16c5cb64 Cc: "mip6@ietf.org" Subject: [Mip6] Re: RE: I-D ACTION:draft-ietf-mip6-hiopt-04.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="===============1888682017==" Errors-To: mip6-bounces@ietf.org --===============1888682017== Content-return: prohibited Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 SGksIEtpbGlhbi4NClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLg0KV2UnbGwgcmVmbGVjdCB0aGVt Lg0KIA0KLSBCZXN0IFJlZ2FyZHMsIA0KSGVlamluLiANCiANCg0KLS0tLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tLS0NClNlbmRlciA6IEtpbGlhbiBXZW5pZ2VyPEtpbGlhbi5XZW5pZ2VyQGV1 LnBhbmFzb25pYy5jb20+DQpEYXRlICAgOiAyMDA3LTA2LTEyIDIxOjU0DQpUaXRsZSAgOiBSRTog SS1EIEFDVElPTjpkcmFmdC1pZXRmLW1pcDYtaGlvcHQtMDQudHh0DQoNCkhpIEhlZWppbiwNCg0K VGhlIGRyYWZ0IGxvb2tzIG11Y2ggYmV0dGVyIG5vdywgaG93ZXZlciwgSSB0aGluayBJIGZvdW5k IG9uZSBvdmVyc2lnaHQNCmluIHNlY3Rpb24gMy4xLCBzZWNvbmQgbGFzdCBwYXJhZ3JhcGg6DQoN CiAgICJUaGlzIHR5cGUNCiAgIGNhbiBiZSB1c2VkIHRvIGRpc2NvdmVyIGhvbWUgYWdlbnRzIHRo YXQgYXJlIGhvc3RlZCBieSBhIHVzZXImIzM5O3MgaG9tZQ0KICAgZG9tYWluIG9yIHRhcmdldCBN U1AgKGFzIGluZGljYXRlZCBieSBoaXMvaGVyIE5BSS1iYXNlZCB1c2VybmFtZSAtLQ0KICAgdXNl ckBIb21lUmVhbG0pLiBUaGUgSG9tZSBOZXR3b3JrIElkZW50aWZpZXIgZmllbGQgY2FuIGJlIGEg aG9tZSBNU1ANCiAgIG9yIGEgTVNQIHdoaWNoIGhhcyB0cnVzdCByb2FtaW5nIHJlbGF0aW9uc2hp cCB3aXRoIHRoZSBtb2JpbGUgbm9kZSYjMzk7cw0KICAgaG9tZSBNU1AuIg0KDQpUaGUgc2VudGVu Y2UgaW4gYnJhY2tldHMgaXMgd3JvbmcgYXQgdGhpcyBwbGFjZSBJTU8sIHNpbmNlIHRoZSB0YXJn ZXQNCk1TUCBjYW4gYmUgZGlmZmVyZW50IGZyb20gdGhlIE5BSSYjMzk7cyBob21lIHJlYWxtLiBJ dCBzaG91bGQgYmUgYWZ0ZXIgImhvbWUNCmRvbWFpbiIuIA0KDQpGdXJ0aGVybW9yZSwgc3RyaWN0 bHkgc3BlYWtpbmcgdGhlIHRydXN0IHJlbGF0aW9uc2hpcCBzaG91bGQgYmUgYmV0d2Vlbg0KdGFy Z2V0IE1TUCBhbmQgTVNBIChub3QgaG9tZSBNU1ApLCBzaW5jZSB0aGVyZSBtYXkgYmUgTVNBcyB0 aGF0IGRvIG5vdA0KcHJvdmlkZSBtb2JpbGl0eSBzZXJ2aWNlcyAoaW4gd2hpY2ggY2FzZSB0aGVy ZSBpcyBubyBob21lIE1TUCkuIFRoZQ0KY29ycmVjdCBzZW50ZW5jZSBzaG91bGQgYmUgYXMgZm9s bG93czoNCg0KICAgIlRoaXMgdHlwZQ0KICAgY2FuIGJlIHVzZWQgdG8gZGlzY292ZXIgaG9tZSBh Z2VudHMgdGhhdCBhcmUgaG9zdGVkIGJ5IGEgdXNlciYjMzk7cyBob21lIA0KICAgZG9tYWluIChN U0EgZG9tYWluLCBhcyBpbmRpY2F0ZWQgYnkgaGlzL2hlciBOQUktYmFzZWQgdXNlcm5hbWUgLS0N CiAgIHVzZXJASG9tZVJlYWxtKSBvciBieSBhbnkgdGFyZ2V0IGRvbWFpbi4gVGhlIHJlcXVlc3Rl ZCBkb21haW4gaXMNCnNwZWNpZmllZCBpbiB0aGUgSG9tZSBOZXR3b3JrIElkZW50aWZpZXIgZmll bGQgYW5kIGNhbiBiZSBhIG1vYmlsZQ0Kbm9kZSYjMzk7cyBob21lIE1TUCBvciBhbnkgTVNQIHdo aWNoIGhhcyB0cnVzdCByb2FtaW5nIHJlbGF0aW9uc2hpcCB3aXRoIHRoZQ0KbW9iaWxlIG5vZGUm IzM5O3MgTVNBLiINCg0KQlIsDQoNCktpbGlhbg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogSW50ZXJuZXQtRHJhZnRzQGlldGYub3JnIFttYWlsdG86SW50ZXJuZXQt RHJhZnRzQGlldGYub3JnXSANCj4gU2VudDogTW9udGFnLCAxMS4gSnVuaSAyMDA3IDIxOjUwDQo+ IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4gQ2M6IG1pcDZAaWV0Zi5vcmcNCj4gU3ViamVj dDogSS1EIEFDVElPTjpkcmFmdC1pZXRmLW1pcDYtaGlvcHQtMDQudHh0IA0KPiANCj4gQSBOZXcg SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh ZnRzIA0KPiBkaXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUg TW9iaWxpdHkgZm9yIElQdjYgV29ya2luZyANCj4gR3JvdXAgb2YgdGhlIElFVEYuDQo+IA0KPiAg ICAgVGl0bGUgICAgICAgIDogREhDUCBPcHRpb24gZm9yIEhvbWUgSW5mb3JtYXRpb24gDQo+IERp c2NvdmVyeSBpbiBNSVB2Ng0KPiAgICAgQXV0aG9yKHMpICAgIDogSC4gSmFuZywgZXQgYWwuDQo+ ICAgICBGaWxlbmFtZSAgICA6IGRyYWZ0LWlldGYtbWlwNi1oaW9wdC0wNC50eHQNCj4gICAgIFBh Z2VzICAgICAgICA6IDIwDQo+ICAgICBEYXRlICAgICAgICA6IDIwMDctNi0xMQ0KPiAgICAgDQo+ IFRoaXMgZHJhZnQgZGVmaW5lcyBhIERIQ1AtYmFzZWQgc2NoZW1lIHRvIGVuYWJsZSBkeW5hbWlj IGRpc2NvdmVyeSBvZg0KPiAgICBNb2JpbGUgSVB2NiBob21lIGFnZW50IGFkZHJlc3MsIGhvbWUg YWdlbnQgRlFETiBhbmQgaG9tZSANCj4gc3VibmV0LiAgTmV3DQo+ICAgIERIQ1Agb3B0aW9ucyBh cmUgZGVmaW5lZCB0byBjYXJyeSB0aGUgaW5mb3JtYXRpb24gZnJvbSBhIA0KPiBESENQIHNlcnZl cg0KPiAgICB0byB0aGUgREhDUCBjbGllbnQgcnVubmluZyBvbiB0aGUgbW9iaWxlIG5vZGUuDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpEci4gS2lsaWFu IFdlbmlnZXINClBhbmFzb25pYyBSJkQgQ2VudGVyIEdlcm1hbnkNCk1vbnphc3RyLiA0YywgNjMy MjUgTGFuZ2VuLCBHZXJtYW55DQpwaG9uZTogICs0OSAoMCk2MTAzIDc2NiAxMzcNCmZheDogICAg KzQ5ICgwKTYxMDMgNzY2IDE2Ng0KZS1tYWlsOiBraWxpYW4ud2VuaWdlckBldS5wYW5hc29uaWMu Y29tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNClBh bmFzb25pYyBSJkQgQ2VudGVyIEdlcm1hbnkgR21iSA0KNjMyMjUgTGFuZ2VuLCBIZXNzZW4sIEdl cm1hbnkNClJlZzogQUcgT2ZmZW5iYWNoIChIZXNzZW4pIEhSQiAzMzk3NA0KTWFuYWdpbmcgRGly ZWN0b3I6IFRob21hcyBNaWNrZQ0KDQoNCg0KDQo= --===============1888682017== 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 --===============1888682017==-- From mip6-bounces@ietf.org Wed Jun 13 08:18: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 1HyRnm-0007QS-Lq; Wed, 13 Jun 2007 08:18:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyRnl-0007Lx-0Z for mip6@ietf.org; Wed, 13 Jun 2007 08:18:17 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyRnk-0003o1-JU for mip6@ietf.org; Wed, 13 Jun 2007 08:18:16 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 06D46198691; Wed, 13 Jun 2007 15:18:16 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C0A2719868A; Wed, 13 Jun 2007 15:18:15 +0300 (EEST) Message-ID: <466FE089.2040303@piuha.net> Date: Wed, 13 Jun 2007 15:18:17 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: draft-ietf-mip6-cn-ipsec@tools.ietf.org, Mobile IPv6 Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Mip6] Progressing draft-ietf-mip6-cn-ipsec? 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 draft has been long enough in the same state. I would like to move it forward or decide what else to do with it. There are two types of issues in it, the first being about the text. In order to move forward, two problems in the text need to be corrected. I posted text suggestions in [1] but other suggestions are fine too. There is not necessarily any need to update the document itself, the suggestions could go into so called RFC Editor notes and the document could move forward more or less immediately, if we want to. But I need the authors to tell me what changes to apply. The second issue is the standard level applied for the specification. I suggested Experimental. I would be willing to designate it as Proposed Standard as well, but for that I think we need to have some more evidence that it needs to be a recommended IETF approach, something to be relatively widely implemented, etc. The reason I'm asking for this is that while this is potentially very useful, it is also an alternate mechanism to what already exists in RFCs. Is someone going to deploy this? Are there technical reasons that lead us into believing that it will be very useful in certain network contexts? I'd like to know what to do by June 27th, i.e., in two weeks. At that time I need to have either new text or agreement that text in [1] is OK, and I need some feedback on the standard level question. Jari [1] http://www1.ietf.org/mail-archive/web/mip6/current/msg05925.html _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 13 11:13: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 1HyUXD-0004lc-I2; Wed, 13 Jun 2007 11:13:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUXA-0004g3-EP; Wed, 13 Jun 2007 11:13:20 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyUX9-0000WN-SV; Wed, 13 Jun 2007 11:13:20 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 7389F26ECB; Wed, 13 Jun 2007 15:13:19 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HyUX9-0006Rr-C1; Wed, 13 Jun 2007 11:13:19 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 13 Jun 2007 11:13:19 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: mip6 mailing list , mip6 chair , Internet Architecture Board , RFC Editor Subject: [Mip6] Document Action: 'Problem Statement: Dual Stack Mobility' to Informational RFC 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 The IESG has approved the following document: - 'Problem Statement: Dual Stack Mobility ' as an Informational RFC This document is the product of the Mobility for IPv6 Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-dsmip-problem-03.txt Technical Summary This draft discusses the issues associated with mobility management for dual stack mobile nodes. Currently, two mobility management protocols are defined for IPv4 and IPv6. Deploying both in a dual stack mobile node introduces a number of inefficiencies. Deployment and operational issues motivate the use of a single mobility management protocol. This draft discusses such motivations. The draft also hints on how the current MIP4 and MIP6 protocols could be extended so that they can support mobility management for a dual stack node. Working Group Summary This I-D was initially produced as a problem statement for the MIP6 WG. However subsequently it was noted that it applied to MIP4 as well. Hence the I-D is now considered as being applicable to the MIP4 and MIP6 WGs. There is consensus behind this document and the need to address the problem. Protocol Quality This specification has been reviewed by Jari Arkko for the IESG. Note to RFC Editor Please ignore the "Intended status: Standards Track" header in the document. The intended status is really Informational RFC. Please change the following in Section 4.3: OLD: possible to optimize some of these processes. NEW: possible to rely on one set of set common credentials. Similarly, change the contents of Section 4.2 to the following: As mentioned above, a node that is IPv4 and IPv6 capable must also be MIPv4 and MIPv6 capable to roam within the Internet. The ability to employ both IP versions from one mobility protocol makes it possible to implement just that one protocol, assuming the protocol choice is known. However, in situations where the mobile node must be capable of working in any network it may still need two protocols. And change the contents of Section 4.5 to this: The IETF has standardized a number of transition mechanisms to allow networks and end nodes to gain IPv6 connectivity while the Internet is migrating from IPv4 to IPv6. However, while some transition mechanisms can be combined with Mobile IPv4 or Mobile IPv6, none of the known mechanisms have been shown to assist with the issues described in this document. In Section 4.1 title, change "impossibility" to "Impossibility". Please remove Section 8 prior to publication as an RFC. Please remove Section 1 and the associated reference (the document does not use RFC 2119 terms). Please change the following in Section 5: 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: 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. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 13 13:03: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 1HyWG2-0005xm-KN; Wed, 13 Jun 2007 13:03:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyWG1-0005xd-Gz for mip6@ietf.org; Wed, 13 Jun 2007 13:03:45 -0400 Received: from cluster-d.mailcontrol.com ([217.69.20.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyWFz-0007l0-Rk for mip6@ietf.org; Wed, 13 Jun 2007 13:03:45 -0400 Received: from rly48d.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly48d.srv.mailcontrol.com (MailControl) with ESMTP id l5DH2lAP013148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Jun 2007 18:03:39 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly48d.srv.mailcontrol.com (MailControl) id l5DH2eT9012575 for mip6@ietf.org; Wed, 13 Jun 2007 18:02:40 +0100 Received: from cameurexb01.EUROPE.ROOT.PRI ([62.189.241.200]) by rly48d-eth0.srv.mailcontrol.com (envelope-sender Ji.Zhang@csr.com) (MIMEDefang) with ESMTP id l5DH2d9V012522; Wed, 13 Jun 2007 18:02:39 +0100 (BST) 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" Subject: RE: [Mip6] I-D ACTION:draft-korhonen-mip6-service-02.txt Date: Wed, 13 Jun 2007 18:01:15 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] I-D ACTION:draft-korhonen-mip6-service-02.txt Thread-Index: Acet2eL87cO0ExV3Q7GfQGiV/GgjtAAADBvQ From: "Ji Zhang" To: X-Scanned-By: MailControl A-07-07-10 (www.mailcontrol.com) on 10.68.1.158 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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 Jouni, Just come across this I-D... IMHO, it might be good if there are some more concrete scenarios/examples to show why this option is necessary or works better (e.g. reduce additional signaling?). BTW, does one Service Selection Mobility Option encode a single identifier or allow multiple as well? If an MN wants to change the service or the set of services the home agent is offering, would a deregistration be required before re-registration(s)? Cheers, Ji ----- Original Message -----=20 From: To: Sent: Friday, June 08, 2007 6:42 AM Subject: [Mip6] FW: I-D ACTION:draft-korhonen-mip6-service-02.txt FYI.. The I-D on service selection for MIP6 has been revised based on the received comments & feedback. Cheers, Jouni > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Thursday, June 07, 2007 10:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-korhonen-mip6-service-02.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Service Selection for Mobile IPv6 > Author(s) : J. Korhonen, et al. > Filename : draft-korhonen-mip6-service-02.txt > Pages : 9 > Date : 2007-6-7 > > In some Mobile IPv6 deployments identifying the mobile node or the > mobility service subscriber is not enough to distinguish between > multiple services possibly provisioned to the said mobile node and > its mobility service subscription. A capability to > specify different > services in addition to the mobile node identity can be > leveraged to > provide flexibility for mobility service providers on provisioning > > multiple services to one mobility service subscription. This > document describes a Service Selection Mobility Option for both > conventional Mobile IPv6 or Proxy Mobile IPv6 that is intended to > assist home agents to make a specific service selection for the > mobility service subscription during the binding update procedure. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-korhonen-mip6-service-02.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-korhonen-mip6-service-02.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-korhonen-mip6-service-02.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 To report this email as spam click https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg=3D=3D DVRCyMKb4W2rVPx0tCfiV5ruvelr6GGHlrhkKDkjC48R5jZ8u+yuWgmclsxI18lIwgo2iePp TOxHdM3SfspoO2Ssycnc+6w8cgYCSu4!ZYbjtL0Y78QDCjIsKr6JDmowvSNRHGLgFBgW0a5o rvq5o5c2UheNrFfQqvV2TFd3OCSGuAx0XL3InfQ . _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 14 07:55: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 1Hynvc-0001Lu-Bh; Thu, 14 Jun 2007 07:55:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hynvb-0001Lb-AG for mip6@ietf.org; Thu, 14 Jun 2007 07:55:51 -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 1HynvZ-0001Lr-Ro for mip6@ietf.org; Thu, 14 Jun 2007 07:55:51 -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 l5EBtBUY021392; Thu, 14 Jun 2007 14:55:48 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 14:55: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, 14 Jun 2007 06:55:43 -0500 Received: from 10.162.252.107 ([10.162.252.107]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 14 Jun 2007 11:55:42 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 14 Jun 2007 06:55:46 -0500 From: Basavaraj Patil To: Mobile IPv6 Mailing List Message-ID: Thread-Topic: Note: Review of integrated bootstrap ID and WG LC of DHCP options I-D in DHC WG Thread-Index: AceuevE+L8VyRhpuEdyFIwARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Jun 2007 11:55:43.0760 (UTC) FILETIME=[EFE8C100:01C7AE7A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: dhc-chairs@tools.ietf.org, mip6-chairs@tools.ietf.org Subject: [Mip6] Note: Review of integrated bootstrap ID and WG LC of DHCP options I-D in DHC WG 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 MIP6 WG documents: 1. MIP6-bootstrapping for the Integrated Scenario 2. DHCP Option for Home Information Discovery in MIPv6 have completed WG LC in the MIP6 WG. The above I-Ds will be progressed in parallel as they are companion documents and need to be read together. The DHC WG will review the DHCP options being specified and will do a WG LC in the DHC WG. Revision 5 of the I-D draft-ietf-mip6-hiopt has been submitted by the authors and should be posted soon. -Raj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 14 08:30: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 1HyoT4-0006ny-Vh; Thu, 14 Jun 2007 08:30:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyoT4-0006nk-5b for mip6@ietf.org; Thu, 14 Jun 2007 08:30:26 -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 1HyoT2-00024M-NO for mip6@ietf.org; Thu, 14 Jun 2007 08:30:26 -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 l5ECU346027407; Thu, 14 Jun 2007 15:30:21 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 15:30:20 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 07:30:18 -0500 Received: from 10.162.252.107 ([10.162.252.107]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 14 Jun 2007 12:30:17 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 14 Jun 2007 07:30:21 -0500 From: Basavaraj Patil To: Mobile IPv6 Mailing List Message-ID: Thread-Topic: FYI: On vacation Thread-Index: Aceuf8YKBFAH3RpzEdyFIwARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Jun 2007 12:30:18.0457 (UTC) FILETIME=[C4866490:01C7AE7F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Gopal Dommety Subject: [Mip6] FYI: On vacation 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, I will be on vacation with almost no email access from Jun 17 to Jul 17th. The preparation for the MIP6 meeting at IETF69 as well as all MIP6 related issues will be handled by Gopal. Please address all requests and concerns to Gopal Dommety for the next few weeks. -Raj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 14 18:50:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyy8w-0006JC-4f; Thu, 14 Jun 2007 18:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyy8h-00067c-RF; Thu, 14 Jun 2007 18:50:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyy8g-0005mX-IU; Thu, 14 Jun 2007 18:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 703D526EE5; Thu, 14 Jun 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hyy8g-0005Hi-BY; Thu, 14 Jun 2007 18: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: Thu, 14 Jun 2007 18: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-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 : DHCP Option for Home Information Discovery in MIPv6 Author(s) : H. Jang, et al. Filename : draft-ietf-mip6-hiopt-05.txt Pages : 21 Date : 2007-6-14 This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home network information. New DHCP options are defined which allow a mobile node to request the home agent IP address, FQDN, or home subnet prefix and obtain it via the DHCP response. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-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-hiopt-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-hiopt-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-6-14151231.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-hiopt-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-hiopt-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-14151231.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 Sun Jun 17 09:32: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 1Hzurk-0002dS-Dk; Sun, 17 Jun 2007 09:32:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzuri-0002dL-P5 for mip6@ietf.org; Sun, 17 Jun 2007 09:32:26 -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 1Hzurg-0007L4-8O for mip6@ietf.org; Sun, 17 Jun 2007 09:32:26 -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 l5HDWKqt020694 for ; Sun, 17 Jun 2007 16:32:22 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 16:32:21 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 08:32:20 -0500 Received: from 10.241.58.45 ([10.241.58.45]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Sun, 17 Jun 2007 13:32:19 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Sun, 17 Jun 2007 08:32:28 -0500 From: Basavaraj Patil To: Mobile IPv6 Mailing List Message-ID: Thread-Topic: Nomcom anouncement Thread-Index: Acew4/K+MVK6XhzXEdy0DgARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Jun 2007 13:32:20.0228 (UTC) FILETIME=[EE1CD440:01C7B0E3] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Mip6] Nomcom anouncement 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, Nomcom is seeking volunteers. The announcement has been sent on the IETF-announce mailing list. Criteria for volunteering and details are at: https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1234 If you qualify and wish to serve, please volunteer. -Raj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jun 17 13:53: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 1HzywZ-0008VS-0C; Sun, 17 Jun 2007 13:53:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzywY-0008VN-1J for mip6@ietf.org; Sun, 17 Jun 2007 13:53:42 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzywV-0007zx-Mt for mip6@ietf.org; Sun, 17 Jun 2007 13:53:42 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 10:53:38 -0700 Message-ID: <4675751F.9000608@azairenet.com> Date: Sun, 17 Jun 2007 10:53:35 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jun 2007 17:53:38.0796 (UTC) FILETIME=[6F4472C0:01C7B108] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Mip6] Deprecating Routing Header Type 0 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 folks, There is a discussion going on in the IPv6 WG about deprecating the use of Routing Header Type 0. See the following URL for the discussion on this topic. http://www1.ietf.org/mail-archive/web/ipv6/current/msg07634.html For more information on security threats due to Routing Header Type 0, see http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf. It is an interesting read. Some folks are suggesting "knee-jerk" reactions of blocking all messages with a routing header in them. This would of course break MIPv6. MIPv6 uses Router Header Type 2. It would be especially bad if the firewalls start blocking them instead of the hosts or the routers that receive such messages. Comments? Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jun 17 20:51: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 1I05SZ-0001vE-69; Sun, 17 Jun 2007 20:51:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I05SX-0001v6-Ug; Sun, 17 Jun 2007 20:51:09 -0400 Received: from omta03sl.mx.bigpond.com ([144.140.92.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I05SW-00069f-3Q; Sun, 17 Jun 2007 20:51:09 -0400 Received: from oaamta03sl.mx.bigpond.com ([124.191.178.123]) by omta03sl.mx.bigpond.com with ESMTP id <20070618005104.TTWP28147.omta03sl.mx.bigpond.com@oaamta03sl.mx.bigpond.com>; Mon, 18 Jun 2007 00:51:04 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta03sl.mx.bigpond.com with ESMTP id <20070618005103.EHGX24129.oaamta03sl.mx.bigpond.com@PC20005>; Mon, 18 Jun 2007 00:51:03 +0000 From: "Hesham Soliman" To: "'Mobile IPv6 Mailing List'" Date: Mon, 18 Jun 2007 10:50:57 +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: AcexQrtnp4iPHSFpQ8KvK/VonMv5SA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Message-Id: <20070618005103.EHGX24129.oaamta03sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: nemo@ietf.org Subject: [Mip6] DSMIP progress report 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, There is a couple of drafts in this WG on DSMIP and this is a quick progress report on them. The problem statement was approved recently by Jari and has moved forward with a couple of notes to the RFC editor. The DSMIPv6 solution draft (for MIP6 and nemo) is currently waiting on Jari's review with the chairs. I discussed this with the AD and chairs and we will move forward as soon as we resolve the concensus issues that were raised while addressing issue 93. As soon as I hear back from Jari/chairs, I'll submit the new revision. We're hoping to get to WGLC by Chicago. Thanks, Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 18 06:28: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 1I0ESs-0008Fx-0P; Mon, 18 Jun 2007 06:28:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ESq-0008Fn-0S for mip6@ietf.org; Mon, 18 Jun 2007 06:28:04 -0400 Received: from py-out-1112.google.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ESm-0007oH-8N for mip6@ietf.org; Mon, 18 Jun 2007 06:28:03 -0400 Received: by py-out-1112.google.com with SMTP id a25so441065pyi for ; Mon, 18 Jun 2007 03:27:59 -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:cc:in-reply-to:mime-version:content-type:references; b=RC+rrHoN6JGxwjAIeaLDQCoGj29ggYTWD29FRP9I/KublniMegFehBzivIS+2HOIZfK3WwdgYPFx2js20iL+aUhSgGiX7Hu1DYY6ieQ+jNaLR1yi1mf5xMT4EjwvdteAbOiLDE6fL2ZIKgAix6unbqY0+IIaSnzhP9tttBz9Avg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=owuOR1LT7icSHcERR+r8gIcWY20bKVckfAb3vc/Z/mS7F9PM0O39hDymPfK5y0fYVOLOMiXOpJ+2ahS/LH9v+euvD1ujz7rby/lGNP3RmkGzjAfZoGPmWZsQFLlP1wVeckdAn03zGvqCeAqG3AoSm5PftBnFvfWvb3ST3IpaFII= Received: by 10.65.234.2 with SMTP id l2mr3108897qbr.1182162479105; Mon, 18 Jun 2007 03:27:59 -0700 (PDT) Received: by 10.64.76.16 with HTTP; Mon, 18 Jun 2007 03:27:59 -0700 (PDT) Message-ID: Date: Mon, 18 Jun 2007 19:27:59 +0900 From: "Jong-Hyouk Lee" To: "Behcet Sarikaya" Subject: Re: VS: Re: [Mip6] Dynamic HoA assignment In-Reply-To: <588112.1618.qm@web84112.mail.mud.yahoo.com> MIME-Version: 1.0 References: <588112.1618.qm@web84112.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 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: , Content-Type: multipart/mixed; boundary="===============1713674964==" Errors-To: mip6-bounces@ietf.org --===============1713674964== Content-Type: multipart/alternative; boundary="----=_Part_14350_33399588.1182162479070" ------=_Part_14350_33399588.1182162479070 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear colleague. I marvel that Europe has been deploying MIPv6. Could you provide more detail information about the MIPv6 deployment in Europe? Cheers. On 4/17/07, Behcet Sarikaya wrote: > > Jean-Michel, it is good to hear that MIP6 is being deployed in Europe. > > Regards, > > Behcet > > > ----- Original Message ---- > From: Jean-Michel Combes > To: jouni.korhonen@teliasonera.com > Cc: mip6@ietf.org; heejin.jang@samsung.com > Sent: Monday, April 16, 2007 5:22:22 AM > Subject: Re: VS: Re: [Mip6] Dynamic HoA assignment > > Hi Jouni, > > 2007/4/13, jouni.korhonen@teliasonera.com >: > > Hi Jean, > > > > I doubt the the fw rules (or other filtering) would be based on HoA, > > Why not? > IMHO, this is the more logical: > - the HoA is the more 'permanent' IP address for a MN which is needed > for the stateful function of a FW > - the HoA is owned by the operator and so the security administrator > is aware of them and can set up the security policy easily > - the MIPv6 aware FWs I have tested work with HoA policy based > > > at least not for BUs. Of course it is up to the operator's deployment > but I would not generalize.. > > I agree on this point. But this is just an advertisement in the case > where security policy would be based on HoAs. > > Best regards. > > JMC. > > > > > /jouni > > > > [snip] > > > > The second issue is that, normally, security policy (i.e. filtering > > rules) at the border of an administrative domain (i.e. HA's domain > > here) should be based on HoA. If the BU has HoA=0::0, the packet > > should be rejected. > > > > Best regards. > > > > JMC. > > > > > > > > The intent is to allow the MN to send a BU with HoA=0:0 only in the > case > > > when IPsec is not used between the MN and HA (i.e 4285 mode). > > > > > > -Raj > > > > > > > > > > > > > > > On 4/13/07 12:22 AM, "ext Chowdhury, Kuntal" > > > wrote: > > > > > > > IPv6CP is used to negotiate the IID only which helps in producing > the > > > > link local address. RS/RA or DHCPv6 is used to configure the global > > > > scope address. > > > > > > > > -Kuntal > > > > > > > > > > > >> -----Original Message----- > > > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > > >> Sent: Thursday, April 12, 2007 2:07 PM > > > >> To: Alper Yegin > > > >> Cc: mip6@ietf.org; heejin.jang@samsung.com > > > >> Subject: Re: [Mip6] Dynamic HoA assignment > > > >> > > > >> Alper Yegin wrote: > > > >>>> The base PMIPv6 protocol assumes that the home prefix is sent > > > >>>> to the mobile node using a router advertisement and then the > > > >>>> mobile node auto-configures a home address from this prefix. > > > >>> > > > >>> Isn't an IPv6 host in charge of whether it uses address > > > >> autoconfiguration or > > > >>> DHCP? If so, PMIPv6 spec shall accommodate that, assuming it does > > > > not > > > >> want > > > >>> to dictate any particular behaviour on the hosts. > > > >> > > > >> 2461bis says > > > >> > > > >> Router Advertisements (and per-prefix flags) allow routers to > > > > inform > > > >> hosts how to perform Address Autoconfiguration. For example, > > > > routers > > > >> can specify whether hosts should use DHCPv6 and/or > > > >> autonomous (stateless) address configuration. > > > >> > > > >> Stateful address configuration is not mandatory to support. > > > >> RFC 4294 says > > > >> > > > >> Stateful Address Autoconfiguration MAY be supported. > > > >> > > > >> But I do agree DHCPv6 could be used between the mobile node > > > >> and the MAG (Mobile Access Gateway). > > > >> > > > >> However, the address configuration for PMIPv6 depends to a > > > >> large extent on what kind of link layer is used between the > > > >> mobile node and the MAG. If the link layer is PPP, for e.g., > > > >> IPv6CP is used. If the link layer is an IPsec tunnel then > > > >> IKEv2 configuration payloads are used. The PMIPv6 protocol > > > >> does consider this and has some text addressing this. > > > >> > > > >> Anyway, this discussion needs to happen on the NETLMM > > > >> mailing list. > > > >> > > > >> Vijay > > > >> > > > >> _______________________________________________ > > > >> Mip6 mailing list > > > >> Mip6@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > _______________________________________________ > > > 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 > > -- Internet Management Technology Lab, Sungkyunkwan University. Jong-Hyouk Lee. #email: jonghyouk (at) gmail (dot) com #webpage: http://www.hurryon.org ------=_Part_14350_33399588.1182162479070 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Dear colleague.
 
I marvel that Europe has been deploying MIPv6. Could you provide more detail information about the MIPv6 deployment in Europe?
 
Cheers.

 
On 4/17/07, Behcet Sarikaya <behcetsarikaya@yahoo.com> wrote:
Jean-Michel, it is good to hear that MIP6 is being deployed in Europe.
 
Regards,
 
Behcet

 
----- Original Message ----
From: Jean-Michel Combes < jeanmichel.combes@gmail.com>
To: jouni.korhonen@teliasonera.com
Cc: mip6@ietf.org; heejin.jang@samsung.com
Sent: Monday, April 16, 2007 5:22:22 AM
Subject: Re: VS: Re: [Mip6] Dynamic HoA assignment

Hi Jouni,

2007/4/13, jouni.korhonen@teliasonera.com < jouni.korhonen@teliasonera.com>:
> Hi Jean,
>
> I doubt the the fw rules (or other filtering) would be based on HoA,

Why not?
IMHO, this is the more logical:
- the HoA is the more 'permanent' IP address for a MN which is needed
for the stateful function of a FW
- the HoA is owned by the operator and so the security administrator
is aware of them and can set up the security policy easily
- the MIPv6 aware FWs I have tested work with HoA policy based

>  at least not for BUs. Of course it is up to the operator's deployment but I would not generalize..

I agree on this point. But this is just an advertisement in the case
where security policy would be based on HoAs.

Best regards.

JMC.

>
> /jouni
>
> [snip]
>
> The second issue is that, normally, security policy (i.e. filtering
> rules) at the border of an  administrative domain ( i.e. HA's domain
> here) should be based on HoA. If the BU has HoA=0::0, the packet
> should be rejected.
>
> Best regards.
>
> JMC.
>
> >
> > The intent is to allow the MN to send a BU with HoA=0:0 only in the case
> > when IPsec is not used between the MN and HA (i.e 4285 mode).
> >
> > -Raj
> >
> >
> >
> >
> > On 4/13/07 12:22 AM, "ext Chowdhury, Kuntal"
> > <kchowdhury@starentnetworks.com> wrote:
> >
> > > IPv6CP is used to negotiate the IID only which helps in producing the
> > > link local address. RS/RA or DHCPv6 is used to configure the global
> > > scope address.
> > >
> > > -Kuntal
> > >
> > >
> > >> -----Original Message-----
> > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]
> > >> Sent: Thursday, April 12, 2007 2:07 PM
> > >> To: Alper Yegin
> > >> Cc: mip6@ietf.org; heejin.jang@samsung.com
> > >> Subject: Re: [Mip6] Dynamic HoA assignment
> > >>
> > >> Alper Yegin wrote:
> > >>>> The base PMIPv6 protocol assumes that the home prefix is sent
> > >>>> to the mobile node using a router advertisement and then the
> > >>>> mobile node auto-configures a home address from this prefix.
> > >>>
> > >>> Isn't an IPv6 host in charge of whether it uses address
> > >> autoconfiguration or
> > >>> DHCP? If so, PMIPv6 spec shall accommodate that, assuming it does
> > > not
> > >> want
> > >>> to dictate any particular behaviour on the hosts.
> > >>
> > >> 2461bis says
> > >>
> > >>     Router Advertisements (and per-prefix flags) allow routers to
> > > inform
> > >>     hosts how to perform Address Autoconfiguration.  For example,
> > > routers
> > >>     can specify whether hosts should use DHCPv6 and/or
> > >>     autonomous (stateless) address configuration.
> > >>
> > >> Stateful address configuration is not mandatory to support.
> > >> RFC 4294 says
> > >>
> > >>     Stateful Address Autoconfiguration MAY be supported.
> > >>
> > >> But I do agree DHCPv6 could be used between the mobile node
> > >> and the MAG (Mobile Access Gateway).
> > >>
> > >> However, the address configuration for PMIPv6 depends to a
> > >> large extent on what kind of link layer is used between the
> > >> mobile node and the MAG. If the link layer is PPP, for e.g.,
> > >> IPv6CP is used. If the link layer is an IPsec tunnel then
> > >> IKEv2 configuration payloads are used. The PMIPv6 protocol
> > >> does consider this and has some text addressing this.
> > >>
> > >> Anyway, this discussion needs to happen on the NETLMM
> > >> mailing list.
> > >>
> > >> Vijay
> > >>
> > >> _______________________________________________
> > >> Mip6 mailing list
> > >> Mip6@ietf.org
> > >> https://www1.ietf.org/mailman/listinfo/mip6
> > >
> > > _______________________________________________
> > > Mip6 mailing list
> > > Mip6@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/mip6
> >
> >
> > _______________________________________________
> > 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




--
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.org ------=_Part_14350_33399588.1182162479070-- --===============1713674964== 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 --===============1713674964==-- From mip6-bounces@ietf.org Mon Jun 18 16:18: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 1I0Nfx-0001qK-4f; Mon, 18 Jun 2007 16:18:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0NFC-0006Wv-0W; Mon, 18 Jun 2007 15:50:34 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I0NFB-0004jN-LT; Mon, 18 Jun 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 09D6C2ACA7; Mon, 18 Jun 2007 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I0NEg-00088V-FR; Mon, 18 Jun 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: Mon, 18 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-whyauthdataoption-02.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 : Why Authentication Data suboption is needed for MIP6 Author(s) : B. Patil, G. Dommety Filename : draft-ietf-mip6-whyauthdataoption-02.txt Pages : 16 Date : 2007-6-18 Mobile IPv6 defines a set of messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec SA that is established between the MN and HA. The MIP6 working group has proposed a mechanism to secure the binding update and binding acknowledgement messages using an authentication option, similar to the authentication option in Mobile IPv4, carried within the messages that are exchanged between the MN and HA to establish a binding. This document provides the justifications as to why the authentication option mechanism is needed for Mobile IPv6 deployment in certain deployment environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-whyauthdataoption-02.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-whyauthdataoption-02.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-whyauthdataoption-02.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-6-18134030.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-whyauthdataoption-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-whyauthdataoption-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-18134030.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 Mon Jun 18 18:02: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 1I0PIu-00028d-Cm; Mon, 18 Jun 2007 18:02:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0PIs-00028R-FL; Mon, 18 Jun 2007 18:02:30 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0PIp-00081z-Iv; Mon, 18 Jun 2007 18:02:30 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B829D1986A7; Tue, 19 Jun 2007 01:02:26 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 4A34F1986A6; Tue, 19 Jun 2007 01:02:26 +0300 (EEST) Message-ID: <467700F2.4060204@piuha.net> Date: Tue, 19 Jun 2007 01:02:26 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Mobile IPv6 Mailing List , IETF NEMO WG , Monami6 WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Cc: Subject: [Mip6] Merged WG charter X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mobile IPv6 Mailing List List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi all, Please find below the first draft charter for the merged WG. Comments appreciated. Note that the charter has changed only in terms of merging material from the three working groups into one, shortening the text here and there, and removing completed items. I've taken bootstrapping away as a completed item even if we are still a few weeks away from sending the last document (the option) to the IESG. Replies set to mip6 list. Jari ---- Mobility EXTensions for IPv6 (MEXT) Chair(s): TBD Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: TBD Description of Working Group: Mobile IPv6 specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions. In addition, NEMO network mobility mechanisms built on top of Mobile IPv6 allow managing the mobility of an entire network, as it changes its point of attachment to the Internet. The base specifications consist of: o RFC 3775 o RFC 3776 o RFC 3963 The primary goal of the MEXT working group will be to enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios (A). Additionally the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained (B). The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol (C). Deployment considerations call for solutions to enable dual-stack operation (A.1), allow the use of multiple interfaces in mobile nodes (A.2), mechanisms to support high-availabity home agents (A.3), and ways to employ Mobile IPv6 in the presence of firewalls (A.4). In addition, there are specific needs of the automotive and aviation communities with regards to route optimization of network mobility (A.5). Work items related to large scale deployment include: (A.1) A Solution for MIP6 session continuity for dual stack hosts which attach to IPv4 access networks. Additionally provide a mechanism for carrying IPv4 packets via the Home agent for MIP6 capable dual-stack hosts. (A.2) A protocol based solution for enhancing the reliability of home agents and a method to force a host to switch home agents. A mechanism to force an MN to switch the HA that is currently serving it. This is required in deployments where the HA may need to be taken offline for maintenance. (A.3) Use of multiple interfaces. The protocols do not today provide support for simultaneous differentiated use of multiple access technologies, although several proposals exist for such support, and some of them have been implemented and tested. When a mobile host/router uses multiple network interfaces simultaneously, or when multiple prefixes are available on a single network interface, the mobile host/router would end up with multiple Care-of Addresses (CoAs). In addition, the Home Agent might be attached to multiple network interfaces, or to a single network interface with multiple prefixes, hence resulting in the option to use multiple IP addresses for the Home Agent. This could result in the possibility of using a multitude of bi-directional tunnels between pairs of {Home Agent address, CoA} and a number of associated issues: establishment, selection and modification of multiple simultaneous tunnels. The objective of the WG is to produce a clear problem statement and to produce standard track specifications to the problems associated with the simultaneous use of multiple addresses for either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support and their variants (FMIPv6, HMIPv6, etc). Where the effects of having multiple prefixes on a single interface is identical to the effects of having multiple interfaces each with a single prefix, the WG will consider a generalized approach to cater for multiple prefixes available to a mobile host/router. The WG does not plan to define a tunnel selection mechanism, but may document how to use existing mechanisms based upon preferences or policies. In particular, the WG will consider that a tunnel is alive as long as packets can be exchanged with the corresponding peer. In addition, local information, such as interface up/down events, or other failure detection mechanisms can be used to quickly detect failure of tunnel(s). Deliverables related to this include - A document explaining the motivations for a node using multiple interfaces and the scenarios where it may end up with multiple global addresses on its interfaces [Informational] - An analysis document explaining what are the limitations for mobile hosts using multiple simultaneous Care-of Addresses and Home Agent addresses using Mobile IPv6, whether issues are specific to Mobile IPv6 or not [Informational]. - A protocol extension to support the registration of multiple Care-of Addresses at a given Home Agent address [Standard Track]. - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address [Standard Track]. (A.4) Work on solutions to deal with firewalls and the problems that firewalls cause as identified in RFC 4487. (A.5) Route optimization of network mobility. Three use cases have been identified for this. These are called the Aviation case, the Automotive case, and the Personal Mobile Router (consumer electronics) case, though the actual technical problems are characterized by the type of movements and environments more than by the specific industry using the technology. The group will explore these cases to gather requirements and proceed with solving the open issues. (1) Airline and spacecraft community, who are deploying NEMO for control systems, as well as Internet connectivity and entertainment systems. This use case is characterized by fast (~ 1000 km/h) moving objects over large distances (across continents). The main technical problem is that tunneling-based solutions imply a roundtrip to another continent and that BGP based solutions imply significant churn in the global Internet routing table. (2) Automotive industry who are deploying NEMO for in-car communication, entertainment, and data gathering, possible control systems use, and communication to roadside devices. This use case is characterized by moderately fast (~ 100-300 km/h) moving objects that employ local or cellular networks for connectivity. (3) Personal Mobile Routers, which are consumer devices that allow the user to bring a NEMO network with the user while mobile, and communicate with peer NEMO networks/MNNs. After gathering the requirements for these types of deployments, the working group will evaluate what type of route optimization needs to be performed (if any), and formulate a solution to those problems. If no requirements for those scenarios can be collected by the deadline, it will be assumed that the work is premature, and that type of deployment will be dropped from the WG. The group will only consider airline and spacecraft solutions that combine tunneling solutions for small movements with either federated tunnel servers or slowly changing end host prefixes. The group will only consider personal mobile router requirements about optimized routes to another mobile router belonging to the same operator. The group will only consider automotive industry requirements to allow MR-attached hosts to directly access the network where MR has attached to. Work on automotive and personal mobile router solutions requires rechartering. The WG will not consider routing issues inside the mobile network. Existing routing protocols (including MANET protocols) can be used to solve these problems. The group will also not consider general route optimization, multihoming, or other problems that are not related to the deployment and maintenance of NEMO networks. Similarly, the group will not consider or rely on the results of general routing architecture, Internet architecture, or identifier-locator split issues that are discussed in separate, long term efforts elsewhere in the IETF. Finally, the group will not consider solutions that require changes from correspondent nodes in the general Internet Work items related to base specification maintenance include: (B.1) Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. One specific area of concern that should be analyzed and addressed relates to multilink subnets. This work item relates only to corrections and clarifications. The working group shall not revisit design decisions or change the protocol. (B.2) Update the IANA considerations of RFC 3775 to allow extensions for experimental purposes as well passing of optional vendor-specific information. (B.3) Finish working group documents that are currently in process, and submit for RFC. This includes prefix delegation protocol mechanism for network mobility, and a MIB for NEMO Basic Support. Work items related to informational documentation include: (C.1) Produce a design rationale that documents the historical thinking behind the introduction of an alternative security mechanism, the Authentication Protocol (RFC 4285). Goals and Milestones: Jul 2007 Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments Jul 2007 Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments Jul 2007 Submit -00 draft on Route Optimization needs for Personal Mobile Router Aug 2007 Submit Multiple CoA Registration to IESG Aug 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational. Aug 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational. Sep 2007 Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard. Sep 2007 Submit Analysis of the use of Multiple Simultaneous Care-of Addresses and Home Agent addresses in Mobile IPv6 Sep 2007 Submit -00 draft for solution to aircraft/spacecraft problem Sep 2007 Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard. Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard. Oct 2007 Submit Multiple Interfaces Motivations and Scenario to IESG, for Informational Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard Nov 2007 Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational Nov 2007 Submit final doc on Route Optimization Needs for Automobile and Highway Deployments, for Informational Nov 2007 Submit final doc on Route Optimization needs for Personal Mobile Router, for Informational Dec 2007 Determine how to proceed with remaining automotive/Personal Mobile Router solutions Dec 2007 Recharter to work on the remaining automotive/Personal Mobile Router solutions Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard. Dec 2007 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. Dec 2007 Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard Feb 2008 Submit final doc for solution to aircraft/spacecraft problem to the IESG, for Proposed Standard Feb 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Feb 2008 Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. Mar 2008 Submit Flow/binding policies exchange to IESG _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 18 19:55: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 1I0R4A-0006Rv-DT; Mon, 18 Jun 2007 19:55:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0R48-0006RW-S4 for mip6@ietf.org; Mon, 18 Jun 2007 19:55:25 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0R46-0004ya-Bh for mip6@ietf.org; Mon, 18 Jun 2007 19:55:24 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 16:55:21 -0700 Message-ID: <46771B69.6000900@azairenet.com> Date: Mon, 18 Jun 2007 16:55:21 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Mobile IPv6 Mailing List , jari.arkko@piuha.net References: <467700F2.4060204@piuha.net> In-Reply-To: <467700F2.4060204@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jun 2007 23:55:21.0638 (UTC) FILETIME=[21951460:01C7B204] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Subject: [Mip6] Re: [Monami6] Merged WG charter 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 The charter looks good. A few comments. The charter is missing RADIUS Mobile IPv6 support (it is listed in the milestones). The deployment considerations for Mobile IPv6 should talk about extensions to interwork with a AAA infrastructure. Jari Arkko wrote: > Mobile IPv6 specifies routing support which permits an IPv6 host to > continue using its home address as it moves around the Internet, > enabling continuity of sessions. Mobile IPv6 supports transparency > above the IP layer, including maintenance of active transport level > sessions. In addition, NEMO network mobility mechanisms built on top > of Mobile IPv6 allow managing the mobility of an entire network, as it > changes its point of attachment to the Internet. The base > specifications consist of: > > o RFC 3775 > o RFC 3776 Suggest replacing 3776 with 4877 or add 4877. 4877 updates 3776. > o RFC 3963 > > The primary goal of the MEXT working group will be to enhance base > IPv6 mobility by continuing work on developments that are required for > wide-scale deployments and specific deployment scenarios > (A). Additionally the working group will ensure that any issues > identified by implementation and interoperability experience are > addressed, and that the base specifications are maintained (B). The > group will also produce informational documentation, such as design > rationale documents or description of specific issues within the > protocol (C). > > Deployment considerations call for solutions to enable > dual-stack operation (A.1), allow the use of multiple interfaces in > mobile nodes (A.2), mechanisms to support high-availabity home agents typo. It should be "availability". > (B.1) Create and maintain issue lists that are generated on the basis > of implementation and interoperability experience. Address > specific issues with specific updates or revisions of the base > specification. One specific area of concern that should be > analyzed and addressed relates to multilink subnets. Based on the discussions I have had so far (online and offline), I don't think there is an issue with multilink subnets in MIPv6. We could have a specific deliverable which explains how MIPv6 treats tunnels to each mobile node as being as extension of the home link. > Jul 2007 Submit -00 draft on Route Optimization Needs for > Aircraft and Spacecraft Deployments > Jul 2007 Submit -00 draft on Route Optimization Needs for > Automobile and Highway Deployments > Jul 2007 Submit -00 draft on Route Optimization needs for > Personal Mobile Router > Aug 2007 Submit Multiple CoA Registration to IESG > Aug 2007 Submit I-D 'Motivation for Authentication I-D' to IESG > for publication as Informational. > Aug 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for > publication as Informational. > Sep 2007 Submit I-D 'Mobility Header Home Agent Switch Message' > to IESG for publication as a Proposed Standard. > Sep 2007 Submit Analysis of the use of Multiple Simultaneous > Care-of Addresses and Home Agent addresses in Mobile IPv6 > Sep 2007 Submit -00 draft for solution to aircraft/spacecraft problem > Sep 2007 Submit I-D 'Home agent reliability' to IESG for > publication as a Proposed Standard. > Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG > for publication as a Proposed Standard. > Oct 2007 Submit Multiple Interfaces Motivations and Scenario to > IESG, for Informational > Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG > for publication as a Proposed Standard > Nov 2007 Submit final doc on Route Optimization Needs for > Aircraft and Spacecraft Deployments, for Informational > Nov 2007 Submit final doc on Route Optimization Needs for > Automobile and Highway Deployments, for Informational > Nov 2007 Submit final doc on Route Optimization needs for > Personal Mobile Router, for Informational > Dec 2007 Determine how to proceed with remaining > automotive/Personal Mobile Router solutions > Dec 2007 Recharter to work on the remaining automotive/Personal > Mobile Router solutions > Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to > IESG for publication as a Proposed Standard. > Dec 2007 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for > publication as a proposed standard. > Dec 2007 Submit the final doc on MIB for NEMO Basic Support to > the IESG, for Proposed Standard > Dec 2007 Submit the final doc on Prefix Delegation for NEMO to > the IESG, for Proposed Standard > Feb 2008 Submit final doc for solution to aircraft/spacecraft > problem to the IESG, for Proposed Standard > Feb 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to > IESG for publication as Informational. > Feb 2008 Submit I-D(s) related to specific updates and > corrections of RFC 3775 to IESG for publication as Proposed Standard. > Mar 2008 Submit Flow/binding policies exchange to IESG For many months there are at least three specifications being sent to the IESG. In September, there are five. Might be a big ambitious. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 18 22:34: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 1I0TXz-0002Lv-VW; Mon, 18 Jun 2007 22:34:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0TXy-0002LZ-3Y; Mon, 18 Jun 2007 22:34:22 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0TXw-0004JV-Gr; Mon, 18 Jun 2007 22:34:22 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id l5J2YHS1016634; Tue, 19 Jun 2007 11:34:17 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id l5J2YIt19206; Tue, 19 Jun 2007 11:34:18 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with ESMTP id l5J2YE710011; Tue, 19 Jun 2007 11:34:15 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.103]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 10:32:48 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Tue, 19 Jun 2007 10:32:44 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Tue, 19 Jun 2007 10:32:44 +0800 From: "Benjamin Lim" To: "'Mobile IPv6 Mailing List'" , "'Monami6 WG'" , "'IETF NEMO WG'" References: <467700F2.4060204@piuha.net> In-Reply-To: <467700F2.4060204@piuha.net> Date: Tue, 19 Jun 2007 10:32:38 +0800 Organization: Panasonic Singapore Labs Pte Ltd Message-ID: <010b01c7b21a$1a7111a0$4f5334e0$@limck@sg.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acex9DFDjINqk7bUQdmMFdjiMw6ajwAIZsHw Content-Language: en-us X-OriginalArrivalTime: 19 Jun 2007 02:32:48.0111 (UTC) FILETIME=[201E77F0:01C7B21A] X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Mip6] RE: [Monami6] Merged WG charter X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: benjamin.limck@sg.panasonic.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, I snip points for comments. [snip] from (A.3) Use of multiple interfaces. > > The objective of the WG is to produce a clear problem statement > and to produce standard track specifications to the problems > associated with the simultaneous use of multiple addresses for > either mobile hosts using Mobile IPv6 or mobile routers using > NEMO Basic Support and their variants (FMIPv6, HMIPv6, > etc). Where the effects of having multiple prefixes on a single > interface is identical to the effects of having multiple > interfaces each with a single prefix, the WG will consider a > generalized approach to cater for multiple prefixes available to > a mobile host/router. [/snip] [snip] from (A.5) Route optimization of network mobility. > > The WG will not consider routing issues inside the mobile > network. Existing routing protocols (including MANET protocols) > can be used to solve these problems. The group will also not > consider general route optimization, multihoming, or other > problems that are not related to the deployment and maintenance > of NEMO networks.... [/snip] I feel that there is a conflict between A.3 and A.5. From my interpretation, A.3 mentions that the WG will consider multi-homing w.r.t multiple interfaces for mobile host/routers. However, in A.5, it is said that WG will NOT consider multi-homing that are not related to NEMO. Suggest removing the restriction of multi-homing consideration from A.5. Regards, Benjamin Lim _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 19 00:26: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 1I0VHz-00068W-33; Tue, 19 Jun 2007 00:25:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0VHx-00068J-Mf for mip6@ietf.org; Tue, 19 Jun 2007 00:25:57 -0400 Received: from mx06.syd.iprimus.net.au ([210.50.76.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0VHw-0005GF-75 for mip6@ietf.org; Tue, 19 Jun 2007 00:25:57 -0400 Message-Id: <5vrfma$1hlcng@smtp06.syd.iprimus.net.au> X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALb3dkbTG2yO/2dsb2JhbAA X-IronPort-AV: E=Sophos;i="4.16,437,1175436000"; d="scan'208";a="52081392" Received: from 142.001.vod.mel.iprimus.net.au (HELO PC20005) ([211.27.108.142]) by smtp06.syd.iprimus.net.au with ESMTP; 19 Jun 2007 14:25:47 +1000 From: "Hesham Soliman" To: "'Mobile IPv6 Mailing List'" Subject: RE: [Mip6] Merged WG charter Date: Tue, 19 Jun 2007 14:25:42 +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.3138 Thread-Index: Acex9GIj9MUavYQNQjWntRnrV/3blwAM716Q In-Reply-To: <467700F2.4060204@piuha.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b 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 Jari, Thanks for this, some comments inline, mainly editorial. > Mobile IPv6 specifies routing support which permits an IPv6 host to > continue using its home address as it moves around the Internet, > enabling continuity of sessions. Mobile IPv6 supports transparency > above the IP layer, including maintenance of active transport level > sessions. In addition, NEMO network mobility mechanisms built on top > of Mobile IPv6 allow managing the mobility of an entire > network, as it > changes its point of attachment to the Internet. The base > specifications consist of: > > o RFC 3775 > o RFC 3776 > o RFC 3963 > > The primary goal of the MEXT working group will be to enhance base > IPv6 mobility by continuing work on developments that are > required for > wide-scale deployments and specific deployment scenarios > (A). Additionally the working group will ensure that any issues > identified by implementation and interoperability experience are > addressed, and that the base specifications are maintained (B). The > group will also produce informational documentation, such as design > rationale documents or description of specific issues within the > protocol (C). => I would list those in bullet format for clarity by placing (A), (B)..et first then the text describing it. Same for the text below. > > Deployment considerations call for solutions to enable > dual-stack operation (A.1), allow the use of multiple interfaces in > mobile nodes (A.2), mechanisms to support high-availabity home agents > (A.3), and ways to employ Mobile IPv6 in the presence of firewalls > (A.4). In addition, there are specific needs of the automotive and > aviation communities with regards to route optimization of network > mobility (A.5). => I'd reword the above to say: Address the specific needs of automotive and aviation communities for route optimisation in nemo. > > Work items related to large scale deployment include: > > (A.1) A Solution for MIP6 session continuity for dual stack > hosts which > attach to IPv4 access networks. Additionally provide a > mechanism > for carrying IPv4 packets via the Home agent for MIP6 capable > dual-stack hosts. > > (A.2) A protocol based solution for enhancing the reliability of home > agents and a method to force a host to switch home agents. > > A mechanism to force an MN to switch the HA that is currently > serving it. This is required in deployments where the > HA may need to > be taken offline for maintenance. => s/may need/needs > > (A.3) Use of multiple interfaces. > > The protocols do not today provide support for simultaneous > differentiated use of multiple access technologies, although > several proposals exist for such support, and some of them have > been implemented and tested. => Reword: Today, the protocols do not provide suppport... > > When a mobile host/router uses multiple network interfaces > simultaneously, or when multiple prefixes are available on a > single network interface, the mobile host/router would end up > with multiple Care-of Addresses (CoAs). In addition, the Home > Agent might be attached to multiple network interfaces, or to a > single network interface with multiple prefixes, hence > resulting > in the option to use multiple IP addresses for the Home > Agent. This could result in the possibility of using a > multitude > of bi-directional tunnels between pairs of {Home Agent address, > CoA} and a number of associated issues: establishment, > selection > and modification of multiple simultaneous tunnels. => The monami work was focused on the multiple CoA scenarios and explicitly removed the multiple HoA scenarios as a condition of the WG starting. We might need to discuss the impact of adding that back on the amount of work, overlap with site multihoming ...etc. > > The objective of the WG is to produce a clear problem statement > and to produce standard track specifications to the problems > associated with the simultaneous use of multiple addresses for > either mobile hosts using Mobile IPv6 or mobile routers using > NEMO Basic Support and their variants (FMIPv6, HMIPv6, > etc). Where the effects of having multiple prefixes on a single > interface is identical to the effects of having multiple > interfaces each with a single prefix, the WG will consider a > generalized approach to cater for multiple prefixes > available to > a mobile host/router. > > The WG does not plan to define a tunnel selection > mechanism, but > may document how to use existing mechanisms based upon > preferences or policies. In particular, the WG will consider > that a tunnel is alive as long as packets can be exchanged with > the corresponding peer. In addition, local information, such as > interface up/down events, or other failure detection mechanisms > can be used to quickly detect failure of tunnel(s). > > Deliverables related to this include > > - A document explaining the motivations for a node > using multiple > interfaces and the scenarios where it may end up > with multiple > global addresses on its interfaces [Informational] > > - An analysis document explaining what are the limitations for > mobile hosts using multiple simultaneous Care-of > Addresses and Home > Agent addresses using Mobile IPv6, whether issues > are specific to > Mobile IPv6 or not [Informational]. > > - A protocol extension to support the registration of multiple > Care-of Addresses at a given Home Agent address [Standard > Track]. > > - A "Flow/binding policies exchange" solution for an > exchange of > policies from the mobile host/router to the Home > Agent and from the > Home Agent to the mobile host/router influencing the > choice of the > Care-of Address and Home Agent address [Standard Track]. => We discussed, online and offline the possibility of having two drafts here, one specifying the protocol (transport) and one defining the format for the flow descriptors. Are we now merging them into one? > > (A.4) Work on solutions to deal with firewalls and the problems that > firewalls cause as identified in RFC 4487. => Hmm. I have some doubts about the "work on a solution" part. We need to assess those problems and decide whether a solution is needed. If needed then we should produce one. We discussed these issues in the FW DT and it's not clear, at least to me, that a solution is a certainty. More to come, but these are my initial comments up to this part. Hesham > > (A.5) Route optimization of network mobility. > > Three use cases have been identified for this. These are called > the Aviation case, the Automotive case, and the Personal Mobile > Router (consumer electronics) case, though the actual technical > problems are characterized by the type of movements and > environments more than by the specific industry using the > technology. The group will explore these cases to gather > requirements and proceed with solving the open issues. > > (1) Airline and spacecraft community, who are > deploying NEMO for > control systems, as well as Internet connectivity and > entertainment systems. This use case is characterized > by fast (~ > 1000 km/h) moving objects over large distances (across > continents). The main technical problem is that tunneling-based > solutions imply a roundtrip to another continent and that BGP > based solutions imply significant churn in the global Internet > routing table. > > (2) Automotive industry who are deploying NEMO for in-car > communication, entertainment, and data gathering, possible > control systems use, and communication to roadside > devices. This > use case is characterized by moderately fast (~ 100-300 km/h) > moving objects that employ local or cellular networks for > connectivity. > > (3) Personal Mobile Routers, which are consumer devices that > allow the user to bring a NEMO network with the user while > mobile, and communicate with peer NEMO networks/MNNs. > > After gathering the requirements for these types of > deployments, > the working group will evaluate what type of route optimization > needs to be performed (if any), and formulate a solution to > those problems. > > If no requirements for those scenarios can be collected by the > deadline, it will be assumed that the work is premature, and > that type of deployment will be dropped from the WG. > > The group will only consider airline and spacecraft solutions > that combine tunneling solutions for small movements > with either > federated tunnel servers or slowly changing end host prefixes. > The group will only consider personal mobile router > requirements > about optimized routes to another mobile router > belonging to the > same operator. The group will only consider automotive industry > requirements to allow MR-attached hosts to directly access the > network where MR has attached to. Work on automotive and > personal mobile router solutions requires rechartering. > > The WG will not consider routing issues inside the mobile > network. Existing routing protocols (including MANET protocols) > can be used to solve these problems. The group will also not > consider general route optimization, multihoming, or other > problems that are not related to the deployment and maintenance > of NEMO networks. Similarly, the group will not > consider or rely > on the results of general routing architecture, Internet > architecture, or identifier-locator split issues that are > discussed in separate, long term efforts elsewhere in the > IETF. Finally, the group will not consider solutions that > require changes from correspondent nodes in the > general Internet > > > Work items related to base specification maintenance include: > > (B.1) Create and maintain issue lists that are generated on the basis > of implementation and interoperability experience. Address > specific issues with specific updates or revisions of the base > specification. One specific area of concern that should be > analyzed and addressed relates to multilink subnets. > > This work item relates only to corrections and > clarifications. The working group shall not revisit design > decisions or change the protocol. > > (B.2) Update the IANA considerations of RFC 3775 to allow > extensions for > experimental purposes as well passing of optional > vendor-specific > information. > > (B.3) Finish working group documents that are currently in > process, and > submit for RFC. This includes prefix delegation > protocol mechanism > for network mobility, and a MIB for NEMO Basic Support. > > > Work items related to informational documentation include: > > (C.1) Produce a design rationale that documents the historical > thinking behind the introduction of an alternative security > mechanism, the Authentication Protocol (RFC 4285). > > > Goals and Milestones: > > > Jul 2007 Submit -00 draft on Route Optimization Needs > for Aircraft and Spacecraft Deployments > Jul 2007 Submit -00 draft on Route Optimization Needs > for Automobile and Highway Deployments > Jul 2007 Submit -00 draft on Route Optimization needs > for Personal Mobile Router > Aug 2007 Submit Multiple CoA Registration to IESG > Aug 2007 Submit I-D 'Motivation for Authentication I-D' > to IESG for publication as Informational. > Aug 2007 Submit I-D 'Goals for AAA HA Interface' to IESG > for publication as Informational. > Sep 2007 Submit I-D 'Mobility Header Home Agent Switch > Message' to IESG for publication as a Proposed Standard. > Sep 2007 Submit Analysis of the use of Multiple > Simultaneous Care-of Addresses and Home Agent addresses in > Mobile IPv6 > Sep 2007 Submit -00 draft for solution to > aircraft/spacecraft problem > Sep 2007 Submit I-D 'Home agent reliability' to IESG for > publication as a Proposed Standard. > Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' > to IESG for publication as a Proposed Standard. > Oct 2007 Submit Multiple Interfaces Motivations and > Scenario to IESG, for Informational > Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' > to IESG for publication as a Proposed Standard > Nov 2007 Submit final doc on Route Optimization Needs > for Aircraft and Spacecraft Deployments, for Informational > Nov 2007 Submit final doc on Route Optimization Needs > for Automobile and Highway Deployments, for Informational > Nov 2007 Submit final doc on Route Optimization needs > for Personal Mobile Router, for Informational > Dec 2007 Determine how to proceed with remaining > automotive/Personal Mobile Router solutions > Dec 2007 Recharter to work on the remaining > automotive/Personal Mobile Router solutions > Dec 2007 Submit I-D 'Mobile IPv6 Experimental > Allocations' to IESG for publication as a Proposed Standard. > Dec 2007 Submit the I-D 'RADIUS Mobile IPv6 Support' to > IESG for publication as a proposed standard. > Dec 2007 Submit the final doc on MIB for NEMO Basic > Support to the IESG, for Proposed Standard > Dec 2007 Submit the final doc on Prefix Delegation for > NEMO to the IESG, for Proposed Standard > Feb 2008 Submit final doc for solution to > aircraft/spacecraft problem to the IESG, for Proposed Standard > Feb 2008 Submit I-D 'Mobile IPv6 Operation with > Firewalls' to IESG for publication as Informational. > Feb 2008 Submit I-D(s) related to specific updates and > corrections of RFC 3775 to IESG for publication as Proposed > Standard. > Mar 2008 Submit Flow/binding policies exchange to IESG > > > > _______________________________________________ > 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 Jun 19 03:33: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 1I0YDA-0006d3-B2; Tue, 19 Jun 2007 03:33:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0YD9-0006cv-R1 for Mip6@ietf.org; Tue, 19 Jun 2007 03:33:11 -0400 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0YD7-0006YJ-DF for Mip6@ietf.org; Tue, 19 Jun 2007 03:33:11 -0400 Received: by nz-out-0506.google.com with SMTP id z31so1559242nzd for ; Tue, 19 Jun 2007 00:33:09 -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; b=gs0yXVBG0VIy4kVXFKQ0apQSQVNwu2QEmRhMWitRD3Sw7UCSUFd6g7hCZ3aANQZLSzikSgfPZV42vzt2t6Nf0k81p9Q4hh8TJPARMPrc/v+nM+kpdtXPymuEq+SGwwOrKSTC2aeLxsfJL3ClcdpekY4pxNUU6hJio/AXwHJqfZw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=SgNgKurKRBTw1sCX36CtFrb6Lclapb3pdxkl3l6VZCQz8WMj5kGg01HfT/3fgPjFc14MTITjQRUL05Gh1ZnZ7gXtWhfltvL/ZmY1yfEHauMFBM7N9yABkETI5ynPnnFF8PfWB4c+q+ih77ibN7aNognvamrOdIdHxDzKnqsl4Yg= Received: by 10.143.1.2 with SMTP id d2mr346239wfi.1182238388663; Tue, 19 Jun 2007 00:33:08 -0700 (PDT) Received: by 10.142.90.7 with HTTP; Tue, 19 Jun 2007 00:33:08 -0700 (PDT) Message-ID: Date: Mon, 18 Jun 2007 19:33:08 -1200 From: "Kuljaree Tantayakul" To: Mip6@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: Subject: [Mip6] cannot send BU 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="===============0391623904==" Errors-To: mip6-bounces@ietf.org --===============0391623904== Content-Type: multipart/alternative; boundary="----=_Part_82276_6031646.1182238388642" ------=_Part_82276_6031646.1182238388642 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear All, I'm interesting MIPv6 and I try to setup mobile IPv6 network by using kame-20070201-freebsd54-snap. But I had problem that MN cannot send BU to its HA. Please help me to solve these problems. my configuration file can be shown as following: HA configuration rc.conf __________________________________________________ PATH=/usr/local/v6/sbin:/usr/local/v6/bin:${PATH} ipv6_enable="YES" ipv6_gateway_enable="YES" rtadvd_enable="YES" rtadvd_interfaces="em0" ipv6_ifconfig_em0_alias0="3ffe:b80:53:aaaa::1" ipv6_ifconfig_em0_alias1="3ffe:b80:53:aaaa:: anycast" ipv6_mobile_enable="YES" ipv6_mobile_nodetype="home_agent" ipv6_mobile_home_interface="em0" ipv6_ifconfig_em1="3ffe:b80:53:aabb::1 prefixlen 64" ipv6_ifconfig_fxp1="3ffe:b80:53:bbbb::1 prefixlen 64" ipv6_router_enable="YES" ipv6_router="/usr/local/v6/sbin/route6d" __________________________________________________ had.conf ___________________________________________ debug 1; interface em0 { command-port 7778; preference 10; }; _____________________________________________ >> when I try to see had process by using HA#ps -aux |grep had root 572 0.0 0.5 2368 1260 ?? ls 9:01AM 0:00.00 had -n -c /usr/local/v6/etc/had.conf em0 MN configuration rc.conf --------------------------------------------------------------------------------------- PATH=/usr/local/v6/sbin:/usr/local/v6/bin:${PATH} ipv6_enable="YES" ipv6_mobile_enable="YES" ipv6_mobile_nodetype="mobile_node" ipv6_interfaces="fxp0 mip0" ipv6_ifconfig_mip0="3ffe:b80:53:aaaa::2 home" ipv6_ifconfig_fxp0="up" ---------------------------------------------------------------------------------------- mnd.conf ---------------------------------------------------------------------------------------- debug 1; interface mip0 { command-port 7778; home-registration-lifetime 10; }; -------------------------------------------------------------------------------------- >> When I reboot MN and MN connect which home link, I notice that home address which is 3ffe:b80:53:aaaa::2 cannot assign on fxp0 interface. But assigned on mip0 interface. >> when I try to see process mnd by using MN#ps -aux |grep mnd don't have mnd process >> I try manually run command MN#/use/local/v6/sbin/mnd mip0 Result June 18 16:55:17 shisa(mnd): mip0 is added successfully June 18 16:55:17 shisa(mnd): insert bul 3ffe:b80:53:aaaa::2 into hoainfo June 18 16:55:17 shisa(mnd): HA not found Now my testbed cannot work. When MN move to the other network. MN cannot send BU to its Home Agent (HA). Please help me to solve my problem or give some information to me. Thanks, Kuljaree ------=_Part_82276_6031646.1182238388642 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Dear  All,

       I'm interesting MIPv6 and I try to setup mobile IPv6 network by using
kame-20070201-freebsd54-snap. But I had problem that MN cannot send BU to its HA.
 
Please help me to solve these problems.
 
my configuration file can be shown as following:

HA configuration
rc.conf
__________________________________________________
       PATH=/usr/local/v6/sbin:/usr/local/v6/bin:${PATH}

       ipv6_enable="YES"
       ipv6_gateway_enable="YES"
       rtadvd_enable="YES"
       rtadvd_interfaces="em0"
       ipv6_ifconfig_em0_alias0="3ffe:b80:53:aaaa::1"
       ipv6_ifconfig_em0_alias1="3ffe:b80:53:aaaa:: anycast"

       ipv6_mobile_enable="YES"
       ipv6_mobile_nodetype="home_agent"
       ipv6_mobile_home_interface="em0"

       ipv6_ifconfig_em1="3ffe:b80:53:aabb::1 prefixlen 64"
       ipv6_ifconfig_fxp1="3ffe:b80:53:bbbb::1 prefixlen 64"
       ipv6_router_enable="YES"
       ipv6_router="/usr/local/v6/sbin/route6d"
__________________________________________________


had.conf
___________________________________________
debug 1;

 interface em0 {
        command-port 7778;
        preference 10;
};
_____________________________________________

>> when I try to  see had process by using
       HA#ps  -aux  |grep  had
       root   572  0.0  0.5  2368  1260  ??  ls  9:01AM     0:00.00  had  -n
 -c  /usr/local/v6/etc/had.conf  em0


MN configuration

rc.conf
---------------------------------------------------------------------------------------
       PATH=/usr/local/v6/sbin:/usr/local/v6/bin:${PATH}

       ipv6_enable="YES"
       ipv6_mobile_enable="YES"
       ipv6_mobile_nodetype="mobile_node"
       ipv6_interfaces="fxp0 mip0"
       ipv6_ifconfig_mip0="3ffe:b80:53:aaaa::2 home"
       ipv6_ifconfig_fxp0="up"
----------------------------------------------------------------------------------------

mnd.conf
----------------------------------------------------------------------------------------
 debug 1;

 interface mip0 {
        command-port 7778;
        home-registration-lifetime 10;
 };
--------------------------------------------------------------------------------------

>> When I reboot MN and MN connect which home link, I notice that
home address which is 3ffe:b80:53:aaaa::2  cannot assign on fxp0
interface. But assigned on mip0 interface.

>> when I try to see process mnd by using
       MN#ps  -aux  |grep mnd
 don't have mnd process

>> I try manually run command
       MN#/use/local/v6/sbin/mnd mip0
Result
June 18 16:55:17  shisa(mnd): mip0 is added successfully
June 18 16:55:17 shisa(mnd): insert  bul  3ffe:b80:53:aaaa::2  into  hoainfo
June 18 16:55:17 shisa(mnd):  HA not found


Now my testbed cannot work. When MN move to the other network. MN
cannot send  BU to its Home Agent (HA).
Please help me to solve my problem or give some information to me.

Thanks,
 

Kuljaree
------=_Part_82276_6031646.1182238388642-- --===============0391623904== 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 --===============0391623904==-- From mip6-bounces@ietf.org Tue Jun 19 05:03: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 1I0ZcT-0005z3-EX; Tue, 19 Jun 2007 05:03:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ZcR-0005yn-Sx for mip6@ietf.org; Tue, 19 Jun 2007 05:03:23 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0Zc6-00069K-I0 for mip6@ietf.org; Tue, 19 Jun 2007 05:03:23 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1182243737!6828508!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 25125 invoked from network); 19 Jun 2007 09:02:17 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-13.tower-128.messagelabs.com with SMTP; 19 Jun 2007 09:02:17 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l5J92GXa001783; Tue, 19 Jun 2007 02:02:16 -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 l5J92FYq025349; Tue, 19 Jun 2007 04:02:16 -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 l5J92D3E025267; Tue, 19 Jun 2007 04:02:14 -0500 (CDT) Message-ID: <46779B90.1050904@gmail.com> Date: Tue, 19 Jun 2007 11:02:08 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: benjamin.limck@sg.panasonic.com References: <467700F2.4060204@piuha.net> <010b01c7b21a$1a7111a0$4f5334e0$@limck@sg.panasonic.com> In-Reply-To: <010b01c7b21a$1a7111a0$4f5334e0$@limck@sg.panasonic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000750-1, 18/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: 'Mobile IPv6 Mailing List' Subject: [Mip6] Re: [Monami6] Merged WG charter 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 Benjamin Lim wrote: > Hi, > > I snip points for comments. > > [snip] from (A.3) Use of multiple interfaces. >> The objective of the WG is to produce a clear problem statement >> and to produce standard track specifications to the problems >> associated with the simultaneous use of multiple addresses for >> either mobile hosts using Mobile IPv6 or mobile routers using >> NEMO Basic Support and their variants (FMIPv6, HMIPv6, >> etc). Where the effects of having multiple prefixes on a single >> interface is identical to the effects of having multiple >> interfaces each with a single prefix, the WG will consider a >> generalized approach to cater for multiple prefixes available to >> a mobile host/router. > [/snip] > > [snip] from (A.5) Route optimization of network mobility. >> The WG will not consider routing issues inside the mobile >> network. Existing routing protocols (including MANET protocols) >> can be used to solve these problems. The group will also not >> consider general route optimization, multihoming, or other >> problems that are not related to the deployment and maintenance >> of NEMO networks.... > [/snip] > > I feel that there is a conflict between A.3 and A.5. From my interpretation, > A.3 mentions that the WG will consider multi-homing w.r.t multiple > interfaces for mobile host/routers. However, in A.5, it is said that WG will > NOT consider multi-homing that are not related to NEMO. Suggest removing the > restriction of multi-homing consideration from A.5. I agree, I had the same remark. I think the text looks so because it's still in an initial phase of merging, and the NEMO text was written probably with only the NEMO WG in mind, not the merged group. I agree removing that restriction on multihoming since MEXT _will_ work on multiple CoAs, multiple HAs, multiple interfaces, etc. Alex > > Regards, > Benjamin Lim > > > > _______________________________________________ > Monami6 mailing list > Monami6@ietf.org > https://www1.ietf.org/mailman/listinfo/monami6 > ______________________________________________________________________ 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 Jun 19 07:38: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 1I0c2E-0005gF-Tl; Tue, 19 Jun 2007 07:38:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0c2C-0005gA-V1 for mip6@ietf.org; Tue, 19 Jun 2007 07:38:08 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0c29-0006cp-UT for mip6@ietf.org; Tue, 19 Jun 2007 07:38:08 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 705D21986A6; Tue, 19 Jun 2007 14:38:04 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 01C59198691; Tue, 19 Jun 2007 14:38:04 +0300 (EEST) Message-ID: <4677C01B.9060703@piuha.net> Date: Tue, 19 Jun 2007 14:38:03 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Vijay Devarapalli References: <467700F2.4060204@piuha.net> <46771B69.6000900@azairenet.com> In-Reply-To: <46771B69.6000900@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e95407604bef3289cd27cb4f3b3a35b4 Cc: Mobile IPv6 Mailing List Subject: [Mip6] Re: [Monami6] Merged WG charter 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, Thanks for your comments: > The charter is missing RADIUS Mobile IPv6 support (it is listed > in the milestones). The deployment considerations for Mobile > IPv6 should talk about extensions to interwork with a AAA > infrastructure. Right. I added this. >> o RFC 3775 >> o RFC 3776 > > Suggest replacing 3776 with 4877 or add 4877. 4877 updates 3776. Ah yes. I made the replacement. > typo. It should be "availability". Corrected. > >> (B.1) Create and maintain issue lists that are generated on the basis >> of implementation and interoperability experience. Address >> specific issues with specific updates or revisions of the base >> specification. One specific area of concern that should be >> analyzed and addressed relates to multilink subnets. > > Based on the discussions I have had so far (online and offline), I > don't think there is an issue with multilink subnets in MIPv6. We > could have a specific deliverable which explains how MIPv6 treats > tunnels to each mobile node as being as extension of the home link. Right. But your statement above is not in conflict with what the charter says, i.e., its fine to analyze and document the results of an analysis. >> Jul 2007 Submit -00 draft on Route Optimization Needs for >> Aircraft and Spacecraft Deployments >> Jul 2007 Submit -00 draft on Route Optimization Needs for >> Automobile and Highway Deployments >> Jul 2007 Submit -00 draft on Route Optimization needs for >> Personal Mobile Router >> Aug 2007 Submit Multiple CoA Registration to IESG >> Aug 2007 Submit I-D 'Motivation for Authentication I-D' to >> IESG for publication as Informational. >> Aug 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for >> publication as Informational. >> Sep 2007 Submit I-D 'Mobility Header Home Agent Switch >> Message' to IESG for publication as a Proposed Standard. >> Sep 2007 Submit Analysis of the use of Multiple Simultaneous >> Care-of Addresses and Home Agent addresses in Mobile IPv6 >> Sep 2007 Submit -00 draft for solution to aircraft/spacecraft >> problem >> Sep 2007 Submit I-D 'Home agent reliability' to IESG for >> publication as a Proposed Standard. >> Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG >> for publication as a Proposed Standard. >> Oct 2007 Submit Multiple Interfaces Motivations and Scenario >> to IESG, for Informational >> Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to >> IESG for publication as a Proposed Standard >> Nov 2007 Submit final doc on Route Optimization Needs for >> Aircraft and Spacecraft Deployments, for Informational >> Nov 2007 Submit final doc on Route Optimization Needs for >> Automobile and Highway Deployments, for Informational >> Nov 2007 Submit final doc on Route Optimization needs for >> Personal Mobile Router, for Informational >> Dec 2007 Determine how to proceed with remaining >> automotive/Personal Mobile Router solutions >> Dec 2007 Recharter to work on the remaining >> automotive/Personal Mobile Router solutions >> Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to >> IESG for publication as a Proposed Standard. >> Dec 2007 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG >> for publication as a proposed standard. >> Dec 2007 Submit the final doc on MIB for NEMO Basic Support to >> the IESG, for Proposed Standard >> Dec 2007 Submit the final doc on Prefix Delegation for NEMO to >> the IESG, for Proposed Standard >> Feb 2008 Submit final doc for solution to aircraft/spacecraft >> problem to the IESG, for Proposed Standard >> Feb 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to >> IESG for publication as Informational. >> Feb 2008 Submit I-D(s) related to specific updates and >> corrections of RFC 3775 to IESG for publication as Proposed Standard. >> Mar 2008 Submit Flow/binding policies exchange to IESG > > For many months there are at least three specifications being sent > to the IESG. In September, there are five. Might be a big ambitious. Ok, I felt that too but did not want to change to many of them (I already postoned some). But you are right, this needs to change. Please find a new version attached: Mobility EXTensions for IPv6 (MEXT) Chair(s): TBD Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: TBD Description of Working Group: Mobile IPv6 specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions. In addition, NEMO network mobility mechanisms built on top of Mobile IPv6 allow managing the mobility of an entire network, as it changes its point of attachment to the Internet. The base specifications consist of: o RFC 3775 o RFC 3963 o RFC 4877 The primary goal of the MEXT working group will be to enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios (A). Additionally the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained (B). The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol (C). Deployment considerations call for solutions to enable dual-stack operation (A.1), allow the use of multiple interfaces in mobile nodes (A.2), mechanisms to support high-availability home agents (A.3), and ways to employ Mobile IPv6 in the presence of firewalls (A.4). In addition, there are specific needs of the automotive and aviation communities with regards to route optimization of network mobility (A.5). Finally, support for AAA is needed as a continuation of earlier work on bootstrapping (A.6). Work items related to large scale deployment include: (A.1) A Solution for MIP6 session continuity for dual stack hosts which attach to IPv4 access networks. Additionally provide a mechanism for carrying IPv4 packets via the Home agent for MIP6 capable dual-stack hosts. (A.2) A protocol based solution for enhancing the reliability of home agents and a method to force a host to switch home agents. A mechanism to force an MN to switch the HA that is currently serving it. This is required in deployments where the HA may need to be taken offline for maintenance. (A.3) Use of multiple interfaces. The protocols do not today provide support for simultaneous differentiated use of multiple access technologies, although several proposals exist for such support, and some of them have been implemented and tested. When a mobile host/router uses multiple network interfaces simultaneously, or when multiple prefixes are available on a single network interface, the mobile host/router would end up with multiple Care-of Addresses (CoAs). In addition, the Home Agent might be attached to multiple network interfaces, or to a single network interface with multiple prefixes, hence resulting in the option to use multiple IP addresses for the Home Agent. This could result in the possibility of using a multitude of bi-directional tunnels between pairs of {Home Agent address, CoA} and a number of associated issues: establishment, selection and modification of multiple simultaneous tunnels. The objective of the WG is to produce a clear problem statement and to produce standard track specifications to the problems associated with the simultaneous use of multiple addresses for either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support and their variants (FMIPv6, HMIPv6, etc). Where the effects of having multiple prefixes on a single interface is identical to the effects of having multiple interfaces each with a single prefix, the WG will consider a generalized approach to cater for multiple prefixes available to a mobile host/router. The WG does not plan to define a tunnel selection mechanism, but may document how to use existing mechanisms based upon preferences or policies. In particular, the WG will consider that a tunnel is alive as long as packets can be exchanged with the corresponding peer. In addition, local information, such as interface up/down events, or other failure detection mechanisms can be used to quickly detect failure of tunnel(s). Deliverables related to this include - A document explaining the motivations for a node using multiple interfaces and the scenarios where it may end up with multiple global addresses on its interfaces [Informational] - An analysis document explaining what are the limitations for mobile hosts using multiple simultaneous Care-of Addresses and Home Agent addresses using Mobile IPv6, whether issues are specific to Mobile IPv6 or not [Informational]. - A protocol extension to support the registration of multiple Care-of Addresses at a given Home Agent address [Standard Track]. - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address [Standard Track]. (A.4) Work on solutions to deal with firewalls and the problems that firewalls cause as identified in RFC 4487. (A.5) Route optimization of network mobility. Three use cases have been identified for this. These are called the Aviation case, the Automotive case, and the Personal Mobile Router (consumer electronics) case, though the actual technical problems are characterized by the type of movements and environments more than by the specific industry using the technology. The group will explore these cases to gather requirements and proceed with solving the open issues. (1) Airline and spacecraft community, who are deploying NEMO for control systems, as well as Internet connectivity and entertainment systems. This use case is characterized by fast (~ 1000 km/h) moving objects over large distances (across continents). The main technical problem is that tunneling-based solutions imply a roundtrip to another continent and that BGP based solutions imply significant churn in the global Internet routing table. (2) Automotive industry who are deploying NEMO for in-car communication, entertainment, and data gathering, possible control systems use, and communication to roadside devices. This use case is characterized by moderately fast (~ 100-300 km/h) moving objects that employ local or cellular networks for connectivity. (3) Personal Mobile Routers, which are consumer devices that allow the user to bring a NEMO network with the user while mobile, and communicate with peer NEMO networks/MNNs. After gathering the requirements for these types of deployments, the working group will evaluate what type of route optimization needs to be performed (if any), and formulate a solution to those problems. If no requirements for those scenarios can be collected by the deadline, it will be assumed that the work is premature, and that type of deployment will be dropped from the WG. The group will only consider airline and spacecraft solutions that combine tunneling solutions for small movements with either federated tunnel servers or slowly changing end host prefixes. The group will only consider personal mobile router requirements about optimized routes to another mobile router belonging to the same operator. The group will only consider automotive industry requirements to allow MR-attached hosts to directly access the network where MR has attached to. Work on automotive and personal mobile router solutions requires rechartering. The WG will not consider routing issues inside the mobile network. Existing routing protocols (including MANET protocols) can be used to solve these problems. The group will also not consider general route optimization, multihoming, or other problems that are not related to the deployment and maintenance of NEMO networks. Similarly, the group will not consider or rely on the results of general routing architecture, Internet architecture, or identifier-locator split issues that are discussed in separate, long term efforts elsewhere in the IETF. Finally, the group will not consider solutions that require changes from correspondent nodes in the general Internet (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG require AAA support for Mobile IPv6. Part of this work is already being done in the DIME WG, but the MEXT WG is chartered to complete a design for RADIUS. Work items related to base specification maintenance include: (B.1) Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. One specific area of concern that should be analyzed and addressed relates to multilink subnets. This work item relates only to corrections and clarifications. The working group shall not revisit design decisions or change the protocol. (B.2) Update the IANA considerations of RFC 3775 to allow extensions for experimental purposes as well passing of optional vendor-specific information. (B.3) Finish working group documents that are currently in process, and submit for RFC. This includes prefix delegation protocol mechanism for network mobility, and a MIB for NEMO Basic Support. Work items related to informational documentation include: (C.1) Produce a design rationale that documents the historical thinking behind the introduction of an alternative security mechanism, the Authentication Protocol (RFC 4285). Goals and Milestones: Jul 2007 Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments Jul 2007 Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments Jul 2007 Submit -00 draft on Route Optimization needs for Personal Mobile Router Aug 2007 Submit Multiple CoA Registration to IESG Aug 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational. Aug 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational. Sep 2007 Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard. Sep 2007 Submit -00 draft for solution to aircraft/spacecraft problem Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard. Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard Nov 2007 Submit Multiple Interfaces Motivations and Scenario to IESG, for Informational Nov 2007 Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational Nov 2007 Submit Analysis of the use of Multiple Simultaneous Care-of Addresses and Home Agent addresses in Mobile IPv6 Dec 2007 Submit final doc on Route Optimization Needs for Automobile and Highway Deployments, for Informational Dec 2007 Submit final doc on Route Optimization needs for Personal Mobile Router, for Informational Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard. Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard Dec 2007 Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard. Jan 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. Jan 2008 Determine how to proceed with remaining automotive/Personal Mobile Router solutions Jan 2008 Recharter to work on the remaining automotive/Personal Mobile Router solutions Feb 2008 Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard Feb 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Mar 2008 Submit final doc for solution to aircraft/spacecraft problem to the IESG, for Proposed Standard Mar 2008 Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. Mar 2008 Submit Flow/binding policies exchange to IESG _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 19 10:35: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 1I0enM-000876-UA; Tue, 19 Jun 2007 10:35:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0enL-000870-EO for mip6@ietf.org; Tue, 19 Jun 2007 10:34:59 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0enK-0002AB-Hz for mip6@ietf.org; Tue, 19 Jun 2007 10:34:59 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 07:34:57 -0700 Message-ID: <4677E98C.7000109@azairenet.com> Date: Tue, 19 Jun 2007 07:34:52 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Jari Arkko , Mobile IPv6 Mailing List References: <467700F2.4060204@piuha.net> <46771B69.6000900@azairenet.com> <4677C01B.9060703@piuha.net> In-Reply-To: <4677C01B.9060703@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2007 14:34:57.0344 (UTC) FILETIME=[025ABC00:01C7B27F] X-Spam-Score: 0.0 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Cc: Subject: [Mip6] Re: [Monami6] Merged WG charter 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. The changes look good to me. Vijay Jari Arkko wrote: > Vijay, > > Thanks for your comments: > >> The charter is missing RADIUS Mobile IPv6 support (it is listed >> in the milestones). The deployment considerations for Mobile >> IPv6 should talk about extensions to interwork with a AAA >> infrastructure. > > Right. I added this. > >>> o RFC 3775 >>> o RFC 3776 >> Suggest replacing 3776 with 4877 or add 4877. 4877 updates 3776. > > Ah yes. I made the replacement. > >> typo. It should be "availability". > > Corrected. > >>> (B.1) Create and maintain issue lists that are generated on the basis >>> of implementation and interoperability experience. Address >>> specific issues with specific updates or revisions of the base >>> specification. One specific area of concern that should be >>> analyzed and addressed relates to multilink subnets. >> Based on the discussions I have had so far (online and offline), I >> don't think there is an issue with multilink subnets in MIPv6. We >> could have a specific deliverable which explains how MIPv6 treats >> tunnels to each mobile node as being as extension of the home link. > > Right. But your statement above is not in conflict with what > the charter says, i.e., its fine to analyze and document the > results of an analysis. > >>> Jul 2007 Submit -00 draft on Route Optimization Needs for >>> Aircraft and Spacecraft Deployments >>> Jul 2007 Submit -00 draft on Route Optimization Needs for >>> Automobile and Highway Deployments >>> Jul 2007 Submit -00 draft on Route Optimization needs for >>> Personal Mobile Router >>> Aug 2007 Submit Multiple CoA Registration to IESG >>> Aug 2007 Submit I-D 'Motivation for Authentication I-D' to >>> IESG for publication as Informational. >>> Aug 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for >>> publication as Informational. >>> Sep 2007 Submit I-D 'Mobility Header Home Agent Switch >>> Message' to IESG for publication as a Proposed Standard. >>> Sep 2007 Submit Analysis of the use of Multiple Simultaneous >>> Care-of Addresses and Home Agent addresses in Mobile IPv6 >>> Sep 2007 Submit -00 draft for solution to aircraft/spacecraft >>> problem >>> Sep 2007 Submit I-D 'Home agent reliability' to IESG for >>> publication as a Proposed Standard. >>> Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG >>> for publication as a Proposed Standard. >>> Oct 2007 Submit Multiple Interfaces Motivations and Scenario >>> to IESG, for Informational >>> Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to >>> IESG for publication as a Proposed Standard >>> Nov 2007 Submit final doc on Route Optimization Needs for >>> Aircraft and Spacecraft Deployments, for Informational >>> Nov 2007 Submit final doc on Route Optimization Needs for >>> Automobile and Highway Deployments, for Informational >>> Nov 2007 Submit final doc on Route Optimization needs for >>> Personal Mobile Router, for Informational >>> Dec 2007 Determine how to proceed with remaining >>> automotive/Personal Mobile Router solutions >>> Dec 2007 Recharter to work on the remaining >>> automotive/Personal Mobile Router solutions >>> Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to >>> IESG for publication as a Proposed Standard. >>> Dec 2007 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG >>> for publication as a proposed standard. >>> Dec 2007 Submit the final doc on MIB for NEMO Basic Support to >>> the IESG, for Proposed Standard >>> Dec 2007 Submit the final doc on Prefix Delegation for NEMO to >>> the IESG, for Proposed Standard >>> Feb 2008 Submit final doc for solution to aircraft/spacecraft >>> problem to the IESG, for Proposed Standard >>> Feb 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to >>> IESG for publication as Informational. >>> Feb 2008 Submit I-D(s) related to specific updates and >>> corrections of RFC 3775 to IESG for publication as Proposed Standard. >>> Mar 2008 Submit Flow/binding policies exchange to IESG >> For many months there are at least three specifications being sent >> to the IESG. In September, there are five. Might be a big ambitious. > > Ok, I felt that too but did not want to change to many of them > (I already postoned some). > > But you are right, this needs to change. > > Please find a new version attached: > > Mobility EXTensions for IPv6 (MEXT) > > Chair(s): > TBD > > Internet Area Director(s): > Jari Arkko > Mark Townsley > > Internet Area Advisor: > Jari Arkko > > Mailing Lists: > TBD > > Description of Working Group: > > Mobile IPv6 specifies routing support which permits an IPv6 host to > continue using its home address as it moves around the Internet, > enabling continuity of sessions. Mobile IPv6 supports transparency > above the IP layer, including maintenance of active transport level > sessions. In addition, NEMO network mobility mechanisms built on top > of Mobile IPv6 allow managing the mobility of an entire network, as it > changes its point of attachment to the Internet. The base > specifications consist of: > > o RFC 3775 > o RFC 3963 > o RFC 4877 > > The primary goal of the MEXT working group will be to enhance base > IPv6 mobility by continuing work on developments that are required for > wide-scale deployments and specific deployment scenarios > (A). Additionally the working group will ensure that any issues > identified by implementation and interoperability experience are > addressed, and that the base specifications are maintained (B). The > group will also produce informational documentation, such as design > rationale documents or description of specific issues within the > protocol (C). > > Deployment considerations call for solutions to enable dual-stack > operation (A.1), allow the use of multiple interfaces in mobile nodes > (A.2), mechanisms to support high-availability home agents (A.3), and > ways to employ Mobile IPv6 in the presence of firewalls (A.4). In > addition, there are specific needs of the automotive and aviation > communities with regards to route optimization of network mobility > (A.5). Finally, support for AAA is needed as a continuation of earlier > work on bootstrapping (A.6). > > Work items related to large scale deployment include: > > (A.1) A Solution for MIP6 session continuity for dual stack hosts which > attach to IPv4 access networks. Additionally provide a mechanism > for carrying IPv4 packets via the Home agent for MIP6 capable > dual-stack hosts. > > (A.2) A protocol based solution for enhancing the reliability of home > agents and a method to force a host to switch home agents. > > A mechanism to force an MN to switch the HA that is currently > serving it. This is required in deployments where the HA may need to > be taken offline for maintenance. > > (A.3) Use of multiple interfaces. > > The protocols do not today provide support for simultaneous > differentiated use of multiple access technologies, although > several proposals exist for such support, and some of them have > been implemented and tested. > > When a mobile host/router uses multiple network interfaces > simultaneously, or when multiple prefixes are available on a > single network interface, the mobile host/router would end up > with multiple Care-of Addresses (CoAs). In addition, the Home > Agent might be attached to multiple network interfaces, or to a > single network interface with multiple prefixes, hence resulting > in the option to use multiple IP addresses for the Home > Agent. This could result in the possibility of using a multitude > of bi-directional tunnels between pairs of {Home Agent address, > CoA} and a number of associated issues: establishment, selection > and modification of multiple simultaneous tunnels. > > The objective of the WG is to produce a clear problem statement > and to produce standard track specifications to the problems > associated with the simultaneous use of multiple addresses for > either mobile hosts using Mobile IPv6 or mobile routers using > NEMO Basic Support and their variants (FMIPv6, HMIPv6, > etc). Where the effects of having multiple prefixes on a single > interface is identical to the effects of having multiple > interfaces each with a single prefix, the WG will consider a > generalized approach to cater for multiple prefixes available to > a mobile host/router. > > The WG does not plan to define a tunnel selection mechanism, but > may document how to use existing mechanisms based upon > preferences or policies. In particular, the WG will consider > that a tunnel is alive as long as packets can be exchanged with > the corresponding peer. In addition, local information, such as > interface up/down events, or other failure detection mechanisms > can be used to quickly detect failure of tunnel(s). > > Deliverables related to this include > > - A document explaining the motivations for a node using multiple > interfaces and the scenarios where it may end up with multiple > global addresses on its interfaces [Informational] > > - An analysis document explaining what are the limitations for > mobile hosts using multiple simultaneous Care-of Addresses and Home > Agent addresses using Mobile IPv6, whether issues are specific to > Mobile IPv6 or not [Informational]. > > - A protocol extension to support the registration of multiple > Care-of Addresses at a given Home Agent address [Standard > Track]. > > - A "Flow/binding policies exchange" solution for an exchange of > policies from the mobile host/router to the Home Agent and from the > Home Agent to the mobile host/router influencing the choice of the > Care-of Address and Home Agent address [Standard Track]. > > (A.4) Work on solutions to deal with firewalls and the problems that > firewalls cause as identified in RFC 4487. > > (A.5) Route optimization of network mobility. > > Three use cases have been identified for this. These are called > the Aviation case, the Automotive case, and the Personal Mobile > Router (consumer electronics) case, though the actual technical > problems are characterized by the type of movements and > environments more than by the specific industry using the > technology. The group will explore these cases to gather > requirements and proceed with solving the open issues. > > (1) Airline and spacecraft community, who are deploying NEMO for > control systems, as well as Internet connectivity and > entertainment systems. This use case is characterized by fast (~ > 1000 km/h) moving objects over large distances (across > continents). The main technical problem is that tunneling-based > solutions imply a roundtrip to another continent and that BGP > based solutions imply significant churn in the global Internet > routing table. > > (2) Automotive industry who are deploying NEMO for in-car > communication, entertainment, and data gathering, possible > control systems use, and communication to roadside devices. This > use case is characterized by moderately fast (~ 100-300 km/h) > moving objects that employ local or cellular networks for > connectivity. > > (3) Personal Mobile Routers, which are consumer devices that > allow the user to bring a NEMO network with the user while > mobile, and communicate with peer NEMO networks/MNNs. > > After gathering the requirements for these types of deployments, > the working group will evaluate what type of route optimization > needs to be performed (if any), and formulate a solution to > those problems. > > If no requirements for those scenarios can be collected by the > deadline, it will be assumed that the work is premature, and > that type of deployment will be dropped from the WG. > > The group will only consider airline and spacecraft solutions > that combine tunneling solutions for small movements with either > federated tunnel servers or slowly changing end host prefixes. > The group will only consider personal mobile router requirements > about optimized routes to another mobile router belonging to the > same operator. The group will only consider automotive industry > requirements to allow MR-attached hosts to directly access the > network where MR has attached to. Work on automotive and > personal mobile router solutions requires rechartering. > > The WG will not consider routing issues inside the mobile > network. Existing routing protocols (including MANET protocols) > can be used to solve these problems. The group will also not > consider general route optimization, multihoming, or other > problems that are not related to the deployment and maintenance > of NEMO networks. Similarly, the group will not consider or rely > on the results of general routing architecture, Internet > architecture, or identifier-locator split issues that are > discussed in separate, long term efforts elsewhere in the > IETF. Finally, the group will not consider solutions that > require changes from correspondent nodes in the general Internet > > (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG > require AAA support for Mobile IPv6. Part of this work is > already being done in the DIME WG, but the MEXT WG is chartered > to complete a design for RADIUS. > > > Work items related to base specification maintenance include: > > (B.1) Create and maintain issue lists that are generated on the basis > of implementation and interoperability experience. Address > specific issues with specific updates or revisions of the base > specification. One specific area of concern that should be > analyzed and addressed relates to multilink subnets. > > This work item relates only to corrections and > clarifications. The working group shall not revisit design > decisions or change the protocol. > > (B.2) Update the IANA considerations of RFC 3775 to allow extensions for > experimental purposes as well passing of optional vendor-specific > information. > > (B.3) Finish working group documents that are currently in process, and > submit for RFC. This includes prefix delegation protocol mechanism > for network mobility, and a MIB for NEMO Basic Support. > > > Work items related to informational documentation include: > > (C.1) Produce a design rationale that documents the historical > thinking behind the introduction of an alternative security > mechanism, the Authentication Protocol (RFC 4285). > > > Goals and Milestones: > > > Jul 2007 Submit -00 draft on Route Optimization Needs for Aircraft > and Spacecraft Deployments > Jul 2007 Submit -00 draft on Route Optimization Needs for Automobile > and Highway Deployments > Jul 2007 Submit -00 draft on Route Optimization needs for Personal > Mobile Router > Aug 2007 Submit Multiple CoA Registration to IESG > Aug 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for > publication as Informational. > Aug 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for > publication as Informational. > Sep 2007 Submit I-D 'Mobility Header Home Agent Switch Message' to > IESG for publication as a Proposed Standard. > Sep 2007 Submit -00 draft for solution to aircraft/spacecraft problem > Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for > publication as a Proposed Standard. > Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for > publication as a Proposed Standard > Nov 2007 Submit Multiple Interfaces Motivations and Scenario to IESG, > for Informational > Nov 2007 Submit final doc on Route Optimization Needs for Aircraft > and Spacecraft Deployments, for Informational > Nov 2007 Submit Analysis of the use of Multiple Simultaneous Care-of > Addresses and Home Agent addresses in Mobile IPv6 > Dec 2007 Submit final doc on Route Optimization Needs for Automobile > and Highway Deployments, for Informational > Dec 2007 Submit final doc on Route Optimization needs for Personal > Mobile Router, for Informational > Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG > for publication as a Proposed Standard. > Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the > IESG, for Proposed Standard > Dec 2007 Submit I-D 'Home agent reliability' to IESG for publication > as a Proposed Standard. > Jan 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for > publication as a proposed standard. > Jan 2008 Determine how to proceed with remaining automotive/Personal > Mobile Router solutions > Jan 2008 Recharter to work on the remaining automotive/Personal > Mobile Router solutions > Feb 2008 Submit the final doc on MIB for NEMO Basic Support to the > IESG, for Proposed Standard > Feb 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG > for publication as Informational. > Mar 2008 Submit final doc for solution to aircraft/spacecraft problem > to the IESG, for Proposed Standard > Mar 2008 Submit I-D(s) related to specific updates and corrections of > RFC 3775 to IESG for publication as Proposed Standard. > Mar 2008 Submit Flow/binding policies exchange to IESG > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 19 11:18: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 1I0fTj-0003hs-Kk; Tue, 19 Jun 2007 11:18:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fTi-0003hZ-PK for mip6@ietf.org; Tue, 19 Jun 2007 11:18:46 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fTh-00071W-Gk for mip6@ietf.org; Tue, 19 Jun 2007 11:18:46 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 621EB1986A6; Tue, 19 Jun 2007 18:18:44 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2375B198691; Tue, 19 Jun 2007 18:18:44 +0300 (EEST) Message-ID: <4677F3D4.7070807@piuha.net> Date: Tue, 19 Jun 2007 18:18:44 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: benjamin.limck@sg.panasonic.com References: <467700F2.4060204@piuha.net> <010b01c7b21a$1a7111a0$4f5334e0$@limck@sg.panasonic.com> In-Reply-To: <010b01c7b21a$1a7111a0$4f5334e0$@limck@sg.panasonic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: 'Mobile IPv6 Mailing List' Subject: [Mip6] Re: [Monami6] Merged WG charter 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 Benjamin, > I feel that there is a conflict between A.3 and A.5. From my interpretation, > A.3 mentions that the WG will consider multi-homing w.r.t multiple > interfaces for mobile host/routers. However, in A.5, it is said that WG will > NOT consider multi-homing that are not related to NEMO. Suggest removing the > restriction of multi-homing consideration from A.5. > Right. Thanks for catching this. I edited A.5 to remove the restriction. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 19 11:35: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 1I0fkJ-0001W4-Ew; Tue, 19 Jun 2007 11:35:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fkH-0001Vz-VO for mip6@ietf.org; Tue, 19 Jun 2007 11:35:53 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fkH-00029H-1A for mip6@ietf.org; Tue, 19 Jun 2007 11:35:53 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 62DDB1986A6; Tue, 19 Jun 2007 18:35:52 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id F0829198691; Tue, 19 Jun 2007 18:35:51 +0300 (EEST) Message-ID: <4677F7D8.9080104@piuha.net> Date: Tue, 19 Jun 2007 18:35:52 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Merged WG charter References: <5vrfma$1hlcng@smtp06.syd.iprimus.net.au> In-Reply-To: <5vrfma$1hlcng@smtp06.syd.iprimus.net.au> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 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 Thanks for your comments, Hesham! > => I would list those in bullet format for clarity by placing (A), (B)..et > first then the text describing it. Same for the text below. > Ok. > => I'd reword the above to say: > Address the specific needs of automotive and aviation communities for route > optimisation in nemo. > Ok. > => s/may need/needs > Changed. > > > > (A.3) Use of multiple interfaces. > > > > The protocols do not today provide support for simultaneous > > differentiated use of multiple access technologies, although > > several proposals exist for such support, and some of them have > > been implemented and tested. > > => Reword: Today, the protocols do not provide suppport... > Got it. > > When a mobile host/router uses multiple network interfaces > > simultaneously, or when multiple prefixes are available on a > > single network interface, the mobile host/router would end up > > with multiple Care-of Addresses (CoAs). In addition, the Home > > Agent might be attached to multiple network interfaces, or to a > > single network interface with multiple prefixes, hence > > resulting > > in the option to use multiple IP addresses for the Home > > Agent. This could result in the possibility of using a > > multitude > > of bi-directional tunnels between pairs of {Home Agent address, > > CoA} and a number of associated issues: establishment, > > selection > > and modification of multiple simultaneous tunnels. > > => The monami work was focused on the multiple CoA scenarios and explicitly > removed the multiple HoA scenarios as a condition of the WG starting. We > might need to discuss the impact of adding that back on the amount of work, > overlap with site multihoming ...etc. > I did not change anything regarding this in the charter. I'd like to avoid too much reworking the charters beyond the merge. Or do you have a specific text suggestion? > => We discussed, online and offline the possibility of having two drafts > here, one specifying the protocol (transport) and one defining the format > for the flow descriptors. Are we now merging them into one? > No, this is just me forgetting to make that change. I did it now, plus changed the milestones. > > > > (A.4) Work on solutions to deal with firewalls and the problems that > > firewalls cause as identified in RFC 4487. > > => Hmm. I have some doubts about the "work on a solution" part. We need to > assess those problems and decide whether a solution is needed. If needed > then we should produce one. We discussed these issues in the FW DT and it's > not clear, at least to me, that a solution is a certainty. > Ok. But again, I don't want to hold a real rechartering discussion and most of the work items should just stay, unless they either have been completed or have something obviously wrong with them. I do agree with your principle, though. It could be that we can leave the text as is, and simply handle this as a part of the management of the group. New version: Mobility EXTensions for IPv6 (MEXT) Chair(s): TBD Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: TBD Description of Working Group: Mobile IPv6 specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions. In addition, NEMO network mobility mechanisms built on top of Mobile IPv6 allow managing the mobility of an entire network, as it changes its point of attachment to the Internet. The base specifications consist of: o RFC 3775 o RFC 3963 o RFC 4877 The primary goal of the MEXT working group will be to (A) enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios. Additionally, (B) the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. (C) The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. Deployment considerations call for (A.1) solutions to enable dual-stack operation, (A.2) allowing the use of multiple interfaces in mobile nodes, (A.3) mechanisms to support high-availability home agents, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, (A.5) address the specific needs of automotive and aviation communities for route optimisation in network mobility, and (A.6) support for AAA is needed as a continuation of earlier work on bootstrapping. Work items related to large scale deployment include: (A.1) A Solution for MIP6 session continuity for dual stack hosts which attach to IPv4 access networks. Additionally provide a mechanism for carrying IPv4 packets via the Home agent for MIP6 capable dual-stack hosts. (A.2) A protocol based solution for enhancing the reliability of home agents and a method to force a host to switch home agents. A mechanism to force an MN to switch the HA that is currently serving it. This is required in deployments where the HA needs to be taken offline for maintenance. (A.3) Use of multiple interfaces. Today, the protocols do not provide suppport for simultaneous differentiated use of multiple access technologies. Several proposals exist for such support, and some of them have been implemented and tested. When a mobile host/router uses multiple network interfaces simultaneously, or when multiple prefixes are available on a single network interface, the mobile host/router would end up with multiple Care-of Addresses (CoAs). In addition, the Home Agent might be attached to multiple network interfaces, or to a single network interface with multiple prefixes, hence resulting in the option to use multiple IP addresses for the Home Agent. This could result in the possibility of using a multitude of bi-directional tunnels between pairs of {Home Agent address, CoA} and a number of associated issues: establishment, selection and modification of multiple simultaneous tunnels. The objective of the WG is to produce a clear problem statement and to produce standard track specifications to the problems associated with the simultaneous use of multiple addresses for either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support and their variants (FMIPv6, HMIPv6, etc). Where the effects of having multiple prefixes on a single interface is identical to the effects of having multiple interfaces each with a single prefix, the WG will consider a generalized approach to cater for multiple prefixes available to a mobile host/router. The WG does not plan to define a tunnel selection mechanism, but may document how to use existing mechanisms based upon preferences or policies. In particular, the WG will consider that a tunnel is alive as long as packets can be exchanged with the corresponding peer. In addition, local information, such as interface up/down events, or other failure detection mechanisms can be used to quickly detect failure of tunnel(s). Deliverables related to this include - A document explaining the motivations for a node using multiple interfaces and the scenarios where it may end up with multiple global addresses on its interfaces [Informational] - An analysis document explaining what are the limitations for mobile hosts using multiple simultaneous Care-of Addresses and Home Agent addresses using Mobile IPv6, whether issues are specific to Mobile IPv6 or not [Informational]. - A protocol extension to support the registration of multiple Care-of Addresses at a given Home Agent address [Standard Track]. - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport [both Standard Track]. (A.4) Work on solutions to deal with firewalls and the problems that firewalls cause as identified in RFC 4487. (A.5) Route optimization of network mobility. Three use cases have been identified for this. These are called the Aviation case, the Automotive case, and the Personal Mobile Router (consumer electronics) case, though the actual technical problems are characterized by the type of movements and environments more than by the specific industry using the technology. The group will explore these cases to gather requirements and proceed with solving the open issues. (1) Airline and spacecraft community, who are deploying NEMO for control systems, as well as Internet connectivity and entertainment systems. This use case is characterized by fast (~ 1000 km/h) moving objects over large distances (across continents). The main technical problem is that tunneling-based solutions imply a roundtrip to another continent and that BGP based solutions imply significant churn in the global Internet routing table. (2) Automotive industry who are deploying NEMO for in-car communication, entertainment, and data gathering, possible control systems use, and communication to roadside devices. This use case is characterized by moderately fast (~ 100-300 km/h) moving objects that employ local or cellular networks for connectivity. (3) Personal Mobile Routers, which are consumer devices that allow the user to bring a NEMO network with the user while mobile, and communicate with peer NEMO networks/MNNs. After gathering the requirements for these types of deployments, the working group will evaluate what type of route optimization needs to be performed (if any), and formulate a solution to those problems. If no requirements for those scenarios can be collected by the deadline, it will be assumed that the work is premature, and that type of deployment will be dropped from the WG. The group will only consider airline and spacecraft solutions that combine tunneling solutions for small movements with either federated tunnel servers or slowly changing end host prefixes. The group will only consider personal mobile router requirements about optimized routes to another mobile router belonging to the same operator. The group will only consider automotive industry requirements to allow MR-attached hosts to directly access the network where MR has attached to. Work on automotive and personal mobile router solutions requires rechartering. The WG will not consider routing issues inside the mobile network. Existing routing protocols (including MANET protocols) can be used to solve these problems. The group will also not consider general route optimization, or other problems that are not related to the deployment and maintenance of NEMO networks. Similarly, the group will not consider or rely on the results of general routing architecture, Internet architecture, or identifier-locator split issues that are discussed in separate, long term efforts elsewhere in the IETF. Finally, the group will not consider solutions that require changes from correspondent nodes in the general Internet (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG require AAA support for Mobile IPv6. Part of this work is already being done in the DIME WG, but the MEXT WG is chartered to complete a design for RADIUS. Work items related to base specification maintenance include: (B.1) Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. One specific area of concern that should be analyzed and addressed relates to multilink subnets. This work item relates only to corrections and clarifications. The working group shall not revisit design decisions or change the protocol. (B.2) Update the IANA considerations of RFC 3775 to allow extensions for experimental purposes as well passing of optional vendor-specific information. (B.3) Finish working group documents that are currently in process, and submit for RFC. This includes prefix delegation protocol mechanism for network mobility, and a MIB for NEMO Basic Support. Work items related to informational documentation include: (C.1) Produce a design rationale that documents the historical thinking behind the introduction of an alternative security mechanism, the Authentication Protocol (RFC 4285). Goals and Milestones: Jul 2007 Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments Jul 2007 Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments Jul 2007 Submit -00 draft on Route Optimization needs for Personal Mobile Router Aug 2007 Submit Multiple CoA Registration to IESG Aug 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational. Aug 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational. Sep 2007 Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard. Sep 2007 Submit -00 draft for solution to aircraft/spacecraft problem Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard. Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard Nov 2007 Submit Multiple Interfaces Motivations and Scenario to IESG, for Informational Nov 2007 Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational Nov 2007 Submit Analysis of the use of Multiple Simultaneous Care-of Addresses and Home Agent addresses in Mobile IPv6 Dec 2007 Submit final doc on Route Optimization Needs for Automobile and Highway Deployments, for Informational Dec 2007 Submit final doc on Route Optimization needs for Personal Mobile Router, for Informational Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard. Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard Dec 2007 Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard. Jan 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. Jan 2008 Determine how to proceed with remaining automotive/Personal Mobile Router solutions Jan 2008 Recharter to work on the remaining automotive/Personal Mobile Router solutions Feb 2008 Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard Feb 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Mar 2008 Submit final doc for solution to aircraft/spacecraft problem to the IESG, for Proposed Standard Mar 2008 Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. Mar 2008 Submit Flow/binding policy format to IESG, for Proposed Standard Mar 2008 Submit Flow/binding policy transport to IESG, for Proposed Standard _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 19 12:42: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 1I0gmg-0006v6-1x; Tue, 19 Jun 2007 12:42:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gme-0006uz-HM for mip6@ietf.org; Tue, 19 Jun 2007 12:42:24 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0gmd-0006xO-7D for mip6@ietf.org; Tue, 19 Jun 2007 12:42:24 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 09:42:22 -0700 Message-ID: <4678076E.4020204@azairenet.com> Date: Tue, 19 Jun 2007 09:42:22 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mip6] Merged WG charter References: <5vrfma$1hlcng@smtp06.syd.iprimus.net.au> <4677F7D8.9080104@piuha.net> In-Reply-To: <4677F7D8.9080104@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2007 16:42:22.0487 (UTC) FILETIME=[CF36FA70:01C7B290] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Jari Arkko wrote: >> > (A.4) Work on solutions to deal with firewalls and the problems that >> > firewalls cause as identified in RFC 4487. >> >> => Hmm. I have some doubts about the "work on a solution" part. We need to >> assess those problems and decide whether a solution is needed. If needed >> then we should produce one. We discussed these issues in the FW DT and it's >> not clear, at least to me, that a solution is a certainty. > > Ok. But again, I don't want to hold a real rechartering discussion and most > of the work items should just stay, unless they either have been completed > or have something obviously wrong with them. > > I do agree with your principle, though. It could be that we can leave the > text as is, and simply handle this as a part of the management of the > group. Well, there are issues. We have published a document on this. http://www.ietf.org/rfc/rfc4487.txt If we conclude that there is no need for specifying anything new, we would at least need a BCP recommending some firewall configuration for MIPv6. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 19 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 1I0jHH-000072-UG; Tue, 19 Jun 2007 15:22:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jHH-00006x-6V for mip6@ietf.org; Tue, 19 Jun 2007 15:22:11 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0jHF-0002Sz-Ti for mip6@ietf.org; Tue, 19 Jun 2007 15:22:11 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id CE493212F31; Tue, 19 Jun 2007 22:22:08 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 8BC82212DF2; Tue, 19 Jun 2007 22:22:08 +0300 (EEST) Message-ID: <46782CE1.2020605@nomadiclab.com> Date: Tue, 19 Jun 2007 22:22:09 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Jari Arkko , benjamin.limck@sg.panasonic.com, alexandru.petrescu@gmail.com Subject: Re: [Mip6] Merged WG charter References: <5vrfma$1hlcng@smtp06.syd.iprimus.net.au> <4677F7D8.9080104@piuha.net> In-Reply-To: <4677F7D8.9080104@piuha.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 > [...] The group will also not > consider general route optimization, or other problems that are > not related to the deployment and maintenance of NEMO > networks. [...] Jari, Benjamin, Alexandru, shouldn't this be modified to something like the following sentence to avoid conflicts with Shim6? The group will not consider general multi-homing problems that are not related to the deployment and maintenance of Mobile IPv6 or NEMO networks. The group will also not consider general route optimization, or other problems that are not related to the deployment and maintenance of NEMO networks. Best, - Christian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 19 22:27: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 1I0pug-0005xw-2t; Tue, 19 Jun 2007 22:27:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0pue-0005wI-KW for mip6@ietf.org; Tue, 19 Jun 2007 22:27:17 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0pud-0008HL-1k for mip6@ietf.org; Tue, 19 Jun 2007 22:27:16 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id l5K2RBu0017326; Wed, 20 Jun 2007 11:27:11 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id l5K2RBH08644; Wed, 20 Jun 2007 11:27:11 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id l5K2RAZ22634; Wed, 20 Jun 2007 11:27:10 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.101]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 10:25:44 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Wed, 20 Jun 2007 10:25:41 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Wed, 20 Jun 2007 10:25:41 +0800 From: "Benjamin Lim" To: "'Christian Vogt'" References: <5vrfma$1hlcng@smtp06.syd.iprimus.net.au> <4677F7D8.9080104@piuha.net> <46782CE1.2020605@nomadiclab.com> In-Reply-To: <46782CE1.2020605@nomadiclab.com> Subject: RE: [Mip6] Merged WG charter Date: Wed, 20 Jun 2007 10:25:35 +0800 Organization: Panasonic Singapore Labs Pte Ltd Message-ID: <010201c7b2e2$48e99890$dabcc9b0$@limck@sg.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aceypv6mJYnbe5/DQZqtq4z5skNpEAAOWLhA Content-Language: en-us X-OriginalArrivalTime: 20 Jun 2007 02:25:44.0813 (UTC) FILETIME=[4E3A11D0:01C7B2E2] X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'Mobile IPv6 Mailing List' , alexandru.petrescu@gmail.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: benjamin.limck@sg.panasonic.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Christian, I agree that we should avoid conflicts with Shim6. My concern is that with your proposed text is flow filtering for NEMO within scope of MEXT? Regards, Benjamin Lim > -----Original Message----- > From: Christian Vogt [mailto:christian.vogt@nomadiclab.com] > Sent: Wednesday, June 20, 2007 3:22 AM > To: Jari Arkko; benjamin.limck@sg.panasonic.com; alexandru.petrescu@gmail.com > Cc: 'Mobile IPv6 Mailing List' > Subject: Re: [Mip6] Merged WG charter > > > [...] The group will also not > > consider general route optimization, or other problems that are > > not related to the deployment and maintenance of NEMO > > networks. [...] > > Jari, Benjamin, Alexandru, > > shouldn't this be modified to something like the following sentence to > avoid conflicts with Shim6? > > The group will not > consider general multi-homing problems that are not related to > > the deployment and maintenance of Mobile IPv6 or NEMO networks. > The group will also not consider general route optimization, or > other problems that are not related to the deployment and > maintenance of NEMO networks. > > Best, > - Christian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 20 00:22:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0riR-0001MU-Kr; Wed, 20 Jun 2007 00:22:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0riQ-0001ML-V0 for mip6@ietf.org; Wed, 20 Jun 2007 00:22:46 -0400 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0riO-0007EX-R4 for mip6@ietf.org; Wed, 20 Jun 2007 00:22:46 -0400 Received: from oaamta06ps.mx.bigpond.com ([124.190.105.118]) by omta01ps.mx.bigpond.com with ESMTP id <20070620042238.UZHJ19666.omta01ps.mx.bigpond.com@oaamta06ps.mx.bigpond.com>; Wed, 20 Jun 2007 04:22:38 +0000 Received: from PC20005 ([124.190.105.118]) by oaamta06ps.mx.bigpond.com with ESMTP id <20070620042237.MZPR6690.oaamta06ps.mx.bigpond.com@PC20005>; Wed, 20 Jun 2007 04:22:37 +0000 From: "Hesham Soliman" To: "'Jari Arkko'" Subject: RE: [Mip6] Merged WG charter Date: Wed, 20 Jun 2007 14:22:31 +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.3138 Thread-Index: Aceyh5HPysf/UrPUQl63qGRNXP4eyQAaV/GA In-Reply-To: <4677F7D8.9080104@piuha.net> Message-Id: <20070620042237.MZPR6690.oaamta06ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc 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 > > => The monami work was focused on the multiple CoA > scenarios and explicitly > > removed the multiple HoA scenarios as a condition of the > WG starting. We > > might need to discuss the impact of adding that back on > the amount of work, > > overlap with site multihoming ...etc. > > > > I did not change anything regarding this in the charter. I'd like to > avoid too much reworking the charters beyond the merge. Or > do you have a specific text suggestion? => Ok. If anything, I would associate the multiple HoA work with the analysis document rather than the standards track work. But I get your point, I agree that we should avoid reworking the charter at this point. > > => Hmm. I have some doubts about the "work on a solution" > part. We need to > > assess those problems and decide whether a solution is > needed. If needed > > then we should produce one. We discussed these issues in > the FW DT and it's > > not clear, at least to me, that a solution is a certainty. > > > > Ok. But again, I don't want to hold a real rechartering > discussion and most > of the work items should just stay, unless they either have > been completed > or have something obviously wrong with them. > > I do agree with your principle, though. It could be that we > can leave the > text as is, and simply handle this as a part of the management of the > group. => Fine with me. Below are comments on the rest of the charter. > (A.5) Route optimization of network mobility. > > Three use cases have been identified for this. These are called > the Aviation case, the Automotive case, and the Personal Mobile > Router (consumer electronics) case, though the actual technical > problems are characterized by the type of movements and > environments more than by the specific industry using the > technology. The group will explore these cases to gather > requirements and proceed with solving the open issues. > > (1) Airline and spacecraft community, who are deploying NEMO for > control systems, as well as Internet connectivity and > entertainment systems. This use case is characterized by fast (~ > 1000 km/h) moving objects over large distances (across > continents). The main technical problem is that tunneling-based > solutions imply a roundtrip to another continent and that BGP > based solutions imply significant churn in the global Internet > routing table. > > (2) Automotive industry who are deploying NEMO for in-car > communication, entertainment, and data gathering, possible > control systems use, and communication to roadside devices. This > use case is characterized by moderately fast (~ 100-300 km/h) > moving objects that employ local or cellular networks for > connectivity. > > (3) Personal Mobile Routers, which are consumer devices that > allow the user to bring a NEMO network with the user while > mobile, and communicate with peer NEMO networks/MNNs. => I find the association with speed a little misleading. After all, we only care about the frequency of handovers and route optimisation, which don't necessarily correlate with speed. It's up to you to decide whether you should keep it or remove it (not a huge issue) but at least in the above text the Personal router case just doesn't fit as a separate bullet. If the main distinction is speed then the Personal router case can fall under with of the bullets above it. > The group will only consider airline and spacecraft solutions > that combine tunneling solutions for small movements with either > federated tunnel servers or slowly changing end host prefixes. > The group will only consider personal mobile router requirements > about optimized routes to another mobile router belonging to the > same operator. The group will only consider automotive industry > requirements to allow MR-attached hosts to directly access the > network where MR has attached to. Work on automotive and > personal mobile router solutions requires rechartering. => Again, the scope of the Personal router work sounds odd, but it's saved by the last sentence. > (B.3) Finish working group documents that are currently in > process, and > submit for RFC. This includes prefix delegation protocol mechanism > for network mobility, and a MIB for NEMO Basic Support. > > > Work items related to informational documentation include: > > (C.1) Produce a design rationale that documents the historical > thinking behind the introduction of an alternative security > mechanism, the Authentication Protocol (RFC 4285). > => I couldn't see the DSMIP work above but it's listed in the goals section. That's all from me, thanks, Hesham > > Goals and Milestones: > > > Jul 2007 Submit -00 draft on Route Optimization Needs for > Aircraft and > Spacecraft Deployments > Jul 2007 Submit -00 draft on Route Optimization Needs for > Automobile and > Highway Deployments > Jul 2007 Submit -00 draft on Route Optimization needs for Personal > Mobile Router > Aug 2007 Submit Multiple CoA Registration to IESG > Aug 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for > publication as Informational. > Aug 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for > publication > as Informational. > Sep 2007 Submit I-D 'Mobility Header Home Agent Switch > Message' to IESG > for publication as a Proposed Standard. > Sep 2007 Submit -00 draft for solution to aircraft/spacecraft problem > Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for > publication as a Proposed Standard. > Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for > publication as a Proposed Standard > Nov 2007 Submit Multiple Interfaces Motivations and Scenario to IESG, > for Informational > Nov 2007 Submit final doc on Route Optimization Needs for > Aircraft and > Spacecraft Deployments, for Informational > Nov 2007 Submit Analysis of the use of Multiple Simultaneous Care-of > Addresses and Home Agent addresses in Mobile IPv6 > Dec 2007 Submit final doc on Route Optimization Needs for > Automobile and > Highway Deployments, for Informational > Dec 2007 Submit final doc on Route Optimization needs for Personal > Mobile Router, for Informational > Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' > to IESG for > publication as a Proposed Standard. > Dec 2007 Submit the final doc on Prefix Delegation for NEMO > to the IESG, > for Proposed Standard > Dec 2007 Submit I-D 'Home agent reliability' to IESG for > publication as > a Proposed Standard. > Jan 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for > publication as a proposed standard. > Jan 2008 Determine how to proceed with remaining automotive/Personal > Mobile Router solutions > Jan 2008 Recharter to work on the remaining > automotive/Personal Mobile > Router solutions > Feb 2008 Submit the final doc on MIB for NEMO Basic Support > to the IESG, > for Proposed Standard > Feb 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' > to IESG for > publication as Informational. > Mar 2008 Submit final doc for solution to > aircraft/spacecraft problem to > the IESG, for Proposed Standard > Mar 2008 Submit I-D(s) related to specific updates and corrections of > RFC 3775 to IESG for publication as Proposed Standard. > Mar 2008 Submit Flow/binding policy format to IESG, for > Proposed Standard > Mar 2008 Submit Flow/binding policy transport to IESG, for > Proposed Standard > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 21 02:35: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 1I1GGO-0001Tf-Nt; Thu, 21 Jun 2007 02:35:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1GGN-0001TS-VM for mip6@ietf.org; Thu, 21 Jun 2007 02:35:27 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1GGM-0001iY-N7 for mip6@ietf.org; Thu, 21 Jun 2007 02:35:27 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0FCA9212DF2; Thu, 21 Jun 2007 09:35:25 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id CBB83212DAB; Thu, 21 Jun 2007 09:35:24 +0300 (EEST) Message-ID: <467A1C2E.60406@nomadiclab.com> Date: Thu, 21 Jun 2007 09:35:26 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: benjamin.limck@sg.panasonic.com Subject: Re: [Mip6] Merged WG charter References: <5vrfma$1hlcng@smtp06.syd.iprimus.net.au> <4677F7D8.9080104@piuha.net> <46782CE1.2020605@nomadiclab.com> <010201c7b2e2$48e99890$dabcc9b0$@limck@sg.panasonic.com> In-Reply-To: <010201c7b2e2$48e99890$dabcc9b0$@limck@sg.panasonic.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: 'Mobile IPv6 Mailing List' , alexandru.petrescu@gmail.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 Hello Benjamin: > I agree that we should avoid conflicts with Shim6. My concern is that with > your proposed text is flow filtering for NEMO within scope of MEXT? Yes, it is. The text basically says that the WG will consider multi-homing only for host/network mobility, but not beyond that. Best, - Christian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 21 04:06: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 1I1Hgm-0005Xq-9g; Thu, 21 Jun 2007 04:06:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Hgk-0005Xk-RW for mip6@ietf.org; Thu, 21 Jun 2007 04:06:46 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Hgk-0007qp-Dk for mip6@ietf.org; Thu, 21 Jun 2007 04:06:46 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8D01C1986A6; Thu, 21 Jun 2007 11:06:45 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 54A2319868B; Thu, 21 Jun 2007 11:06:45 +0300 (EEST) Message-ID: <467A3195.6090705@piuha.net> Date: Thu, 21 Jun 2007 11:06:45 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Merged WG charter References: <20070620042237.MZPR6690.oaamta06ps.mx.bigpond.com@PC20005> In-Reply-To: <20070620042237.MZPR6690.oaamta06ps.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 Hesham, > > I did not change anything regarding this in the charter. I'd like to > > avoid too much reworking the charters beyond the merge. Or > > do you have a specific text suggestion? > > => Ok. If anything, I would associate the multiple HoA work with the > analysis document rather than the standards track work. But I get your > point, I agree that we should avoid reworking the charter at this point. > I think this is already in the text about the individual documents. > > (3) Personal Mobile Routers, which are consumer devices that > > allow the user to bring a NEMO network with the user while > > mobile, and communicate with peer NEMO networks/MNNs. > > => I find the association with speed a little misleading. After all, we only > care about the frequency of handovers and route optimisation, which don't > necessarily correlate with speed. It's up to you to decide whether you > should keep it or remove it (not a huge issue) but at least in the above > text the Personal router case just doesn't fit as a separate bullet. If the > main distinction is speed then the Personal router case can fall under with > of the bullets above it. > I hear you, but this text comes from a compromise that I made with the rest of the IESG to get the charter approved. I would rather have that discussion again. > > The group will only consider airline and spacecraft solutions > > that combine tunneling solutions for small movements with either > > federated tunnel servers or slowly changing end host prefixes. > > The group will only consider personal mobile router requirements > > about optimized routes to another mobile router belonging to the > > same operator. The group will only consider automotive industry > > requirements to allow MR-attached hosts to directly access the > > network where MR has attached to. Work on automotive and > > personal mobile router solutions requires rechartering. > > => Again, the scope of the Personal router work sounds odd, but it's saved > by the last sentence. > Again, part of the same compromise. > > (B.3) Finish working group documents that are currently in > > process, and > > submit for RFC. This includes prefix delegation protocol mechanism > > for network mobility, and a MIB for NEMO Basic Support. > > > > > > Work items related to informational documentation include: > > > > (C.1) Produce a design rationale that documents the historical > > thinking behind the introduction of an alternative security > > mechanism, the Authentication Protocol (RFC 4285). > > > > => I couldn't see the DSMIP work above but it's listed in the goals section. > There's protocol work in the goals section (A.1) and milestones. If you are referring to the problem definition document, it has already been submitted to the IESG and even approved, so there is no need to keep the informational document in the charter anymore. > That's all from me, thanks > Thank you for your detailed review. It has helped a lot. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 21 04:28: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 1I1I1i-0003vR-0N; Thu, 21 Jun 2007 04:28:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1I1g-0003uq-If for mip6@ietf.org; Thu, 21 Jun 2007 04:28:24 -0400 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1I1d-0001x9-3J for mip6@ietf.org; Thu, 21 Jun 2007 04:28:24 -0400 Received: from oaamta01ps.mx.bigpond.com ([124.190.105.118]) by omta01ps.mx.bigpond.com with ESMTP id <20070621082818.IPIU1740.omta01ps.mx.bigpond.com@oaamta01ps.mx.bigpond.com>; Thu, 21 Jun 2007 08:28:18 +0000 Received: from PC20005 ([124.190.105.118]) by oaamta01ps.mx.bigpond.com with ESMTP id <20070621082817.EDKS16656.oaamta01ps.mx.bigpond.com@PC20005>; Thu, 21 Jun 2007 08:28:17 +0000 From: "Hesham Soliman" To: "'Jari Arkko'" Subject: RE: [Mip6] Merged WG charter Date: Thu, 21 Jun 2007 18:28:07 +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: Acez2zdHf4MgaYcqRo6yU67ssW5nDgAAtF5Q In-Reply-To: <467A3195.6090705@piuha.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Message-Id: <20070621082817.EDKS16656.oaamta01ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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 Hi Jari, Thanks for the response, I'm ok with this. Hesham > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Thursday, June 21, 2007 6:07 PM > To: Hesham Soliman > Cc: 'Mobile IPv6 Mailing List' > Subject: Re: [Mip6] Merged WG charter > > Hesham, > > > > I did not change anything regarding this in the > charter. I'd like to > > > avoid too much reworking the charters beyond the merge. Or > > > do you have a specific text suggestion? > > > > => Ok. If anything, I would associate the multiple HoA > work with the > > analysis document rather than the standards track work. > But I get your > > point, I agree that we should avoid reworking the charter > at this point. > > > > I think this is already in the text about the individual documents. > > > > (3) Personal Mobile Routers, which are consumer devices that > > > allow the user to bring a NEMO network with the user while > > > mobile, and communicate with peer NEMO networks/MNNs. > > > > => I find the association with speed a little misleading. > After all, we only > > care about the frequency of handovers and route > optimisation, which don't > > necessarily correlate with speed. It's up to you to > decide whether you > > should keep it or remove it (not a huge issue) but at > least in the above > > text the Personal router case just doesn't fit as a > separate bullet. If the > > main distinction is speed then the Personal router case > can fall under with > > of the bullets above it. > > > > I hear you, but this text comes from a compromise that I made with > the rest of the IESG to get the charter approved. I would rather have > that discussion again. > > > > The group will only consider airline and spacecraft solutions > > > that combine tunneling solutions for small movements with either > > > federated tunnel servers or slowly changing end host prefixes. > > > The group will only consider personal mobile router requirements > > > about optimized routes to another mobile router belonging to the > > > same operator. The group will only consider automotive industry > > > requirements to allow MR-attached hosts to directly access the > > > network where MR has attached to. Work on automotive and > > > personal mobile router solutions requires rechartering. > > > > => Again, the scope of the Personal router work sounds > odd, but it's saved > > by the last sentence. > > > > Again, part of the same compromise. > > > > (B.3) Finish working group documents that are currently in > > > process, and > > > submit for RFC. This includes prefix delegation > protocol mechanism > > > for network mobility, and a MIB for NEMO Basic Support. > > > > > > > > > Work items related to informational documentation include: > > > > > > (C.1) Produce a design rationale that documents the historical > > > thinking behind the introduction of an alternative security > > > mechanism, the Authentication Protocol (RFC 4285). > > > > > > > => I couldn't see the DSMIP work above but it's listed in > the goals section. > > > > There's protocol work in the goals section (A.1) and > milestones. If you > are referring > to the problem definition document, it has already been > submitted to the > IESG > and even approved, so there is no need to keep the > informational document > in the charter anymore. > > > That's all from me, thanks > > > Thank you for your detailed review. It has helped a lot. > > Jari > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 21 07:28: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 1I1KpX-0001gk-MY; Thu, 21 Jun 2007 07:28:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1KpW-0001cs-Em for mip6@ietf.org; Thu, 21 Jun 2007 07:28:02 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1KpV-0001fV-5s for mip6@ietf.org; Thu, 21 Jun 2007 07:28:02 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D1B4B1986A6; Thu, 21 Jun 2007 14:27:59 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 92C2619868B; Thu, 21 Jun 2007 14:27:59 +0300 (EEST) Message-ID: <467A60BF.2040308@piuha.net> Date: Thu, 21 Jun 2007 14:27:59 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Christian Vogt Subject: Re: [Mip6] Merged WG charter References: <5vrfma$1hlcng@smtp06.syd.iprimus.net.au> <4677F7D8.9080104@piuha.net> <46782CE1.2020605@nomadiclab.com> In-Reply-To: <46782CE1.2020605@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: 'Mobile IPv6 Mailing List' , alexandru.petrescu@gmail.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 Christian, > shouldn't this be modified to something like the following sentence to > avoid conflicts with Shim6? > > The group will not > consider general multi-homing problems that are not related to > > the deployment and maintenance of Mobile IPv6 or NEMO networks. > The group will also not consider general route optimization, or > other problems that are not related to the deployment and > maintenance of NEMO networks. > Yes, that's better. Thanks. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 21 08:24: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 1I1Lhg-00059T-8h; Thu, 21 Jun 2007 08:24:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Lhd-00058L-Nw for mip6@ietf.org; Thu, 21 Jun 2007 08:23:57 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I1Lhd-0000Qo-DQ for mip6@ietf.org; Thu, 21 Jun 2007 08:23:57 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1182428636!6849766!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 27810 invoked from network); 21 Jun 2007 12:23:56 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-10.tower-128.messagelabs.com with SMTP; 21 Jun 2007 12:23:56 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l5LCNnBi011846; Thu, 21 Jun 2007 07:23:50 -0500 (CDT) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l5LCNmGj022002; Thu, 21 Jun 2007 07:23:49 -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 l5LCNkbY021967; Thu, 21 Jun 2007 07:23:47 -0500 (CDT) Message-ID: <467A6DD1.8070909@gmail.com> Date: Thu, 21 Jun 2007 14:23:45 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Jari Arkko Subject: Re: aircraft, automotive, PAN and 'speed' (was: [Mip6] Merged WG charter) References: <20070620042237.MZPR6690.oaamta06ps.mx.bigpond.com@PC20005> <467A3195.6090705@piuha.net> In-Reply-To: <467A3195.6090705@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000751-0, 20/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Jari Arkko wrote: [...] >> > (3) Personal Mobile Routers, which are consumer devices that >> > allow the user to bring a NEMO network with the user while >> > mobile, and communicate with peer NEMO networks/MNNs. >> >> => I find the association with speed a little misleading. After all, we only >> care about the frequency of handovers and route optimisation, which don't >> necessarily correlate with speed. It's up to you to decide whether you >> should keep it or remove it (not a huge issue) but at least in the above >> text the Personal router case just doesn't fit as a separate bullet. If the >> main distinction is speed then the Personal router case can fall under with >> of the bullets above it. >> > > I hear you, but this text comes from a compromise that I made with > the rest of the IESG to get the charter approved. I would rather have > that discussion again. Not sure you prefer or not to re-discuss that again, sounds as if you don't(?) If to be re-discussed: a classification of IP mobility protocols and mobile devices by the speed (time and distance) they physically move makes indeed some sense to me (flying aircraft:fast-speed/long-distance, wheeled vehicle:moderate-speed/local-distance and walk:slow-speed/micro-distance) but it would make more sense if we used it side-by-side with an IP-relevant definition and classificaiton of speed. A mobile host moving at 130kmph is very fast and changing its address twice-per-hour is very slow - physical speed different than IP-relevant 'speed' for the same IP device. Hesham mentioned 'frequency of handover' which could too be defined. For PMR better fitting your classification: PMR doesn't move seen by LFN, so zero-speed/zero-distance. But a personal area network PMR+LFN does move maybe as a slow-speed/local-distance (like automotive) or slower, as a walk-speed/nano-distance. Finally, we should probably use PAN, LAN and MAN IEEE terminology too. 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 Jun 21 08:33: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 1I1Lqi-0007hk-5l; Thu, 21 Jun 2007 08:33:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Lqh-0007hb-54 for mip6@ietf.org; Thu, 21 Jun 2007 08:33:19 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Lqf-0003Nd-Sm for mip6@ietf.org; Thu, 21 Jun 2007 08:33:19 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 824801986A6; Thu, 21 Jun 2007 15:33:16 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 46AC2198691; Thu, 21 Jun 2007 15:33:16 +0300 (EEST) Message-ID: <467A700C.5080809@piuha.net> Date: Thu, 21 Jun 2007 15:33:16 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Alexandru Petrescu References: <20070620042237.MZPR6690.oaamta06ps.mx.bigpond.com@PC20005> <467A3195.6090705@piuha.net> <467A6DD1.8070909@gmail.com> In-Reply-To: <467A6DD1.8070909@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: 'Mobile IPv6 Mailing List' Subject: [Mip6] Re: aircraft, automotive, PAN and 'speed' 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 Alexandru, > Not sure you prefer or not to re-discuss that again, sounds as if you > don't(?) Sorry, there was a crucial "not" word missing from my e-mail. I don't want to discuss this again, because that might mean having another lengthy discussion at the IESG about it. We know what we need to do for the NEMO RO, I think, so I would suggest we get on with that... Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 21 11:44:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1OpY-0008FV-Is; Thu, 21 Jun 2007 11:44:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1OpX-0008FQ-Ch for mip6@ietf.org; Thu, 21 Jun 2007 11:44:19 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1OpU-0001CA-UU for mip6@ietf.org; Thu, 21 Jun 2007 11:44:19 -0400 Received: from iseran.local ([80.10.36.111]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5LFhuOH016098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 17:44:07 +0200 Date: Thu, 21 Jun 2007 17:37:19 +0200 From: Thierry Ernst To: Jari Arkko Subject: Re: [Mip6] Merged WG charter Message-Id: <20070621173719.67d17e7f.thierry.ernst@inria.fr> In-Reply-To: <467A60BF.2040308@piuha.net> References: <5vrfma$1hlcng@smtp06.syd.iprimus.net.au> <4677F7D8.9080104@piuha.net> <46782CE1.2020605@nomadiclab.com> <467A60BF.2040308@piuha.net> Organization: INRIA X-Mailer: Sylpheed version 2.2.3 (GTK+ 2.10.6; powerpc-apple-darwin8.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 467A9CBC.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: christian.vogt@nomadiclab.com, alexandru.petrescu@gmail.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 Please replace (Mobile IPv6 and )"NEMO networks" with (Mobile IPv6 and) "NEMO Basic Support protocols". BTW, can't we set up a new mailing list quickly enough and move all the discussion to that ML instead of splitting that discussion across MIP6/NEMO/MonAmi6 ? Thierry. On Thu, 21 Jun 2007 14:27:59 +0300 Jari Arkko wrote: >Christian, > >> shouldn't this be modified to something like the following sentence to >> avoid conflicts with Shim6? >> >> The group will not >> consider general multi-homing problems that are not related to >> >> the deployment and maintenance of Mobile IPv6 or NEMO networks. >> The group will also not consider general route optimization, or >> other problems that are not related to the deployment and >> maintenance of NEMO networks. >> > >Yes, that's better. Thanks. > >Jari > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > -- Thierry ERNST, PhD INRIA Rocquencourt France Project-Team IMARA / JRU LARA http://www.lara.prd.fr +33 1 39 63 59 30 (office) _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 21 12:01: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 1I1P6R-00076y-PE; Thu, 21 Jun 2007 12:01:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1P6P-00076X-1E for mip6@ietf.org; Thu, 21 Jun 2007 12:01:46 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1P6I-0004A4-O2 for mip6@ietf.org; Thu, 21 Jun 2007 12:01:45 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B2CF21986A7; Thu, 21 Jun 2007 19:01:37 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5E62F19868B; Thu, 21 Jun 2007 19:01:37 +0300 (EEST) Message-ID: <467AA0E1.60003@piuha.net> Date: Thu, 21 Jun 2007 19:01:37 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [Mip6] Merged WG charter References: <5vrfma$1hlcng@smtp06.syd.iprimus.net.au> <4677F7D8.9080104@piuha.net> <46782CE1.2020605@nomadiclab.com> <467A60BF.2040308@piuha.net> <20070621173719.67d17e7f.thierry.ernst@inria.fr> In-Reply-To: <20070621173719.67d17e7f.thierry.ernst@inria.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: christian.vogt@nomadiclab.com, alexandru.petrescu@gmail.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 Makes sense, thanks. I will take care of these. Jari Thierry Ernst kirjoitti: > Please replace (Mobile IPv6 and )"NEMO networks" with (Mobile IPv6 and) > "NEMO Basic Support protocols". > > BTW, can't we set up a new mailing list quickly enough and move all the > discussion to that ML instead of splitting that discussion across > MIP6/NEMO/MonAmi6 ? > > Thierry. > > > On Thu, 21 Jun 2007 14:27:59 +0300 > Jari Arkko wrote: > > >> Christian, >> >> >>> shouldn't this be modified to something like the following sentence to >>> avoid conflicts with Shim6? >>> >>> The group will not >>> consider general multi-homing problems that are not related to >>> >>> the deployment and maintenance of Mobile IPv6 or NEMO networks. >>> The group will also not consider general route optimization, or >>> other problems that are not related to the deployment and >>> maintenance of NEMO networks. >>> >>> >> Yes, that's better. Thanks. >> >> Jari >> >> >> _______________________________________________ >> 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 Jun 21 14:18: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 1I1REz-0008Hz-Sr; Thu, 21 Jun 2007 14:18:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1REy-0008Hu-Ve for mip6@ietf.org; Thu, 21 Jun 2007 14:18:45 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1REx-0008IW-ML for mip6@ietf.org; Thu, 21 Jun 2007 14:18:44 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 11:18:42 -0700 Message-ID: <467AC102.5090805@azairenet.com> Date: Thu, 21 Jun 2007 11:18:42 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Basavaraj Patil References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2007 18:18:42.0825 (UTC) FILETIME=[99640F90:01C7B430] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Gopal Dommety , Mobile IPv6 Mailing List Subject: [Mip6] Re: 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 Raj, Basavaraj Patil wrote: > This is a working group last call for the following two working group > documents: > > 1. Mobile IPv6 Experimental Messages > > > Status intended: Experimental Shouldn't the first document also be Standards Track? It sets aside mobility header messages type and options. Its true that these values are for experimental purposes, but the document itself shouldn't be experimental. Vijay > > 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 Thu Jun 21 15:10: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 1I1S3R-0003x1-SJ; Thu, 21 Jun 2007 15:10:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1S3P-0003ws-Fa for mip6@ietf.org; Thu, 21 Jun 2007 15:10:51 -0400 Received: from [2001:200:180:299:202:b3ff:fe88:5b64] (helo=yui.nc.u-tokyo.ac.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1S3K-0004hj-Uq for mip6@ietf.org; Thu, 21 Jun 2007 15:10:51 -0400 Received: from [203.178.143.253] (dhcp-143-253.sfc.wide.ad.jp [203.178.143.253]) (authenticated bits=0) by yui.nc.u-tokyo.ac.jp (8.12.10/8.12.3/Debian-6.4) with ESMTP id l5LJAQrr028806; Fri, 22 Jun 2007 04:10:29 +0900 In-Reply-To: <20070620131614.GB21253@grc.nasa.gov> References: <20070620131614.GB21253@grc.nasa.gov> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0BF05E30-B2C7-4143-9753-8D5A6A0AB4F7@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Date: Fri, 22 Jun 2007 04:10:23 +0900 To: Wesley Eddy X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: MIP@multicasttech.com, Mobile Mailing List IPv6 Subject: [Mip6] Re: mip6-hareliability-01 review 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 Wesley, On 2007/06/20, at 22:16, Wesley Eddy wrote: > I've read draft-ietf-mip6-hareliability-01 and have a few minor > comments. > I'm not subscribed to mip6, but feel free to forward these there. First of all, thanks for your detailed comments. > In general, I think the approach is good and will work well. Both the > local and geographically distributed modes might be simultaneously > useful in supporting aeronautical mobile networking. > I wonder what the implications for this work are if the IFARE work > stalls, though? Some modes it's intended to work in may be > unaffected, > but others won't be supportable. If IFARE gets solution ready, we can update this HAreliability accordingly. However, it is just too early to include IFARE work in this document. We can revise the HA reliability as hareliability-bis later. > On page 11, "This geographic redundancy is not a requirement by any > SDO", is probably too strong. There are a lot of SDOs, and some are > still waiting to define architectures based on Mobile IP. When > they do, > they may require geographic redundancy for safety-critical uses. I > would suggest simply rewording to "This geographic redundancy is not > required by most SDOs". > On pages 27-28, talking about sending Hello messages, I believe there > should be some discussion on picking initial sequence numbers, > wrapping, > etc., which should be pretty simple. > In 7.7.1, I don't think it's quite enough to say "It MUST set a random > value in the Identifier field". This should, more strongly, be "It > MUST set a random value in the Identifier field that does not coincide > with any other currently pending Requests." Agree on all the comments above. We will fix these. > At the end of section 9, I think something on replay protection > windows > is needed. There are a few "clever" things you can do with deltas or > derivatives to limit the amount of messaging required. Can you elaborate "something" a little further. > Spelling/Grammar Nits: > > page 8: "only tje active" -> "only the active" > > page 25: "because it's lifetime" -> "because its lifetime" > > page 25: "< xref" -> " > page 28: "sending own Hello" -> "sending its own Hello" > > page 28: "with the own Group ID" -> "with its own Group ID" Thanks for your review, again. We will submit -02 document before this IETF. regards, ryuji > > -- > Wesley M. Eddy > Verizon Federal Network Systems > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 22 00:50: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 1I1b6G-0004WW-4a; Fri, 22 Jun 2007 00:50:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1b6E-0004WO-Pr for mip6@ietf.org; Fri, 22 Jun 2007 00:50:22 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1b6D-00041r-H7 for mip6@ietf.org; Fri, 22 Jun 2007 00:50:22 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E49631986A7; Fri, 22 Jun 2007 07:50:20 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8DD741986A6; Fri, 22 Jun 2007 07:50:20 +0300 (EEST) Message-ID: <467B550C.8010709@piuha.net> Date: Fri, 22 Jun 2007 07:50:20 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Vijay Devarapalli References: <467AC102.5090805@azairenet.com> In-Reply-To: <467AC102.5090805@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Gopal Dommety , Mobile IPv6 Mailing List Subject: [Mip6] Re: 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 Vijay, > Shouldn't the first document also be Standards Track? It sets aside > mobility header messages type and options. Its true that these values > are for experimental purposes, but the document itself shouldn't be > experimental. Technically, it does not HAVE to be, because RFC 3775 allows code point allocation (what you do here) either with Standards Action or by IESG Approval. However, I think Proposed Standard makes more sense here, and it is also what the both the document itself and your charter says -- so lets go with that. A quick comment on -experimental-messages: Why does the document need to define the format? If you compare to other similar allocations, say RFC 4727, they simply allocate the number and reference the generic definition of the object as the only guideline. Here you are saying something about the first two bytes of the message, for instance. Is there a reason for that? Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 22 00:56: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 1I1bCS-0006lx-TZ; Fri, 22 Jun 2007 00:56:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1bCR-0006lp-9F for mip6@ietf.org; Fri, 22 Jun 2007 00:56:47 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1bCP-0004ii-V3 for mip6@ietf.org; Fri, 22 Jun 2007 00:56:47 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 21:56:45 -0700 Message-ID: <467B568C.9050409@azairenet.com> Date: Thu, 21 Jun 2007 21:56:44 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Jari Arkko References: <467AC102.5090805@azairenet.com> <467B550C.8010709@piuha.net> In-Reply-To: <467B550C.8010709@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2007 04:56:45.0383 (UTC) FILETIME=[BB92D570:01C7B489] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Gopal Dommety , Mobile IPv6 Mailing List Subject: [Mip6] Re: 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 Jari Arkko wrote: > Vijay, > >> Shouldn't the first document also be Standards Track? It sets aside >> mobility header messages type and options. Its true that these values >> are for experimental purposes, but the document itself shouldn't be >> experimental. > > Technically, it does not HAVE to be, because RFC 3775 allows > code point allocation (what you do here) either with Standards > Action or by IESG Approval. However, I think Proposed Standard > makes more sense here, and it is also what the both the > document itself and your charter says -- so lets go with that. Ok. > A quick comment on -experimental-messages: Why does > the document need to define the format? If you compare > to other similar allocations, say RFC 4727, they simply > allocate the number and reference the generic definition > of the object as the only guideline. Here you are saying > something about the first two bytes of the message, > for instance. Is there a reason for that? Just following RFC 3775 and RFC 3963. We show the format for any mobility header message that we define. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 22 01:01: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 1I1bHE-0004n7-JR; Fri, 22 Jun 2007 01:01:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1bHD-0004n2-J4 for mip6@ietf.org; Fri, 22 Jun 2007 01:01:43 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1bHC-0006GG-6T for mip6@ietf.org; Fri, 22 Jun 2007 01:01:43 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9006A1986A7; Fri, 22 Jun 2007 08:01:41 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2260A1986A6; Fri, 22 Jun 2007 08:01:41 +0300 (EEST) Message-ID: <467B57B5.5030301@piuha.net> Date: Fri, 22 Jun 2007 08:01:41 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Vijay Devarapalli References: <467AC102.5090805@azairenet.com> <467B550C.8010709@piuha.net> <467B568C.9050409@azairenet.com> In-Reply-To: <467B568C.9050409@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Gopal Dommety , Mobile IPv6 Mailing List Subject: [Mip6] Re: 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 Vijay, >> A quick comment on -experimental-messages: Why does >> the document need to define the format? If you compare >> to other similar allocations, say RFC 4727, they simply >> allocate the number and reference the generic definition >> of the object as the only guideline. Here you are saying >> something about the first two bytes of the message, >> for instance. Is there a reason for that? > > Just following RFC 3775 and RFC 3963. We show the format for > any mobility header message that we define. Hmm. But you don't actually define them, you just allocate them and then leave it to the particular experiment to use it in whatever way and format you like. I would understand this if it was a question of something that needs a common new header -- like vendor specific attributes in some protocols start with a vendor id and vendor's own number for the attribute. It makes sense to standardize that, so that code can understand at least which vendor the stuff comes from. I'm not sure we have a similar reason here. (I don't see harm in defining what you have done, just asking why you are doing it.) Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 22 02:20: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 1I1cVG-00041S-J7; Fri, 22 Jun 2007 02:20:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1cVE-00040P-Ml for mip6@ietf.org; Fri, 22 Jun 2007 02:20:16 -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 1I1cUn-0003Tu-K1 for mip6@ietf.org; Fri, 22 Jun 2007 02:19:50 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 21 Jun 2007 23:19:48 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALIGe0arR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,449,1175497200"; d="scan'208"; a="496730775:sNHT27958176" 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 l5M6Jm8w016256; Thu, 21 Jun 2007 23:19:48 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5M6JdXI028806; Fri, 22 Jun 2007 06:19:48 GMT Date: Thu, 21 Jun 2007 23:19:39 -0700 (PDT) From: Sri Gundavelli To: Jari Arkko Subject: Re: [Mip6] Re: WG LC: draft-ietf-mip6-experimental-messages-01 and draft-ietf-mip6-vsm-01 In-Reply-To: <467B57B5.5030301@piuha.net> Message-ID: References: <467AC102.5090805@azairenet.com> <467B550C.8010709@piuha.net> <467B568C.9050409@azairenet.com> <467B57B5.5030301@piuha.net> 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=1274; t=1182493189; x=1183357189; c=relaxed/simple; s=sjdkim2002; 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]=20Re=3A=20WG=20LC=3A=20draft-ietf-mip6-experim ental-messages-01=20and=0A=20draft-ietf-mip6-vsm-01 |Sender:=20; bh=JmGvPJZU2Iw3ma9HpebhOaLQ74Co+OsGG8FIMNI6KMU=; b=cR6ekpFqLWAj9RLQDgDjrVgjWlyvOcioIf2+dy8UblmZkhDkJhhk+4EoSjRNDjP4mgSJ+nNE yStXMa3RhqQi+LKbrTYnXgqe60eO1jIX9IKstfwv9JAZkVhaSoECKTMk; 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: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Gopal Dommety , 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 Fri, 22 Jun 2007, Jari Arkko wrote: > > Hmm. But you don't actually define them, you just allocate > them and then leave it to the particular experiment > to use it in whatever way and format you like. I would > understand this if it was a question of something that > needs a common new header -- like vendor specific > attributes in some protocols start with a vendor id > and vendor's own number for the attribute. It makes > sense to standardize that, so that code can understand > at least which vendor the stuff comes from. I'm not > sure we have a similar reason here. > > (I don't see harm in defining what you have done, > just asking why you are doing it.) > If what we are standardising is a reserved MHType, I think the Vendor Id is critical. If two vendors, HA and MN vendor, implement two different features under standards track, using the same reserved MHType. Now, if they connect both the systems, it will break the code and create problems. Having a vendor id and a application sub-type, will give the implementations the option to skip messages that they dont understand. This is more in the lines of 3025. So, vendors can do the experiments using their vendor id and their specific application sub-type. Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 22 02: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 1I1cdY-0001O3-1s; Fri, 22 Jun 2007 02:28:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1cdW-0001Nx-7L for mip6@ietf.org; Fri, 22 Jun 2007 02:28:50 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1cdV-0007Gy-TX for mip6@ietf.org; Fri, 22 Jun 2007 02:28:50 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 23:28:49 -0700 Message-ID: <467B6C20.4060306@azairenet.com> Date: Thu, 21 Jun 2007 23:28:48 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [Mip6] Re: WG LC: draft-ietf-mip6-experimental-messages-01 and draft-ietf-mip6-vsm-01 References: <467AC102.5090805@azairenet.com> <467B550C.8010709@piuha.net> <467B568C.9050409@azairenet.com> <467B57B5.5030301@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2007 06:28:49.0338 (UTC) FILETIME=[981B79A0:01C7B496] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Gopal Dommety , 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: >> Hmm. But you don't actually define them, you just allocate >> them and then leave it to the particular experiment >> to use it in whatever way and format you like. I would >> understand this if it was a question of something that >> needs a common new header -- like vendor specific >> attributes in some protocols start with a vendor id >> and vendor's own number for the attribute. It makes >> sense to standardize that, so that code can understand >> at least which vendor the stuff comes from. I'm not >> sure we have a similar reason here. >> >> (I don't see harm in defining what you have done, >> just asking why you are doing it.) >> > > If what we are standardising is a reserved MHType, I > think the Vendor Id is critical. If two vendors, HA and > MN vendor, implement two different features under > standards track, using the same reserved MHType. Now, > if they connect both the systems, it will break the > code and create problems. > > Having a vendor id and a application sub-type, will give > the implementations the option to skip messages that they > dont understand. This is more in the lines of 3025. So, > vendors can do the experiments using their vendor id > and their specific application sub-type. The vendor specific mobility option does have a "Vendor ID" string. See http://www.ietf.org/internet-drafts/draft-ietf-mip6-vsm-01.txt Jari is talking about the experimental mobility header message and option. There is no vendor id used there. Vijay > > > Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 22 02:31: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 1I1cg3-0001nz-PB; Fri, 22 Jun 2007 02:31:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1cg2-0001nt-Ij for mip6@ietf.org; Fri, 22 Jun 2007 02:31:26 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1cg1-0007iw-A6 for mip6@ietf.org; Fri, 22 Jun 2007 02:31:26 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 25D561986A6; Fri, 22 Jun 2007 09:31:24 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D0CA5198691; Fri, 22 Jun 2007 09:31:23 +0300 (EEST) Message-ID: <467B6CBC.2080603@piuha.net> Date: Fri, 22 Jun 2007 09:31:24 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [Mip6] Re: WG LC: draft-ietf-mip6-experimental-messages-01 and draft-ietf-mip6-vsm-01 References: <467AC102.5090805@azairenet.com> <467B550C.8010709@piuha.net> <467B568C.9050409@azairenet.com> <467B57B5.5030301@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Gopal Dommety , 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, We are only defining vendor-specific options (in the -vsm draft), not vendor-specific messages. I only used the attribute example as an example of where you would have to define the contents. We do not have a vendor- specific message proposal on the table, and I don't think we should do that either, for interoperability reasons. Vendor-specific = non-standard mechanism but possibly deployed and permanent Experimental = non-standard, research-oriented mechanism, on purpose not deployed and not permanent However, the -vsm draft should comply with what you wrote. However, it only has a vendor id, not vendor's option id. I think adding the option Id too would make debugging easier. Vijay, can we add that? Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 22 02:48: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 1I1cwO-0007fy-Og; Fri, 22 Jun 2007 02:48:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1cwN-0007fn-2d for mip6@ietf.org; Fri, 22 Jun 2007 02:48:19 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1cwL-0002dw-P0 for mip6@ietf.org; Fri, 22 Jun 2007 02:48:19 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 23:48:17 -0700 Message-ID: <467B70B0.1080100@azairenet.com> Date: Thu, 21 Jun 2007 23:48:16 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Jari Arkko References: <467AC102.5090805@azairenet.com> <467B550C.8010709@piuha.net> <467B568C.9050409@azairenet.com> <467B57B5.5030301@piuha.net> In-Reply-To: <467B57B5.5030301@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2007 06:48:17.0127 (UTC) FILETIME=[5029EF70:01C7B499] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Gopal Dommety , Mobile IPv6 Mailing List Subject: [Mip6] Re: 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 Hi Jari, Jari Arkko wrote: > Vijay, > >>> A quick comment on -experimental-messages: Why does >>> the document need to define the format? If you compare >>> to other similar allocations, say RFC 4727, they simply >>> allocate the number and reference the generic definition >>> of the object as the only guideline. Here you are saying >>> something about the first two bytes of the message, >>> for instance. Is there a reason for that? >> Just following RFC 3775 and RFC 3963. We show the format for >> any mobility header message that we define. > > Hmm. But you don't actually define them, you just allocate > them and then leave it to the particular experiment > to use it in whatever way and format you like. I would > understand this if it was a question of something that > needs a common new header -- like vendor specific > attributes in some protocols start with a vendor id > and vendor's own number for the attribute. It makes > sense to standardize that, so that code can understand > at least which vendor the stuff comes from. I'm not > sure we have a similar reason here. We can take specific examples. From RFC 3775, Binding Refresh Request +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From RFC 4068, Fast Neighbor Advertisement +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > (I don't see harm in defining what you have done, > just asking why you are doing it.) The above does not mean that we have to continue doing the same. I am fine either way. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 22 02:56: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 1I1d4G-0003W0-NL; Fri, 22 Jun 2007 02:56:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1d4F-0003Vv-1p for mip6@ietf.org; Fri, 22 Jun 2007 02:56:27 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1d4D-0003XO-PG for mip6@ietf.org; Fri, 22 Jun 2007 02:56:27 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 21 Jun 2007 23:56:25 -0700 X-IronPort-AV: i="4.16,449,1175497200"; d="scan'208"; a="170037838:sNHT42911613" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5M6uP31014468; Thu, 21 Jun 2007 23:56:25 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5M6uPkb012386; Fri, 22 Jun 2007 06:56:25 GMT Date: Thu, 21 Jun 2007 23:56:24 -0700 (PDT) From: Sri Gundavelli To: Jari Arkko Subject: Re: [Mip6] Re: WG LC: draft-ietf-mip6-experimental-messages-01 and draft-ietf-mip6-vsm-01 In-Reply-To: <467B6CBC.2080603@piuha.net> Message-ID: References: <467AC102.5090805@azairenet.com> <467B550C.8010709@piuha.net> <467B568C.9050409@azairenet.com> <467B57B5.5030301@piuha.net> <467B6CBC.2080603@piuha.net> 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=1055; t=1182495385; x=1183359385; c=relaxed/simple; s=sjdkim4002; 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]=20Re=3A=20WG=20LC=3A=20draft-ietf-mip6-experim ental-messages-01=20and=0A=20draft-ietf-mip6-vsm-01 |Sender:=20; bh=xjaGWe1ovvzFssTBCmJ8uSuFcQibkriLH//5UtZc8RM=; b=FC7n/XKC9pHgGDk0kjFPEd8aKesEUE0QYyTOpg32+iYyjTQWm37C1+jocQC8Y74lBsEdzy1N 21qyOseH+N19KxEp+T5h3RNJd6YRwuToJDyLl3YHBQq6iRBXjN3pVdxY; 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Gopal Dommety , 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 Jari, Ok. If implementations are not allowed to release/deploy features that use experimental message/options. It should be fine. I see the text in the Introduction. Thanks for the clarification. Sri On Fri, 22 Jun 2007, Jari Arkko wrote: > Sri, > > We are only defining vendor-specific options (in the -vsm > draft), not vendor-specific messages. I only used the > attribute example as an example of where you would > have to define the contents. We do not have a vendor- > specific message proposal on the table, and I don't > think we should do that either, for interoperability > reasons. > > Vendor-specific = non-standard mechanism but > possibly deployed and permanent > > Experimental = non-standard, research-oriented > mechanism, on purpose not deployed and not > permanent > > However, the -vsm draft should comply with what > you wrote. However, it only has a vendor id, not > vendor's option id. I think adding the option Id > too would make debugging easier. Vijay, can > we add that? > > Jari > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 22 03:28: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 1I1dW7-00029j-5L; Fri, 22 Jun 2007 03:25:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1dW5-000296-Uf for mip6@ietf.org; Fri, 22 Jun 2007 03:25:13 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1dVq-0000WI-9d for mip6@ietf.org; Fri, 22 Jun 2007 03:24:59 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D5BB71986A6; Fri, 22 Jun 2007 10:24:26 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 847CA19868B; Fri, 22 Jun 2007 10:24:26 +0300 (EEST) Message-ID: <467B792A.2040202@piuha.net> Date: Fri, 22 Jun 2007 10:24:26 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Vijay Devarapalli References: <467AC102.5090805@azairenet.com> <467B550C.8010709@piuha.net> <467B568C.9050409@azairenet.com> <467B57B5.5030301@piuha.net> <467B70B0.1080100@azairenet.com> In-Reply-To: <467B70B0.1080100@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Gopal Dommety , Mobile IPv6 Mailing List Subject: [Mip6] Re: 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 Vijay, > We can take specific examples. > > From RFC 3775, Binding Refresh Request Right. But there's a difference between a message for a given purpose and a message reserved for any purpose. In the former case you need specific fields, because you have a specific task in hand. In the latter case... you don't. You could define some generic fields, like what we discussed in the VSA case, but even those fields do not appear to be relevant for an experimental message. >> (I don't see harm in defining what you have done, >> just asking why you are doing it.) > > The above does not mean that we have to continue doing the same. > I am fine either way. Right. I do not think this is a problem either way, either. I have expressed my opinion which is that we do not need the contents definition. (FYI: That is something that I'm saying only as an individual; if the WG has consensus to bring the definitions anyway I wouldn't block it in AD review.) Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 22 05:02: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 1I1f2N-0003jE-Gn; Fri, 22 Jun 2007 05:02:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1f2L-0003dx-Qi; Fri, 22 Jun 2007 05:02:37 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1f2F-0005hj-Ov; Fri, 22 Jun 2007 05:02:37 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7838B1986A6; Fri, 22 Jun 2007 12:02:30 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 260EA198691; Fri, 22 Jun 2007 12:02:30 +0300 (EEST) Message-ID: <467B9026.7080600@piuha.net> Date: Fri, 22 Jun 2007 12:02:30 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] issue 93 summary References: <20070607070308.UIFP5648.oaamta07ps.mx.bigpond.com@PC20005> In-Reply-To: <20070607070308.UIFP5648.oaamta07ps.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Hesham, > => No that's not true at all. There is an IP version field in the IP header > that tells you what the header is. The fact that the IP header fields (for > v4 or v6) are not revisited in this draft does not in any shape or form > suggest that we have no way of parsing header. I suggest that we get off the > header parsing argument because frankly, it's a waste of time. Everyone > knows (including people who want option 3) that you can do this with the > version field. Let's not debate facts here, it's pointless. > He's not saying its impossible, he's saying it needs to be documented. I agree with that requirement. You need to change the draft no matter what (but of course adding this description is trivial). Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 22 05:03: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 1I1f36-0004Ur-Vh; Fri, 22 Jun 2007 05:03:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1f35-0004TT-I3; Fri, 22 Jun 2007 05:03:23 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1f34-00063i-3S; Fri, 22 Jun 2007 05:03:23 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7CF901986A6; Fri, 22 Jun 2007 12:03:21 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2369C198691; Fri, 22 Jun 2007 12:03:21 +0300 (EEST) Message-ID: <467B9059.5090508@piuha.net> Date: Fri, 22 Jun 2007 12:03:21 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus calltoclose issue 93 References: <20070607005358.PNHE23012.oaamta07sl.mx.bigpond.com@PC20005> <35912544FC930E49BF20EF16C3EF2765024ACE7B@xmb-hkg-416.apac.cisco.com> <004f01c7a8bb$28b99470$1220fea9@amer.cisco.com> In-Reply-To: <004f01c7a8bb$28b99470$1220fea9@amer.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Henrik Levkowetz' 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, > 4. Tunnel Keep Alive message > > When DSMIP chose IPv4 UDP transport for NAT traversal, > the need for keepalive messaging between the tunnel > peers for keeping the NAT bindings came up. The authors > of the draft chose to use MIP6 signaling messages BU/BA > as a way to refresh the keepalive messages. IMO, having > a simple keepalive messages is lot more useful than an > expensive BU/BA. Most 3519 implementation today optimize > on this, by eliminating the keepalives when there is > traffic. We cant do such optimizations with BU/BA. > I don't see why not. First of all, you can always skip a keepalive when there is other traffic. Secondly, you can skip the entire contents and send an empty container. Etc. > 6. Why do we need GRE Header ? > > We need GRE tunnel header for various reasons, when ever we > carry multiple streams within a tunnel, the GRE header for its > mature header semantics, the key field and the sequence number > field is useful. > Hmm. Reading on... > We have some NEMO 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. > > Use cases: > > a.) Overlapping private IPv4 addressing support on the MAGs > (PMIP6 Usage) > >From your list, this sounds like the most valid reason. But are there other ways to deal with this? Can you expand on the requirement and describe why there are no other ways to deal with it? > c.) Carrying other protocol packets (Lets say, IPX packets) > in a MIP tunnel. > This is not a very convincing use case. We can always encapsulate L2TP etc. inside if we really want to. > e.) Industry direction and related work, these are the active > drafts: > Mumble. It is very clear that the Internet has many, many tunneling schemes from here to eternity. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 22 05:19: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 1I1fIG-0008J9-NR; Fri, 22 Jun 2007 05:19:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fIE-0008Au-TH; Fri, 22 Jun 2007 05:19:02 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1fIC-0001d4-IQ; Fri, 22 Jun 2007 05:19:01 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id EA8DE198691; Fri, 22 Jun 2007 12:18:59 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8F23B19868B; Fri, 22 Jun 2007 12:18:59 +0300 (EEST) Message-ID: <467B9404.20709@piuha.net> Date: Fri, 22 Jun 2007 12:19:00 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Karen E. Nielsen (AH/LMD)" Subject: Re: [nemo] RE: [Mip6] issue 93 summary References: <20070608015911.CHWN6690.oaamta06ps.mx.bigpond.com@PC20005> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: nemo@ietf.org, Alexandru Petrescu , Sri Gundavelli , mip6@ietf.org, 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 Karen, Vijay, >> Well, we kind of have tighter integration between MIPv6 and >> IPsec already. For e.g, the insertation of home address >> option and routing header is done by MIPv6 after IPsec >> processing is done. >> The use of 'K' bit (to update the tunnel end point) also >> requires this. I am not suggesting we continue doing this, >> but adding TLV shouldn't be a big issue. :) >> >> Vijay >> >> > > Yes, :-). I do not want to be twisting straws here about the pros and > cons. I > am simply trying to understand the differences. > > However, (now you may see this as twisting straws, but the angle is > different), > the extraction and insertion of RH/DO is a mobility thing and there is a > very good reason > IPSec shouldn't know about those as we exactly want the movement to be > transparent to > IPSec SAs anchored on the MN's home address. > > The TLV header is not a mobility thing, per se, as I understand it. > So the insertion and extraction outside IPSec seems more like a hack to > allow this > new encapsulation header type IP-UDP-TLV to use IPSec UDP ESP > encapsulation. > For what it is worth, I would like to see as little changes in IPsec processing with Mobile IPv6 as possible. (But as Vijay points out in a later e-mail, the TLV is only used for Mobile IPv6 / DSMIP, and when IPsec encapsulation is not used. So maybe this is not creating additional changes. But as a principle, I want to be very careful about any new interactions.) Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 22 05:19: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 1I1fIL-0000Be-Jc; Fri, 22 Jun 2007 05:19:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fIK-0008Vg-6Y; Fri, 22 Jun 2007 05:19:08 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1fII-0001dF-Qb; Fri, 22 Jun 2007 05:19:08 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3C78E1986A7; Fri, 22 Jun 2007 12:19:06 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D3C6B19868B; Fri, 22 Jun 2007 12:19:05 +0300 (EEST) Message-ID: <467B940A.5020104@piuha.net> Date: Fri, 22 Jun 2007 12:19:06 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] issue 93 summary References: <20070608002659.ZHXH20226.oaamta04ps.mx.bigpond.com@PC20005> In-Reply-To: <20070608002659.ZHXH20226.oaamta04ps.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: nemo@ietf.org, mip6@ietf.org, 'Alexandru Petrescu' , '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 Hesham, > => Nope. We have requirements from MIP6 and NEMO. Of course it's nice if we > can help any other work (including PMIP) if we can, but I think it's wrong > to do that at the cost of making the base spec worse for its primary users. I do not think we should treat the users of this technology differently depending on what they are doing. I do think we need to listen to the PMIP folks, too. (But its a separate question whether the PMIP use case truly implies need for the TLV, and even if it does, whether it should be done as a part of the initial DSMIP application or as an extension. However, in practice we know that the NETLMM schedule is quite tight, so I would at least like to entertain the idea that if they truly need something then it should be in the base DSMIP document. I've also told NETLMM that their current charter does not allow work for IPv4, except when then they can directly reference an existing spec. This may change -- I want to recharter them, but that's another consideration to take into account.) Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 22 05:19: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 1I1fIV-0000pD-4I; Fri, 22 Jun 2007 05:19:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fIT-0000jR-8V; Fri, 22 Jun 2007 05:19:17 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1fIR-0001e3-Vu; Fri, 22 Jun 2007 05:19:17 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 65231198691; Fri, 22 Jun 2007 12:19:15 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 045A519868B; Fri, 22 Jun 2007 12:19:14 +0300 (EEST) Message-ID: <467B9413.5080105@piuha.net> Date: Fri, 22 Jun 2007 12:19:15 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [nemo] RE: [Mip6] issue 93 summary References: <003901c7a918$05c84a30$1220fea9@amer.cisco.com> <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005> <004001c7a91b$fc2d0b10$1220fea9@amer.cisco.com> In-Reply-To: <004001c7a91b$fc2d0b10$1220fea9@amer.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: nemo@ietf.org, 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 Sri, > >From what I interpret from 3948, the mechanism of UDP transport > can be used when the outer header and the contained header are > both either IPv4 or IPv6. It did not state that the IPSec process > has to look in the version field and do the demux to ip_input or > ipv6_input. So, it did not talk about a scenario where the payload > is IPv6 and the transport is IPv4. If we can get this clarified > from the IPSec guys, that will be good. If 3948 can support IPv4, > IPv6 payloads in an IPv4-UDP-ESP, then the issue exists is not > applicable to option #1. > My interpretation of RFC 3948 is that it does not in any way change the ESP processin rules. That is, a tunnel mode packet contains an IP packet. IPsec can deal with both IPv4 and IPv6 packets in the inner packet. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 22 05:19: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 1I1fIi-0001XZ-Pr; Fri, 22 Jun 2007 05:19:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fIh-0001XL-D9; Fri, 22 Jun 2007 05:19:31 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1fIg-0001fO-4S; Fri, 22 Jun 2007 05:19:31 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 89521198691; Fri, 22 Jun 2007 12:19:29 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2730519868B; Fri, 22 Jun 2007 12:19:29 +0300 (EEST) Message-ID: <467B9421.20905@piuha.net> Date: Fri, 22 Jun 2007 12:19:29 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [Mip6] issue 93 summary References: <001f01c7a93d$51e882c0$1220fea9@amer.cisco.com> <20070608002659.ZHXH20226.oaamta04ps.mx.bigpond.com@PC20005> <000601c7a96b$b46ebee0$1220fea9@amer.cisco.com> In-Reply-To: <000601c7a96b$b46ebee0$1220fea9@amer.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: nemo@ietf.org, 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 Sri, > As Yoshi pointed out, if some one wants to tunnel legacy IPX > or other traffic from the MN to home network, GRE is required. > Same thing for routing legacy protocol traffic from a network > behind mobile router to the home network. We already talked > about the NETLMM requirement. I do not think this 4-byte header > will make the "base spec worse", it really addresses all these > usecases. As far as I am aware, we are not chartered in any of the related WGs to produce a legacy protocol mobility solution. Lets leave that part of the kitchen sink to other protocols :-) Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 22 05:38: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 1I1faf-00067L-Jh; Fri, 22 Jun 2007 05:38:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1faf-00067E-0d for mip6@ietf.org; Fri, 22 Jun 2007 05:38:05 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1fad-00053C-Jm for mip6@ietf.org; Fri, 22 Jun 2007 05:38:04 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 60F0A198691; Fri, 22 Jun 2007 12:38:01 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1998919868B; Fri, 22 Jun 2007 12:38:01 +0300 (EEST) Message-ID: <467B9879.2020107@piuha.net> Date: Fri, 22 Jun 2007 12:38:01 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Mobile IPv6 Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: mip6-chairs@tools.ietf.org, Sri Gundavelli Subject: [Mip6] Issue 93 situation 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, The chairs asked me to help with assessing the consensus and way forward with regards to this issue. After review the discussion during the last two weeks, I can see some useful discussion and new technical aspects have been brought in. Thanks! However, it is apparent that the situation with regards to consensus has not changed, i.e., there is no consensus, nor have we heard from too many new people on this. And I have not seen anyone change their opinion, which is not a good sign :-( At this point I would like to ask Hesham to submit the draft if you have other changes since the previous submission, and we need to continue discussing issue 93 in a new way. I would like to note that getting the DSMIP spec out is very important, and that this discussion is threatening the completion of the work. I would suggest we do two things. First, I would like get some of the main persons in this argument in a conference call (the chairs and me will send mail to some of you about this), in an effort to see if we can agree on a compromise. As one of the preparations for that I would like to ask Sri to send a detailed description to the list about why NETLMM needs encapsulations that are capable of differentiating between flows or address spaces. Secondly, I would like to get some additional information about what people believe about this issue. Please respond to this query by Thursday, June 28th. We've heard from people's preferred solutions. I'd like to hear about their willingness to accept different solutions, even if they are not preferred: A) Be willing to accept solution 1, with the option of having solution 2-like extension later. B) Be willing to accept solution 3. Here "be willing to accept" should be interpreted as in not seeing a major technical fault or something that prevents your implementation or business from functioning properly. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 22 05:59: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 1I1fvU-0000bE-6Z; Fri, 22 Jun 2007 05:59:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fvT-0000ZT-2Q for mip6@ietf.org; Fri, 22 Jun 2007 05:59:35 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I1fvR-0002oU-NZ for mip6@ietf.org; Fri, 22 Jun 2007 05:59:35 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1182506372!6936812!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.10] Received: (qmail 11639 invoked from network); 22 Jun 2007 09:59:32 -0000 Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-10.tower-128.messagelabs.com with SMTP; 22 Jun 2007 09:59:32 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id l5M9tlTi017920 for ; Fri, 22 Jun 2007 02:55:47 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l5M9tk0R022453 for ; Fri, 22 Jun 2007 04:55:46 -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 l5M9tipq022427 for ; Fri, 22 Jun 2007 04:55:45 -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, 22 Jun 2007 10:55:41 +0100 Message-ID: <467B9C99.4020408@gmail.com> Date: Fri, 22 Jun 2007 11:55:37 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Re: WG LC: draft-ietf-mip6-experimental-messages-01 and draft-ietf-mip6-vsm-01 References: <467AC102.5090805@azairenet.com> In-Reply-To: <467AC102.5090805@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000751-2, 21/06/2007), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 22 Jun 2007 09:55:41.0947 (UTC) FILETIME=[7E994CB0:01C7B4B3] X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Gopal Dommety , 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 Vijay Devarapalli wrote: > Raj, > > Basavaraj Patil wrote: >> This is a working group last call for the following two working group >> documents: >> 1. Mobile IPv6 Experimental Messages >> >> >> Status intended: Experimental > > Shouldn't the first document also be Standards Track? It sets aside > mobility header messages type and options. Its true that these values > are for experimental purposes, but the document itself shouldn't be > experimental. I think as long as these options are reserved by IANA the document could be experimental/informational/stdtrack/bcp whatever. Alex > > Vijay > > >> >> 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 > ______________________________________________________________________ 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 Jun 22 10:15: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 1I1jua-0005kU-N1; Fri, 22 Jun 2007 10:14:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1juZ-0005kM-Fx; Fri, 22 Jun 2007 10:14:55 -0400 Received: from omta02ps.mx.bigpond.com ([144.140.83.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1juY-0001Kz-1i; Fri, 22 Jun 2007 10:14:55 -0400 Received: from oaamta02ps.mx.bigpond.com ([124.190.105.118]) by omta02ps.mx.bigpond.com with ESMTP id <20070622141451.FBBO7838.omta02ps.mx.bigpond.com@oaamta02ps.mx.bigpond.com>; Fri, 22 Jun 2007 14:14:51 +0000 Received: from PC20005 ([124.190.105.118]) by oaamta02ps.mx.bigpond.com with ESMTP id <20070622141451.ELHE27015.oaamta02ps.mx.bigpond.com@PC20005>; Fri, 22 Jun 2007 14:14:51 +0000 From: "Hesham Soliman" To: "'Jari Arkko'" Subject: RE: [Mip6] issue 93 summary Date: Sat, 23 Jun 2007 00:14:44 +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: Ace0rBYCaH3ogJBAQrWT/JIjmJyElAAK1zfg In-Reply-To: <467B9026.7080600@piuha.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Message-Id: <20070622141451.ELHE27015.oaamta02ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 > > => No that's not true at all. There is an IP version field > in the IP header > > that tells you what the header is. The fact that the IP > header fields (for > > v4 or v6) are not revisited in this draft does not in any > shape or form > > suggest that we have no way of parsing header. I suggest > that we get off the > > header parsing argument because frankly, it's a waste of > time. Everyone > > knows (including people who want option 3) that you can do > this with the > > version field. Let's not debate facts here, it's pointless. > > > He's not saying its impossible, he's saying it needs to be > documented. I agree with that requirement. You need > to change the draft no matter what (but of course > adding this description is trivial). => Agreed. Ahmad said in a later email that it is more of an editorial comment than a technical one. Depending on how we resolve this issue I'll add this comment among several others that he sent. Hesham > > Jari > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 22 10:20:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1jzb-00018G-HX; Fri, 22 Jun 2007 10:20:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1jzZ-000188-Px; Fri, 22 Jun 2007 10:20:05 -0400 Received: from omta05ps.mx.bigpond.com ([144.140.83.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1jzY-000376-Bq; Fri, 22 Jun 2007 10:20:05 -0400 Received: from oaamta05ps.mx.bigpond.com ([124.190.105.118]) by omta05ps.mx.bigpond.com with ESMTP id <20070622142001.YLOZ23363.omta05ps.mx.bigpond.com@oaamta05ps.mx.bigpond.com>; Fri, 22 Jun 2007 14:20:01 +0000 Received: from PC20005 ([124.190.105.118]) by oaamta05ps.mx.bigpond.com with ESMTP id <20070622142000.RFQZ4317.oaamta05ps.mx.bigpond.com@PC20005>; Fri, 22 Jun 2007 14:20:00 +0000 From: "Hesham Soliman" To: "'Jari Arkko'" Subject: RE: [Mip6] issue 93 summary Date: Sat, 23 Jun 2007 00:19: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: Ace0r1KDDj3Z1vubTSyysjYZuC3IvgAKJQlw In-Reply-To: <467B940A.5020104@piuha.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Message-Id: <20070622142000.RFQZ4317.oaamta05ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nemo@ietf.org, mip6@ietf.org, 'Alexandru Petrescu' , '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 > > => Nope. We have requirements from MIP6 and NEMO. Of > course it's nice if we > > can help any other work (including PMIP) if we can, but I > think it's wrong > > to do that at the cost of making the base spec worse for > its primary users. > > I do not think we should treat the users of this technology > differently depending on what they are doing. I do think > we need to listen to the PMIP folks, too. > > (But its a separate question whether the PMIP use case > truly implies need for the TLV, and even if it does, whether > it should be done as a part of the initial DSMIP application > or as an extension. However, in practice we know that the > NETLMM schedule is quite tight, so I would at least like > to entertain the idea that if they truly need something > then it should be in the base DSMIP document. I've also > told NETLMM that their current charter does not allow > work for IPv4, except when then they can directly reference > an existing spec. This may change -- I want to recharter > them, but that's another consideration to take into > account.) => Again, I completely agree. The main problem here is that we haven't seen this discussion in NETLMM, so I don't know that we're getting a *representative* view of NETLMM requirements in this discussion. I think the main point of my statement above relates to your question of whether this should be in the base or not. Of course that is after understanding whether there is a need for this. Hesham > > Jari > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 22 11:24: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 1I1l0E-0000NJ-0c; Fri, 22 Jun 2007 11:24:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1l0C-0000Md-FP; Fri, 22 Jun 2007 11:24:48 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1l0B-0000lM-6g; Fri, 22 Jun 2007 11:24:48 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 08:24:46 -0700 Message-ID: <467BE9BA.9020702@azairenet.com> Date: Fri, 22 Jun 2007 08:24:42 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [nemo] Re: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus calltoclose issue 93 References: <20070607005358.PNHE23012.oaamta07sl.mx.bigpond.com@PC20005><35912544FC930E49BF20EF16C3EF2765024ACE7B@xmb-hkg-416.apac.cisco.com><004f01c7a8bb$28b99470$1220fea9@amer.cisco.com> <467B9059.5090508@piuha.net> In-Reply-To: <467B9059.5090508@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2007 15:24:46.0474 (UTC) FILETIME=[774106A0:01C7B4E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: nemo@ietf.org, Mobile IPv6 Mailing List , Henrik Levkowetz , 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 Jari Arkko wrote: > > We have some NEMO 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. > > > > Use cases: > > > > a.) Overlapping private IPv4 addressing support on the MAGs > > (PMIP6 Usage) > > > > >From your list, this sounds like the most valid reason. But are > there other ways to deal with this? Can you expand on the > requirement and describe why there are no other ways to > deal with it? IMO, GRE is the cleanest. I had looked at other options, it is doable, but ugly. Anyone else knows more on this? Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 22 11:45: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 1I1lK9-0001pP-NM; Fri, 22 Jun 2007 11:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1lK8-0001pJ-5F for mip6@ietf.org; Fri, 22 Jun 2007 11:45:24 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I1lK6-0007Je-Tb for mip6@ietf.org; Fri, 22 Jun 2007 11:45:24 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1182527121!18372928!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 14347 invoked from network); 22 Jun 2007 15:45:21 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-8.tower-119.messagelabs.com with SMTP; 22 Jun 2007 15:45:21 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l5MFjK8B024152 for ; Fri, 22 Jun 2007 08:45:20 -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 l5MFjJf1013397 for ; Fri, 22 Jun 2007 10:45:19 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.1.41]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l5MFjHsu013385 for ; Fri, 22 Jun 2007 10:45:18 -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, 22 Jun 2007 16:45:16 +0100 Message-ID: <467BEE8B.6060700@gmail.com> Date: Fri, 22 Jun 2007 17:45:15 +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] Summary and conclusion of: DS-MIP6 - Consensus calltoclose issue 93 References: <20070607005358.PNHE23012.oaamta07sl.mx.bigpond.com@PC20005><35912544FC930E49BF20EF16C3EF2765024ACE7B@xmb-hkg-416.apac.cisco.com><004f01c7a8bb$28b99470$1220fea9@amer.cisco.com> <467B9059.5090508@piuha.net> <467BE9BA.9020702@azairenet.com> In-Reply-To: <467BE9BA.9020702@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000751-2, 21/06/2007), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 22 Jun 2007 15:45:16.0868 (UTC) FILETIME=[54A04040:01C7B4E4] X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Mobile IPv6 Mailing List , Henrik Levkowetz , 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 Vijay Devarapalli wrote: > Jari Arkko wrote: > >> > We have some NEMO 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. >> > >> > Use cases: >> > >> > a.) Overlapping private IPv4 addressing support on the MAGs >> > (PMIP6 Usage) >> > >> >From your list, this sounds like the most valid reason. But are >> there other ways to deal with this? Can you expand on the >> requirement and describe why there are no other ways to >> deal with it? > > IMO, GRE is the cleanest. I had looked at other options, it is > doable, but ugly. Anyone else knows more on this? I am not sure how much of the problem of overlapping IPv4 address space for PMIPv6 could be solved by using a certain protocol - GRE or any other. I think it's more of an administrative issue where administrators could take care in planning their private space. rfc1918 defining the IPv4 private space warns about risks of uniqueness violation and advises how to avoid, here's a relevant excerpt: > If two (or more) organizations follow the address allocation > specified in this document and then later wish to establish IP > connectivity with each other, then there is a risk that address > uniqueness would be violated. To minimize the risk it is strongly > recommended that an organization using private IP addresses choose > randomly from the reserved pool of private addresses, when allocating > sub-blocks for its internal allocation. 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 Jun 23 08:08: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 1I24Q3-000857-Ln; Sat, 23 Jun 2007 08:08:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I24Q2-000852-UJ for mip6@ietf.org; Sat, 23 Jun 2007 08:08:46 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I24Q1-0007QV-8h for mip6@ietf.org; Sat, 23 Jun 2007 08:08:46 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 23 Jun 2007 14:08:43 +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] I-D ACTION:draft-korhonen-mip6-service-02.txt Date: Sat, 23 Jun 2007 14:08:42 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301F26DC4@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] I-D ACTION:draft-korhonen-mip6-service-02.txt Thread-Index: Acet2eL87cO0ExV3Q7GfQGiV/GgjtAAADBvQAB1MayA= References: From: To: X-OriginalArrivalTime: 23 Jun 2007 12:08:43.0427 (UTC) FILETIME=[3E583F30:01C7B58F] X-Spam-Score: 0.2 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 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 Ji, Thanks for comments and sorry for the delay. See my responses inline. > Hi Jouni, >=20 > Just come across this I-D... IMHO, it might be good if there=20 > are some more concrete scenarios/examples to show why this=20 > option is necessary or works better (e.g. reduce additional=20 > signaling?). Ok.. Will add some more verbal scenario descriptions. > BTW, does one Service Selection Mobility Option encode a=20 > single identifier or allow multiple as well? If an MN wants=20 A single identifier. > to change the service or the set of services the home agent=20 > is offering, would a deregistration be required before=20 > re-registration(s)? The current text indicates that Service Selection option should only be used in the initial BU as the configuring the 'service' in the HA might need setting up subsequent tunnels and routing rules to the destination network hosting the 'service' etc. However, based on the deployment I think it is possible to 'renumber' the services during the MIP6 session without a=20 need to deregister first. Cheers, Jouni > Cheers, > Ji >=20 >=20 > ----- Original Message ----- > From: > To: > Sent: Friday, June 08, 2007 6:42 AM > Subject: [Mip6] FW: I-D ACTION:draft-korhonen-mip6-service-02.txt >=20 >=20 > FYI.. The I-D on service selection for MIP6 has been > revised based on the received comments & feedback. >=20 > Cheers, > Jouni >=20 >=20 > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Thursday, June 07, 2007 10:50 PM > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-korhonen-mip6-service-02.txt > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : Service Selection for Mobile IPv6 > > Author(s) : J. Korhonen, et al. > > Filename : draft-korhonen-mip6-service-02.txt > > Pages : 9 > > Date : 2007-6-7 > > > > In some Mobile IPv6 deployments identifying the mobile node or the > > mobility service subscriber is not enough to distinguish between > > multiple services possibly provisioned to the said=20 > mobile node and > > its mobility service subscription. A capability to > > specify different > > services in addition to the mobile node identity can be > > leveraged to > > provide flexibility for mobility service providers on=20 > provisioning > > > > multiple services to one mobility service subscription. This > > document describes a Service Selection Mobility Option for both > > conventional Mobile IPv6 or Proxy Mobile IPv6 that is intended to > > assist home agents to make a specific service selection for the > > mobility service subscription during the binding update=20 > procedure. > > > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-korhonen-mip6-service-02.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-korhonen-mip6-service-02.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-korhonen-mip6-service-02.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. > > >=20 >=20 >=20 > -------------------------------------------------------------- > ---------- > -------- >=20 >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > >=20 >=20 >=20 > To report this email as spam click > https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg=3D=3D > DVRCyMKb4W2rVPx0tCfiV5ruvelr6GGHlrhkKDkjC48R5jZ8u+yuWgmclsxI18 > lIwgo2iePp > TOxHdM3SfspoO2Ssycnc+6w8cgYCSu4!ZYbjtL0Y78QDCjIsKr6JDmowvSNRHG > LgFBgW0a5o > rvq5o5c2UheNrFfQqvV2TFd3OCSGuAx0XL3InfQ . >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mext-bounces@ietf.org Mon Jun 25 08:48: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 1I2nzf-0002E1-Pr; Mon, 25 Jun 2007 08:48:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2nze-0002Dw-5f for mext@ietf.org; Mon, 25 Jun 2007 08:48:34 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2nzb-0000ay-GS for mext@ietf.org; Mon, 25 Jun 2007 08:48:34 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AB9551986A6 for ; Mon, 25 Jun 2007 15:48:30 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5E7A219868B for ; Mon, 25 Jun 2007 15:48:30 +0300 (EEST) Message-ID: <467FB99E.3000105@piuha.net> Date: Mon, 25 Jun 2007 15:48:30 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: mext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Subject: [MEXT] new charter version X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Testing the new list... this list should have all the subscribers of the existing three lists. For now, please continue your technical discussions in the existing lists, except for charter discussion which we can move here. In general, you do not need to take any action with regards to list changes, once we are ready to move complete away from the old lists we can deal with the from the secretariat. Here's a pointer to the list page: https://www1.ietf.org/mailman/listinfo/mext Here's the new charter, revised according to comments from many of you (thanks!) and the rest of the IESG. The charter will go out soon for public IETF review. ------ Mobility EXTensions for IPv6 (MEXT) Chair(s): TBD Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: https://www1.ietf.org/mailman/listinfo/mext http://www1.ietf.org/mail-archive/web/mext/current/index.html Description of Working Group: Mobile IPv6 specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions. In addition, NEMO network mobility mechanisms built on top of Mobile IPv6 allow managing the mobility of an entire network, as it changes its point of attachment to the Internet. The base specifications consist of: o RFC 3775 o RFC 3963 o RFC 4877 The MEXT Working Group continues the work of the MIP6, NEMO, and MONAMI6 Working Groups. The primary goal of MEXT will be to (A) enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios. Additionally, (B) the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. (C) The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. Deployment considerations call for (A.1) solutions to enable dual-stack operation, (A.2) allowing the use of multiple interfaces in mobile nodes, (A.3) mechanisms to support high-availability home agents, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, (A.5) address the specific needs of automotive and aviation communities for route optimisation in network mobility, and (A.6) support for AAA is needed as a continuation of earlier work on bootstrapping. Work items related to large scale deployment include: (A.1) A Solution for MIP6 session continuity for dual stack hosts which attach to IPv4 access networks. Additionally provide a mechanism for carrying IPv4 packets via the Home agent for MIP6 capable dual-stack hosts. (A.2) A protocol based solution for enhancing the reliability of home agents and a method to force a host to switch home agents. A mechanism to force an MN to switch the HA that is currently serving it. This is required in deployments where the HA needs to be taken offline for maintenance. (A.3) Use of multiple interfaces. Today, the protocols do not provide suppport for simultaneous differentiated use of multiple access technologies. Several proposals exist for such support, and some of them have been implemented and tested. When a mobile host/router uses multiple network interfaces simultaneously, or when multiple prefixes are available on a single network interface, the mobile host/router would end up with multiple Care-of Addresses (CoAs). In addition, the Home Agent might be attached to multiple network interfaces, or to a single network interface with multiple prefixes, hence resulting in the option to use multiple IP addresses for the Home Agent. This could result in the possibility of using a multitude of bi-directional tunnels between pairs of {Home Agent address, CoA} and a number of associated issues: establishment, selection and modification of multiple simultaneous tunnels. The objective of the WG is to produce a clear problem statement and to produce standard track specifications to the problems associated with the simultaneous use of multiple addresses for either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support and their variants (FMIPv6, HMIPv6, etc). Where the effects of having multiple prefixes on a single interface is identical to the effects of having multiple interfaces each with a single prefix, the WG will consider a generalized approach to cater for multiple prefixes available to a mobile host/router. The WG uses existing tunneling mechanisms defined for Mobile IPv6. The involved nodes need to select which tunnel instance to use when multiple ones are available due to multiple addresses on either end. But the WG does not plan to define a new mechanism for this, but rather document how to use existing mechanisms based upon preferences or policies. In particular, the WG will consider that a tunnel is alive as long as packets can be exchanged with the corresponding peer. In addition, local information, such as interface up/down events, or other failure detection mechanisms can be used to quickly detect failure of tunnel(s). Deliverables related to this include - A document explaining the motivations for a node using multiple interfaces and the scenarios where it may end up with multiple global addresses on its interfaces [Informational] - An analysis document explaining what are the limitations for mobile hosts using multiple simultaneous Care-of Addresses and Home Agent addresses using Mobile IPv6, whether issues are specific to Mobile IPv6 or not [Informational]. - A protocol extension to support the registration of multiple Care-of Addresses at a given Home Agent address [Standard Track]. - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport [both Standard Track]. (A.4) Work on solutions to deal with firewalls and the problems that firewalls cause as identified in RFC 4487. (A.5) Route optimization of network mobility. Three use cases have been identified for this. These are called the Aviation case, the Automotive case, and the Personal Mobile Router (consumer electronics) case, though the actual technical problems are characterized by the type of movements and environments more than by the specific industry using the technology. The group will explore these cases to gather requirements and proceed with solving the open issues. (1) Airline and spacecraft community, who are deploying NEMO for control systems, as well as Internet connectivity and entertainment systems. This use case is characterized by fast (~ 1000 km/h) moving objects over large distances (across continents). The main technical problem is that tunneling-based solutions imply a roundtrip to another continent and that BGP based solutions imply significant churn in the global Internet routing table. (2) Automotive industry who are deploying NEMO for in-car communication, entertainment, and data gathering, possible control systems use, and communication to roadside devices. This use case is characterized by moderately fast (~ 100-300 km/h) moving objects that employ local or cellular networks for connectivity. (3) Personal Mobile Routers, which are consumer devices that allow the user to bring a NEMO network with the user while mobile, and communicate with peer NEMO Basic Support nodes and nodes served by them. After gathering the requirements for these types of deployments, the working group will evaluate what type of route optimization needs to be performed (if any), and formulate a solution to those problems. If no requirements for those scenarios can be collected by the deadline, it will be assumed that the work is premature, and that type of deployment will be dropped from the WG. The group will only consider airline and spacecraft solutions that combine tunneling solutions for small movements with either federated tunnel servers or slowly changing end host prefixes. The group will only consider personal mobile router requirements about optimized routes to another mobile router belonging to the same operator. The group will only consider automotive industry requirements to allow MR-attached hosts to directly access the network where MR has attached to. Work on automotive and personal mobile router solutions requires rechartering. The WG will not consider extensions to routing protocols. The group will not consider general multi-homing problems that are not related to the deployment and maintenance of Mobile IPv6 or NEMO Basic Support protocols. The group will also not consider general route optimization, or other problems that are not related to the deployment and maintenance of NEMO Basic Support protocols. Similarly, the group will not consider or rely on the results of general routing architecture, Internet architecture, or identifier-locator split issues that are discussed in separate, long term efforts elsewhere in the IETF. Finally, the group will not consider solutions that require changes from correspondent nodes in the general Internet (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG require AAA support for Mobile IPv6. Part of this work is already being done in the DIME WG, but the MEXT WG is chartered to complete a design for RADIUS. Work items related to base specification maintenance include: (B.1) Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. One specific area of concern that should be analyzed and addressed relates to multilink subnets. This work item relates only to corrections and clarifications. The working group shall not revisit design decisions or change the protocol. (B.2) Update the IANA considerations of RFC 3775 to allow extensions for experimental purposes as well passing of optional vendor-specific information. (B.3) Finish working group documents that are currently in process, and submit for RFC. This includes prefix delegation protocol mechanism for network mobility, and a MIB for NEMO Basic Support. Work items related to informational documentation include: (C.1) Produce a design rationale that documents the historical thinking behind the introduction of an alternative security mechanism, the Authentication Protocol (RFC 4285). Goals and Milestones: Aug 2007 Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments Aug 2007 Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments Aug 2007 Submit Multiple CoA Registration to IESG Sep 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational. Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard. Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard Oct 2007 Submit -00 draft on Route Optimization needs for Personal Mobile Router Nov 2007 Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational Nov 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational. Dec 2007 Submit -00 draft for solution to aircraft/spacecraft problem Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard. Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard Jan 2007 Submit final doc on Route Optimization Needs for Automobile and Highway Deployments, for Informational Jan 2007 Submit final doc on Route Optimization needs for Personal Mobile Router, for Informational Feb 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. Feb 2008 Determine how to proceed with remaining automotive/Personal Mobile Router solutions Mar 2008 Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard Mar 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Apr 2008 Submit Flow/binding policy format to IESG, for Proposed Standard Apr 2008 Submit Flow/binding policy transport to IESG, for Proposed Standard Apr 2007 Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard. May 2008 Submit final doc for solution to aircraft/spacecraft problem to the IESG, for Proposed Standard May 2008 Recharter to work on the remaining automotive/Personal Mobile Router solutions Jul 2007 Submit Multiple Interfaces Motivations and Scenario to IESG, for Informational Jul 2007 Submit Analysis of the use of Multiple Simultaneous Care-of Addresses and Home Agent addresses, for Informational Aug 2008 Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. Aug 2008 Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mip6-bounces@ietf.org Tue Jun 26 03:30: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 1I35Up-0001xm-UJ; Tue, 26 Jun 2007 03:29:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35Uo-0001xY-Da; Tue, 26 Jun 2007 03:29:54 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I35U9-0000Yb-Aw; Tue, 26 Jun 2007 03:29:54 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 26 Jun 2007 00:29:12 -0700 X-IronPort-AV: i="4.16,462,1175497200"; d="scan'208"; a="4843564:sNHT22560060" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l5Q7TC0G009888; Tue, 26 Jun 2007 00:29:12 -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 l5Q7Svka002367; Tue, 26 Jun 2007 07:29:03 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); Tue, 26 Jun 2007 00:28:57 -0700 Received: from sgundavewxp ([10.32.246.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 00:28:56 -0700 From: "Sri Gundavelli" To: "'Jari Arkko'" References: <20070607005358.PNHE23012.oaamta07sl.mx.bigpond.com@PC20005> <35912544FC930E49BF20EF16C3EF2765024ACE7B@xmb-hkg-416.apac.cisco.com> <004f01c7a8bb$28b99470$1220fea9@amer.cisco.com> <467B9059.5090508@piuha.net> Subject: RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensus calltoclose issue 93 Date: Tue, 26 Jun 2007 00:28:52 -0700 Message-ID: <017801c7b7c3$a7900dd0$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 thread-index: Ace0rDWZxhwuwNAaS8CRy2KiWfMalwDEsshg In-Reply-To: <467B9059.5090508@piuha.net> X-OriginalArrivalTime: 26 Jun 2007 07:28:57.0039 (UTC) FILETIME=[A81DF5F0:01C7B7C3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2857; t=1182842952; x=1183706952; 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]=20Summary=20and=20conclusion=20of=3A=20DS-MIP6 =20-=20Consensus=20calltoclose=20issue=2093 |Sender:=20; bh=8G5W3doBIFbLq07l5XkNxxGE3IAS1hhuRZdpNDvOypM=; b=t+derRcgMTCF87kK82k2B7fSVJkWZ0PohfTPrB/xakwOwUTZZLym/eA97s5Gs3kwZjYRuE8d aL3YGQCJHiLoGSciD2A5fhD6p3y+3RvzW63PuGpNqUC/ifXIxvJoP26A; 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: 73734d43604d52d23b3eba644a169745 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Henrik Levkowetz' 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 Jari, > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Friday, June 22, 2007 2:03 AM > To: Sri Gundavelli > Cc: 'Basavaraj Patil'; 'Henrik Levkowetz'; nemo@ietf.org; > 'Mobile IPv6 Mailing List' > Subject: Re: [Mip6] Summary and conclusion of: DS-MIP6 - > Consensus calltoclose issue 93 > > Sri, > > > 4. Tunnel Keep Alive message > > > > When DSMIP chose IPv4 UDP transport for NAT traversal, > > the need for keepalive messaging between the tunnel > > peers for keeping the NAT bindings came up. The authors > > of the draft chose to use MIP6 signaling messages BU/BA > > as a way to refresh the keepalive messages. IMO, having > > a simple keepalive messages is lot more useful than an > > expensive BU/BA. Most 3519 implementation today optimize > > on this, by eliminating the keepalives when there is > > traffic. We cant do such optimizations with BU/BA. > > > > I don't see why not. First of all, you can always skip > a keepalive when there is other traffic. Secondly, you > can skip the entire contents and send an empty container. > Etc. > That's what I meant, when using a KA message, it can always be skipped when there is traffic. The KA processing is not expensive as compared to the use of BU/BA for the same purpose. > > 6. Why do we need GRE Header ? > > > > We need GRE tunnel header for various reasons, when ever we > > carry multiple streams within a tunnel, the GRE header for its > > mature header semantics, the key field and the sequence number > > field is useful. > > > > Hmm. Reading on... > > > We have some NEMO 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. > > > > Use cases: > > > > a.) Overlapping private IPv4 addressing support on the MAGs > > (PMIP6 Usage) > > > > From your list, this sounds like the most valid reason. But are > there other ways to deal with this? Can you expand on the > requirement and describe why there are no other ways to > deal with it? > This is for supporting the overlapping private IPv4 address scenario. As Vijay was saying, GRE is the most simplest way to solve this. It has the proper semantics in the header, such as GRE key etc. There are many MIP4 implementations that use this mechanism for tagging the flows between the PDSN and the HA. > > c.) Carrying other protocol packets (Lets say, IPX packets) > > in a MIP tunnel. > > > > This is not a very convincing use case. We can always encapsulate > L2TP etc. inside if we really want to. > The scenario was about using about using MIP tunnel for routing other traffic. L2TP cant be used, as it wont provide mobility. Regards Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 26 03:30: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 1I35VC-0002NI-0f; Tue, 26 Jun 2007 03:30:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35VA-0002L4-6H; Tue, 26 Jun 2007 03:30:16 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I35Ui-0000bi-PT; Tue, 26 Jun 2007 03:30:16 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 26 Jun 2007 00:29:49 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAM5dgEarR7PEh2dsb2JhbACPIAEBAQgOLA X-IronPort-AV: i="4.16,462,1175497200"; d="scan'208"; a="381793044:sNHT55508240" 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 l5Q7TlUN015700; Tue, 26 Jun 2007 00:29:47 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5Q7ThXH014553; Tue, 26 Jun 2007 07:29:43 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 00:29:42 -0700 Received: from sgundavewxp ([10.32.246.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 00:29:42 -0700 From: "Sri Gundavelli" To: "'Jari Arkko'" References: <003901c7a918$05c84a30$1220fea9@amer.cisco.com> <20070607153719.HSBB3831.oaamta08ps.mx.bigpond.com@PC20005> <004001c7a91b$fc2d0b10$1220fea9@amer.cisco.com> <467B9413.5080105@piuha.net> Subject: RE: [nemo] RE: [Mip6] issue 93 summary Date: Tue, 26 Jun 2007 00:29:41 -0700 Message-ID: <017901c7b7c3$c2b86a80$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 thread-index: Ace0rmhEvuXgAGJZRP+FsWTktDWqygDEpK3w In-Reply-To: <467B9413.5080105@piuha.net> X-OriginalArrivalTime: 26 Jun 2007 07:29:42.0632 (UTC) FILETIME=[C34AE680:01C7B7C3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2802; t=1182842987; x=1183706987; 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]=20issue=2093=20summary |Sender:=20; bh=tT+3FYcsRHku1lNUHKqLxiT4TAaFVOsHnflDl7sO6RQ=; b=ORI0vHaV2kpcKtrnXD94EH3JXH1RTaig5i0TATUDF0k/O7xqlQ9vg0aWQ/D/XtWsM/+wwV5z e3cs4bzHQRxxVBd/AsBuvgGGOkeexGqbWy17C6GkB1rkeujRAxTPt4LK; 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: 52f7a77164458f8c7b36b66787c853da Cc: nemo@ietf.org, 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 Hi Jari, > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Friday, June 22, 2007 2:19 AM > To: Sri Gundavelli > Cc: 'Hesham Soliman'; 'Karen E. Nielsen (AH/LMD)'; 'Alexandru > Petrescu'; nemo@ietf.org; mip6@ietf.org > Subject: Re: [nemo] RE: [Mip6] issue 93 summary > > Sri, > > > >From what I interpret from 3948, the mechanism of UDP transport > > can be used when the outer header and the contained header are > > both either IPv4 or IPv6. It did not state that the IPSec process > > has to look in the version field and do the demux to ip_input or > > ipv6_input. So, it did not talk about a scenario where the payload > > is IPv6 and the transport is IPv4. If we can get this clarified > > from the IPSec guys, that will be good. If 3948 can support IPv4, > > IPv6 payloads in an IPv4-UDP-ESP, then the issue exists is not > > applicable to option #1. > > > My interpretation of RFC 3948 is that it does not in any way change > the ESP processin rules. That is, a tunnel mode packet contains an > IP packet. IPsec can deal with both IPv4 and IPv6 packets in the > inner packet. > Sure, clarified further in that thread with Karen. Copied below. When using ESP, we dont have any issue supporting GRE. ESP follows the right protocol convention and it has the "next header" tag that identifies the payload and the same we are asking for DSMIP when riding over UDP. >>>>>>>>> The "next header" field in the ESP header identifies the payload. So, there is a proper payload qualifier in ESP header. The packet inside can be IPv4, IPv6 or GRE protocol types. So, when using ESP header, we dont need the additional 4-byte TLV header, as the protocol type qualifier is present. We need the same qualifier when there is no ESP header, when riding on UDP. So, the point to emphasize is that we are asking for a payload qualifier when using UDP, so that we can send GRE packets. We need this: IPv4-UDP-ESP-GRE-(IPv4, IPv6) (This works) IPv4-UDP-TLV-GRE-(IPv4, IPv6) When 3948 is used, ie if the port is 4500 and not DSMIP port, the TLV header is not required, as we can carry other protocol payloads and the required headers are present for that mode. So, the behaviour is consistent to 3948 and its the same for both option#1 and option#3. If we prefer both the ESP and non ESP traffic to be handled as a IP-UDP-TLV traffic on DSMIP port, the MIP is the handler for this traffic and will remove the tunnel encapsulations and pass it the the IPSec process. So, its about the registered handlers, IPSec is the handler on 4500 and MIP on the DSMIP port. MIP understands all the encapsulation formats and hence can do the proper decaps and pass it to the crypto system. >>>>>>>>>>>>>>>> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 26 03:31: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 1I35W5-0002yi-OA; Tue, 26 Jun 2007 03:31:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35W4-0002yd-Tg for mip6@ietf.org; Tue, 26 Jun 2007 03:31:12 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I35Vy-0000pw-4c for mip6@ietf.org; Tue, 26 Jun 2007 03:31:12 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 26 Jun 2007 00:31:06 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAM5dgEarR7PDh2dsb2JhbACPIAEBAQgOLA X-IronPort-AV: i="4.16,462,1175497200"; d="scan'208"; a="381793487:sNHT40271052" 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 l5Q7V58d012430; Tue, 26 Jun 2007 00:31:05 -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 l5Q7V4XH015935; Tue, 26 Jun 2007 07:31:05 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 00:31:04 -0700 Received: from sgundavewxp ([10.32.246.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 00:31:04 -0700 From: "Sri Gundavelli" To: "'Jari Arkko'" , "'Mobile IPv6 Mailing List'" References: <467B9879.2020107@piuha.net> Date: Tue, 26 Jun 2007 00:31:03 -0700 Message-ID: <017a01c7b7c3$f39480d0$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 thread-index: Ace0sQdqnaSXhxszShmFX6i96p5sgADELtHw In-Reply-To: <467B9879.2020107@piuha.net> X-OriginalArrivalTime: 26 Jun 2007 07:31:04.0634 (UTC) FILETIME=[F42B69A0:01C7B7C3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3004; t=1182843065; x=1183707065; 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=20Issue=2093=20situation |Sender:=20; bh=2RvORUQnPcOJNLq0dZRQbqr1Ho4UGCVwwNjD+zSP5sg=; b=SGPyyhunKk1cr5WVHkTsZjwXgPun979Wo9PGKieKKtiorwESJrjpnI0y/Vl1oRmT+MdPzIkD E07z6Gfx244K5YHE4/bPUAcvYvYWek6UMKE7Qm9DinVJn4xxN3ESUOLE; 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: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: mip6-chairs@tools.ietf.org Subject: [Mip6] RE: Issue 93 situation 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 Jari, I see a dead lock here and I dont see any shift in positions from either side. Any case, I do not want to delay this work, atleast from my side. I'm ok with having a seperate port for GRE when using IPv4-UDP. Also, based on the discussions with Karen, we are pretty much ending using different ports, one as per 3948, when using UDP for IPSec ESP and the usual DSMIP port. We can probably do the same for GRE. This may not be the best approach, but, atleast some people will be happy and the DSMIP work can move forward. My 2c. Also, we will certainly present enough data on the need for GRE in MIP6 and specifically in PMIP6, the use cases and the need in SDO's for this work. Regards Sri > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Friday, June 22, 2007 2:38 AM > To: Mobile IPv6 Mailing List > Cc: mip6-chairs@tools.ietf.org; Sri Gundavelli > Subject: Issue 93 situation > > All, > > The chairs asked me to help with assessing the consensus > and way forward with regards to this issue. > > After review the discussion during the last two weeks, I can > see some useful discussion and new technical aspects have > been brought in. Thanks! However, it is apparent that the situation > with regards to consensus has not changed, i.e., there is > no consensus, nor have we heard from too many new people > on this. And I have not seen anyone change their opinion, > which is not a good sign :-( > > At this point I would like to ask Hesham to submit the > draft if you have other changes since the previous > submission, and we need to continue discussing issue > 93 in a new way. > > I would like to note that getting the DSMIP spec out > is very important, and that this discussion is threatening > the completion of the work. > > I would suggest we do two things. First, I would like > get some of the main persons in this argument in a > conference call (the chairs and me will send mail to > some of you about this), in an effort to see if we can > agree on a compromise. As one of the preparations > for that I would like to ask Sri to send a detailed > description to the list about why NETLMM needs > encapsulations that are capable of differentiating > between flows or address spaces. > > Secondly, I would like to get some additional information > about what people believe about this issue. Please respond > to this query by Thursday, June 28th. We've heard from > people's preferred solutions. I'd like to hear about their > willingness to accept different solutions, even if they are > not preferred: > > A) Be willing to accept solution 1, with the option of having > solution 2-like extension later. > B) Be willing to accept solution 3. > > Here "be willing to accept" should be interpreted as in > not seeing a major technical fault or something that prevents > your implementation or business from functioning > properly. > > Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 26 05:16: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 1I37AK-00064h-8K; Tue, 26 Jun 2007 05:16:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I37AH-000641-Lo for mip6@ietf.org; Tue, 26 Jun 2007 05:16:49 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I37AG-000097-On for mip6@ietf.org; Tue, 26 Jun 2007 05:16:49 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8A6071986A7; Tue, 26 Jun 2007 12:16:15 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 402A7198691; Tue, 26 Jun 2007 12:16:15 +0300 (EEST) Message-ID: <4680D95F.10403@piuha.net> Date: Tue, 26 Jun 2007 12:16:15 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: draft-ietf-mip6-bootstrapping-split@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: Mobile IPv6 Mailing List , Sam Hartman , Brian E Carpenter Subject: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature 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 Authors, WG, IETF last call and IESG review produced a number of comments relating to the selection of a home agent via anycast. See in particular Sam Hartman's Discuss and Brian Carpenter's comments. There a number of ways in which we could address these issues. What I would like to try is to separate the anycast functionality from this draft and pursue it as a general IKEv2 extension for any application. The mip6 document would then advance immediately. Would this be a good way forward? Comments appreciated. Here are the comments from the IESG: > *Lars Eggert:* > *Comment:* > *[2007-06-20]* For all the different components of the solution, the > document > discusses a number of design options before describing the recommended > solution. I find this confusing. It would be much cleaner if there was > a normative section that talked about what is recommended, and an > informative section (or appendix) that would discuss options that are > not part of the recommended set. > > INTRODUCTION, paragraph 13: > > 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. > > I'm a bit confused by this. Title says this is for "split scenario" > bootstrapping. Abstract then says it's therefore generally applicable > for any bootstrapping scenario? (Also, it'd be good if the abstract > could define the words "split scenario" from the title somewhere, so > that folks not familiar with the term understand what it means.) > > > Section 5.1., paragraph 1: > > As > > mentioned before in the document, the only information that needs to > > be pre-configured on the Mobile Node is the domain name of the > > Mobility Service Provider. > > This paragraph says "need only domain name." Next paragraph says "MN > is configured with DNS server." So apparently MN needs to be configure > with at least two pieces of information? > > *Sam Hartman:* > *Discuss:* > *[2007-06-21]* A question to the aps folks: Doesn't the first label of > aSRV > registration need to be a well known port or at least get taken from > the same namespace? If so, has mip6 been registered there? Also, is > ipv6 an acceptable second label for the srv record? > > I'm concerned that the anycast behavior modifies IKEV2. I don't think > it is appropriate for MIP6 to be extending or modifying IKE in MIP6 > applications. Wouldn't it be better to run that extension by the > IPsec community and make it available generally? > > *Russ Housley:* > *Discuss:* > *[2007-06-20]* > Significant comments were included in the Gen-ART review from > Brian Carpenter. These need to be handled as any other Last > Call comments. (Note: Last Call is not concluded yet.) > > *Tim Polk:* > *Discuss:* > *[2007-06-20]* This document is underspecified with respect to > certificate processing and retrieval and CRL > checking. The document refers to CRL checking, but Figure 3 and the > accompanying text > seem to imply online status checking. Without additional details, it > seems unlikely interoperable > implementations could be developed. And from Brian Carpenter's last call comments: > > ...The Mobile Node sends the IKE_SA_INIT request to the > > anycast address. The node which has the anycast address assigned to > > one of its network interfaces... > > That is not IPv6 anycast. The definition of IPv6 anycast addresses is > quite clear (RFC 4291): > > Anycast: An identifier for a set of interfaces (typically > belonging to different nodes). A packet sent to an > anycast address is delivered to one of the interfaces > identified by that address (the "nearest" one, according > to the routing protocols' measure of distance). > > In other words, an anycast HA implementation would assign > the anycast address to *all* the HAs and the first one to > respond would "win". > > What is described in the current draft is a perfectly reasonable > redirect mechanism for load sharing (albeit with a single point > of failure) but it is *not* IPv6 anycast. It would be anycast > if *any* of the HAs could respond with the redirect. > > Either the design should be modified to do this, or the word > "anycast" should be dropped from the description. > > I don't know IKEv2 well enough to find fault with the cookie > mechanism for implementing a secure redirect. Even though > it's a bit of a hack, it seems to work. I note that RFC 4306 > does not use the term '"under attack" cookie'. > > ... > > The use of anycast address as specified above requires the > > implementation of anycast forwarding in such a way that the Home > > Agent can distinguish between an IKE_SA_INIT forwarded through an > > anycast address and one sent directly from the Mobile Node. One > > possible mechanism is to use IP-in-ip tunneling for forwarding the > > IKE_SA_INIT. In this case, the Home Agent can identify a forwarded > > IKE_SA_INIT based on the incoming interface or based on the > > additional IP header. Other mechanisms may be used. > > This is underspecified and will make it impossible to deploy > heterogeneous HAs together. > > ... > > A mobile node's security associations with its home agent may expire > > while it still has a valid binding cache entry at the the home > agent. > > In this case, the mobile node MUST NOT use an anycast address as the > > destination address in the IKE_SA_INIT exchange to setup new > security > > associations. It MUST try to setup security associations with its > > existing home agent. > > By definition, the MN doesn't know that a given address is an anycast > address, since anycast addresses are syntactically indistinguishable. > I think you mean: if the MN obtained its HA address via the "under > attack" > cookie exchange, it MUST continue to use that address and not revert > to the address it got from DNS. > > > 5.3.2. Home Address auto-configuration by the Mobile Node > ... > > For this reason the Mobile Node needs to obtain the home link > > prefixes through the IKEv2 exchange. In the Configuration Payload > > during the IKE_AUTH exchange, the Mobile Node includes the > > MIP6_HOME_PREFIX attribute in the CFG_REQUEST message. The Home > > Agent, when it processes this message, should include in the > > CFG_REPLY payload prefix information for one prefix on the home > link. > > It seems that 'should' should be a MUST. I don't see any alternative > case. > > > 5.4. Authorization and Authentication with MSA > ... > > The definition of this backend communication is out of the scope of > > this document. In [16] a list of goals for such a communication is > > provided. > ... > > 6. Home Address registration in the DNS > ... > > ...The > > detailed description of the communication between Home Agent and AAA > > is out of the scope of this document. More details are provided in > > [16]. > > I see a significant dependency here. I don't see how interoperable > implementations can be made while these issues are undefined. If > these issues are left open, there is a high risk of MSA/MSP interop > depending on interim or proprietary choices. I don't get this, since > the whole point of an MSA/MSP split is presumably to avoid > walled garden deployments. Since [16] is Informative, there is > nothing at present to prevent this. > > > 9.2. Home Address Assignment through IKEv2 > ... > > RFC 3775 [1] requires that a Home Agent check authorization of a > home > > address received during a Binding Update. Therefore, the home agent > > MUST authorize each home address allocation and use. This > > authorization is based on linking the mobile node identity used in > > the IKEv2 authentication process and the home address. Home agents > > MUST support at least the following two modes of authorization: > > > > o Configured home address(es) for each mobile node. In this mode, > > the home agent or infrastructure nodes behind it know what > > addresses a specific mobile node is authorized to use. The > mobile > > node is allowed to request these addresses, or if the mobile node > > requests any home address, these addresses are returned to it. > > > > o First-come-first-served (FCFS). In this mode, the home agent > > maintains a pool of "used" addresses, and allows mobile nodes to > > request any address, as long as it is not used by another mobile > > node. > > It isn't obvious why both are needed, but in any case the document > should specify whether these are MUST implement or MUST deploy. > > > 9.5. Dynamic DNS Update > > > > If a Home Agent performs dynamic DNS update on behalf of the Mobile > > Node directly with the DNS server, the Home Agent MUST have a > > security association of some type with the DNS server. The security > > association MAY be established either using DNSSEC [18] or TSIG/TKEY > > [19][20]. A security association is required even if the DNS server > > is in the same administrative domain as the Home Agent. The > security > > association SHOULD be separate from the security associations used > > for other purposes, such as AAA. > > Should 'required' be 'REQUIRED'? > > Since use of dynamic DNS is optional, is this a > 'MUST implement' security requirement? > > ... > > In the case where the Mobility Service Provider is different from > the > > Mobility Service Authorizer, the network administrators may want to > > limit the number of cross-administrative domain security > > associations. If the Mobile Node's FQDN is in the Mobility Service > > Authorizer's domain, since a security association for AAA signaling > > involved in mobility service authorization is required in any case, > > the Home Agent can send the Mobile Node's FQDN to the AAA server > > under the HA-AAA server security association, and the AAA server can > > perform the update. In that case, a security association is > required > > between the AAA server and DNS server for the dynamic DNS update. > > See [16] for a deeper discussion of the Home Agent to AAA server > > interface. > > Again, is this 'MUST implement'? If so, it increases my concern about > [16] being non-normative (and again two paragraphs below). > > > Regardless of whether the AAA server or Home Agent performs DNS > > update, the authorization of the Mobile Node to update a FQDN > MUST be > > checked prior to the performance of the update. It is an > > implementation issue as to how authorization is determined. > > Again, worrisome in terms of an MN implementer knowing > what to implement. We don't want MNs that only work with certain > types of HA/MSA/MSP setups. > > Editorial: > ---------- > > (these are typos that are actually technical errors) > > > 3. Split scenario > ... > > ... the Mobile Node potentially requires a certificate > > revocation list check (CTL check) > > s/CTL/CRL/ > > > 5.1. Home Agent Address Discovery > ... > > The Mobile Node needs to obtain the IP address of the DNS server > > before it can send a DNS request. > > s/the DNS server/a DNS server/ > > > 5.1.1. DNS lookup by Home Agent Name > ... > > Note that the configuration of a fixed home agent FQDN does allow > > dynamic assignment of a localized home agent. > > s/does/does not/ > > > 5.2. IPsec Security Associations setup > ... > > ... This is > > needed because the Mobile Node has to provide it is the owner of the > > FQDN provided in the subsequent DNS Update Option. > > s/provide/prove/ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 26 05:25: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 1I37J2-0004yv-DE; Tue, 26 Jun 2007 05:25:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I37J0-0004oq-Mb for mip6@ietf.org; Tue, 26 Jun 2007 05:25:50 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I37IM-0003qo-Ah for mip6@ietf.org; Tue, 26 Jun 2007 05:25:50 -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 l5Q9P7LB019453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 26 Jun 2007 02:25:08 -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 l5Q9P7XN032391; Tue, 26 Jun 2007 02:25:07 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 02:25:07 -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: Tue, 26 Jun 2007 02:25:04 -0700 Message-ID: In-Reply-To: <4680D95F.10403@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: bootstrapping-split anycast/ikev2 ha selection feature Thread-Index: Ace30rtRWkvDLfpxQSapTWnHutWNnQAAG5gQ From: "Giaretta, Gerardo" To: "Jari Arkko" , X-OriginalArrivalTime: 26 Jun 2007 09:25:07.0087 (UTC) FILETIME=[E296E1F0:01C7B7D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: e95407604bef3289cd27cb4f3b3a35b4 Cc: Mobile IPv6 Mailing List , Sam Hartman , Brian E Carpenter Subject: [Mip6] RE: bootstrapping-split anycast/ikev2 ha selection feature 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 Jari, I'm fine if we separate the anycast functionality from this draft.=20 This functionality was not in the original design team solution and was added later based on WG discussion. I see it as an optimization that may be useful in some scenarios, but not generally needed to dynamically bootstrap MIPv6.=20 I would like to get the opinions from Francis and Kilian too, as they suggested the anycast extension. Thanks Gerardo > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Tuesday, June 26, 2007 11:16 AM > To: draft-ietf-mip6-bootstrapping-split@tools.ietf.org > Cc: Mobile IPv6 Mailing List; Sam Hartman; Brian E Carpenter > Subject: bootstrapping-split anycast/ikev2 ha selection feature >=20 > Authors, WG, >=20 > IETF last call and IESG review produced a number of > comments relating to the selection of a home agent > via anycast. See in particular Sam Hartman's Discuss > and Brian Carpenter's comments. >=20 > There a number of ways in which we could address > these issues. What I would like to try is to separate > the anycast functionality from this draft and pursue > it as a general IKEv2 extension for any application. > The mip6 document would then advance immediately. > Would this be a good way forward? Comments > appreciated. >=20 > Here are the comments from the IESG: > > *Lars Eggert:* > > *Comment:* > > *[2007-06-20]* For all the different components of the solution, the > > document > > discusses a number of design options before describing the recommended > > solution. I find this confusing. It would be much cleaner if there was > > a normative section that talked about what is recommended, and an > > informative section (or appendix) that would discuss options that are > > not part of the recommended set. > > > > INTRODUCTION, paragraph 13: > > > 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. > > > > I'm a bit confused by this. Title says this is for "split scenario" > > bootstrapping. Abstract then says it's therefore generally applicable > > for any bootstrapping scenario? (Also, it'd be good if the abstract > > could define the words "split scenario" from the title somewhere, so > > that folks not familiar with the term understand what it means.) > > > > > > Section 5.1., paragraph 1: > > > As > > > mentioned before in the document, the only information that needs > to > > > be pre-configured on the Mobile Node is the domain name of the > > > Mobility Service Provider. > > > > This paragraph says "need only domain name." Next paragraph says "MN > > is configured with DNS server." So apparently MN needs to be configure > > with at least two pieces of information? > > > > *Sam Hartman:* > > *Discuss:* > > *[2007-06-21]* A question to the aps folks: Doesn't the first label of > > aSRV > > registration need to be a well known port or at least get taken from > > the same namespace? If so, has mip6 been registered there? Also, is > > ipv6 an acceptable second label for the srv record? > > > > I'm concerned that the anycast behavior modifies IKEV2. I don't think > > it is appropriate for MIP6 to be extending or modifying IKE in MIP6 > > applications. Wouldn't it be better to run that extension by the > > IPsec community and make it available generally? > > > > *Russ Housley:* > > *Discuss:* > > *[2007-06-20]* > > Significant comments were included in the Gen-ART review from > > Brian Carpenter. These need to be handled as any other Last > > Call comments. (Note: Last Call is not concluded yet.) > > > > *Tim Polk:* > > *Discuss:* > > *[2007-06-20]* This document is underspecified with respect to > > certificate processing and retrieval and CRL > > checking. The document refers to CRL checking, but Figure 3 and the > > accompanying text > > seem to imply online status checking. Without additional details, it > > seems unlikely interoperable > > implementations could be developed. > And from Brian Carpenter's last call comments: >=20 > > > ...The Mobile Node sends the IKE_SA_INIT request to the > > > anycast address. The node which has the anycast address assigned > to > > > one of its network interfaces... > > > > That is not IPv6 anycast. The definition of IPv6 anycast addresses is > > quite clear (RFC 4291): > > > > Anycast: An identifier for a set of interfaces (typically > > belonging to different nodes). A packet sent to an > > anycast address is delivered to one of the interfaces > > identified by that address (the "nearest" one, according > > to the routing protocols' measure of distance). > > > > In other words, an anycast HA implementation would assign > > the anycast address to *all* the HAs and the first one to > > respond would "win". > > > > What is described in the current draft is a perfectly reasonable > > redirect mechanism for load sharing (albeit with a single point > > of failure) but it is *not* IPv6 anycast. It would be anycast > > if *any* of the HAs could respond with the redirect. > > > > Either the design should be modified to do this, or the word > > "anycast" should be dropped from the description. > > > > I don't know IKEv2 well enough to find fault with the cookie > > mechanism for implementing a secure redirect. Even though > > it's a bit of a hack, it seems to work. I note that RFC 4306 > > does not use the term '"under attack" cookie'. > > > > ... > > > The use of anycast address as specified above requires the > > > implementation of anycast forwarding in such a way that the Home > > > Agent can distinguish between an IKE_SA_INIT forwarded through an > > > anycast address and one sent directly from the Mobile Node. One > > > possible mechanism is to use IP-in-ip tunneling for forwarding the > > > IKE_SA_INIT. In this case, the Home Agent can identify a forwarded > > > IKE_SA_INIT based on the incoming interface or based on the > > > additional IP header. Other mechanisms may be used. > > > > This is underspecified and will make it impossible to deploy > > heterogeneous HAs together. > > > > ... > > > A mobile node's security associations with its home agent may > expire > > > while it still has a valid binding cache entry at the the home > > agent. > > > In this case, the mobile node MUST NOT use an anycast address as > the > > > destination address in the IKE_SA_INIT exchange to setup new > > security > > > associations. It MUST try to setup security associations with its > > > existing home agent. > > > > By definition, the MN doesn't know that a given address is an anycast > > address, since anycast addresses are syntactically indistinguishable. > > I think you mean: if the MN obtained its HA address via the "under > > attack" > > cookie exchange, it MUST continue to use that address and not revert > > to the address it got from DNS. > > > > > 5.3.2. Home Address auto-configuration by the Mobile Node > > ... > > > For this reason the Mobile Node needs to obtain the home link > > > prefixes through the IKEv2 exchange. In the Configuration Payload > > > during the IKE_AUTH exchange, the Mobile Node includes the > > > MIP6_HOME_PREFIX attribute in the CFG_REQUEST message. The Home > > > Agent, when it processes this message, should include in the > > > CFG_REPLY payload prefix information for one prefix on the home > > link. > > > > It seems that 'should' should be a MUST. I don't see any alternative > > case. > > > > > 5.4. Authorization and Authentication with MSA > > ... > > > The definition of this backend communication is out of the scope of > > > this document. In [16] a list of goals for such a communication is > > > provided. > > ... > > > 6. Home Address registration in the DNS > > ... > > > ...The > > > detailed description of the communication between Home Agent and > AAA > > > is out of the scope of this document. More details are provided in > > > [16]. > > > > I see a significant dependency here. I don't see how interoperable > > implementations can be made while these issues are undefined. If > > these issues are left open, there is a high risk of MSA/MSP interop > > depending on interim or proprietary choices. I don't get this, since > > the whole point of an MSA/MSP split is presumably to avoid > > walled garden deployments. Since [16] is Informative, there is > > nothing at present to prevent this. > > > > > 9.2. Home Address Assignment through IKEv2 > > ... > > > RFC 3775 [1] requires that a Home Agent check authorization of a > > home > > > address received during a Binding Update. Therefore, the home > agent > > > MUST authorize each home address allocation and use. This > > > authorization is based on linking the mobile node identity used in > > > the IKEv2 authentication process and the home address. Home agents > > > MUST support at least the following two modes of authorization: > > > > > > o Configured home address(es) for each mobile node. In this mode, > > > the home agent or infrastructure nodes behind it know what > > > addresses a specific mobile node is authorized to use. The > > mobile > > > node is allowed to request these addresses, or if the mobile > node > > > requests any home address, these addresses are returned to it. > > > > > > o First-come-first-served (FCFS). In this mode, the home agent > > > maintains a pool of "used" addresses, and allows mobile nodes to > > > request any address, as long as it is not used by another mobile > > > node. > > > > It isn't obvious why both are needed, but in any case the document > > should specify whether these are MUST implement or MUST deploy. > > > > > 9.5. Dynamic DNS Update > > > > > > If a Home Agent performs dynamic DNS update on behalf of the Mobile > > > Node directly with the DNS server, the Home Agent MUST have a > > > security association of some type with the DNS server. The > security > > > association MAY be established either using DNSSEC [18] or > TSIG/TKEY > > > [19][20]. A security association is required even if the DNS > server > > > is in the same administrative domain as the Home Agent. The > > security > > > association SHOULD be separate from the security associations used > > > for other purposes, such as AAA. > > > > Should 'required' be 'REQUIRED'? > > > > Since use of dynamic DNS is optional, is this a > > 'MUST implement' security requirement? > > > > ... > > > In the case where the Mobility Service Provider is different from > > the > > > Mobility Service Authorizer, the network administrators may want to > > > limit the number of cross-administrative domain security > > > associations. If the Mobile Node's FQDN is in the Mobility Service > > > Authorizer's domain, since a security association for AAA signaling > > > involved in mobility service authorization is required in any case, > > > the Home Agent can send the Mobile Node's FQDN to the AAA server > > > under the HA-AAA server security association, and the AAA server > can > > > perform the update. In that case, a security association is > > required > > > between the AAA server and DNS server for the dynamic DNS update. > > > See [16] for a deeper discussion of the Home Agent to AAA server > > > interface. > > > > Again, is this 'MUST implement'? If so, it increases my concern about > > [16] being non-normative (and again two paragraphs below). > > > > > Regardless of whether the AAA server or Home Agent performs DNS > > > update, the authorization of the Mobile Node to update a FQDN > > MUST be > > > checked prior to the performance of the update. It is an > > > implementation issue as to how authorization is determined. > > > > Again, worrisome in terms of an MN implementer knowing > > what to implement. We don't want MNs that only work with certain > > types of HA/MSA/MSP setups. > > > > Editorial: > > ---------- > > > > (these are typos that are actually technical errors) > > > > > 3. Split scenario > > ... > > > ... the Mobile Node potentially requires a certificate > > > revocation list check (CTL check) > > > > s/CTL/CRL/ > > > > > 5.1. Home Agent Address Discovery > > ... > > > The Mobile Node needs to obtain the IP address of the DNS server > > > before it can send a DNS request. > > > > s/the DNS server/a DNS server/ > > > > > 5.1.1. DNS lookup by Home Agent Name > > ... > > > Note that the configuration of a fixed home agent FQDN does allow > > > dynamic assignment of a localized home agent. > > > > s/does/does not/ > > > > > 5.2. IPsec Security Associations setup > > ... > > > ... This is > > > needed because the Mobile Node has to provide it is the owner of > the > > > FQDN provided in the subsequent DNS Update Option. > > > > s/provide/prove/ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 26 06:00: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 1I37qQ-0004So-Ew; Tue, 26 Jun 2007 06:00:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I37qO-0004Sb-SD for mip6@ietf.org; Tue, 26 Jun 2007 06:00:20 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I37qK-0000fI-Gu for mip6@ietf.org; Tue, 26 Jun 2007 06:00:20 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1182852015!13254715!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12621 invoked from network); 26 Jun 2007 10:00:15 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-119.messagelabs.com with SMTP; 26 Jun 2007 10:00:15 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5QA0FBj019460 for ; Tue, 26 Jun 2007 03:00:15 -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 l5QA0EOr003277 for ; Tue, 26 Jun 2007 05:00:14 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.1.41]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5QA0DFe003260 for ; Tue, 26 Jun 2007 05:00:14 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Tue, 26 Jun 2007 11:00:12 +0100 Message-ID: <4680E3AB.7060505@gmail.com> Date: Tue, 26 Jun 2007 12:00:11 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Giaretta, Gerardo" Subject: Re: [Mip6] RE: bootstrapping-split anycast/ikev2 ha selection feature References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000751-5, 24/06/2007), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 26 Jun 2007 10:00:12.0620 (UTC) FILETIME=[C995B8C0:01C7B7D8] X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org, Mobile IPv6 Mailing List , Brian E Carpenter , Sam Hartman 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 Giaretta, Gerardo wrote: > Hi Jari, > > I'm fine if we separate the anycast functionality from this draft. > > This functionality was not in the original design team solution and > was added later based on WG discussion. I see it as an optimization > that may be useful in some scenarios, but not generally needed to > dynamically bootstrap MIPv6. > > I would like to get the opinions from Francis and Kilian too, as they > suggested the anycast extension. I would also like to learn the oppinion from Francis and Kilian. IMHO Separating the anycast feature from the draft: I have no oppinion. I agree 'anycast' could be less widely agreed on but at the same time I'm wondering whether it is possible to design a bootstrapping or discovery mechanism without anycast or multicast concepts. The fact that Brian suggests that the anycast behaviour is not as suggested by this draft (draft suggests the anycast address is assigned to only one interface whereas in reality the anycast semantics means that it is assigned to all HAs interfaces) is not anycast's fault but specifiers' understanding of anycast. I mean the spec _could_ be improved to take that IESG remark into account. The implementation of DHAAD acts as Brian suggests it should act. >> And from Brian Carpenter's last call comments: >> >>>> ...The Mobile Node sends the IKE_SA_INIT request to the anycast >>>> address. The node which has the anycast address assigned to >>>> one of its network interfaces... >>> >>> That is not IPv6 anycast. The definition of IPv6 anycast >>> addresses is quite clear (RFC 4291): >>> >>> Anycast: An identifier for a set of interfaces (typically >>> belonging to different nodes). A packet sent to an anycast >>> address is delivered to one of the interfaces identified by that >>> address (the "nearest" one, according to the routing protocols' >>> measure of distance). >>> >>> In other words, an anycast HA implementation would assign the >>> anycast address to *all* the HAs and the first one to respond >>> would "win". >>> >>> What is described in the current draft is a perfectly reasonable >>> redirect mechanism for load sharing (albeit with a single point >>> of failure) but it is *not* IPv6 anycast. It would be anycast if >>> *any* of the HAs could respond with the redirect. This is right, and it is the way DHAAD works in theory and in practice: MN sends DHAAD-Req to the anycast all-HA address, all HAs receive it and only one HA sends back to MN the DHAAD-Rep (collective decision of _which_ HA responds is done previously by HAs exchanging values in RAs), with its source address that will become the HA address as recorded by MN. >>> Either the design should be modified to do this, or the word >>> "anycast" should be dropped from the description. I have no strong oppinion on eliminating the anycast concept from this draft. [...] >>> By definition, the MN doesn't know that a given address is an >>> anycast address, since anycast addresses are syntactically >>> indistinguishable. A side note here, not intended to disgress the discussion. I think the all_HA anycast address Interface Identifier is reserved by IANA and only the prefix is variable. Thus I think a node _can_ distinguish very well when the address is anycast, especially all_HA anycast. I also think this address _could_ be used as an address in the SA. But of course, an anycast address is indeed 128bit as any other IPv6 address, and in this way indistinguishable. Just a side note and again, I have no strong oppinion on getting rid of the anycast aspect from this spec. 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 Jun 26 09:11:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Aph-0002gi-Ai; Tue, 26 Jun 2007 09:11:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Apf-0002gb-UD for mip6@ietf.org; Tue, 26 Jun 2007 09:11:48 -0400 Received: from s-utl02-atpop.stsn.net ([72.254.128.202]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I3Apf-0001vC-CC for mip6@ietf.org; Tue, 26 Jun 2007 09:11:47 -0400 Received: from s-utl02-atpop.stsn.net ([127.0.0.1]) by s-utl02-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007062609104500774 ; Tue, 26 Jun 2007 09:10:45 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.322,BAYES_00: -1.665 X-Spam-Level: Received: from [127.0.0.1] ([10.86.122.70]) by s-utl02-atpop.stsn.net; Tue, 26 Jun 2007 09:10:44 -0400 Message-ID: <46811047.7080707@azairenet.com> Date: Tue, 26 Jun 2007 06:10:31 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Jari Arkko References: <4680D95F.10403@piuha.net> In-Reply-To: <4680D95F.10403@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org, Mobile IPv6 Mailing List , Sam Hartman , Brian E Carpenter Subject: [Mip6] Re: bootstrapping-split anycast/ikev2 ha selection feature 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 Jari, Brian and Sam, I saw three significant comments regarding the use of anycast address. Let me respond to them. 1. The MIPv6 community has a very good understanding of how IPv6 anycast works. We have been using it for the dynamic home agent address discovery [RFC 3775] for years. The text in the document that talks about assigning the anycast address to the one of the interfaces is the result of some "careless text". Sorry about that. Needs to be fixed. All the home agents in the anycast group would have the anycast address configured. 2. The mobile node might not know it is using anycast address since anycast addresses are supposed to look like unicast address. MIPv6 home agents anycast address is a special reserved address. See RFC 2526. The mobile node would know. 3. MIPv6 WG shouldn't be extending IKEv2. Why? Since when? We have added quite a few attributes/payloads/etc... to IKEv2 already. We have specified a mechanism to dynamically update the IKEv2 SA (the 'K' bit in RFC 3775 and 3776). We dynamically update the tunnel mode IPsec SA with a binding update. For this document we have extended IKEv2 to ignore the mismatch between the destination address on the IKE_SA_INIT request from the MN and the source address on the IKE_SA_INIT response to the MN. We spoke to a number of IKEv2/IPsec folks on this topic. Most agreed that the "MUST" in RFC 4306 about matching the destination address on the IKE_SA_INIT request and the source address on the IKE_SA_INIT response is wrong. It shouldn't have been a "MUST". So I don't yet see a reason to remove it. Vijay Jari Arkko wrote: > Authors, WG, > > IETF last call and IESG review produced a number of > comments relating to the selection of a home agent > via anycast. See in particular Sam Hartman's Discuss > and Brian Carpenter's comments. > > There a number of ways in which we could address > these issues. What I would like to try is to separate > the anycast functionality from this draft and pursue > it as a general IKEv2 extension for any application. > The mip6 document would then advance immediately. > Would this be a good way forward? Comments > appreciated. > > Here are the comments from the IESG: >> *Lars Eggert:* >> *Comment:* >> *[2007-06-20]* For all the different components of the solution, the >> document >> discusses a number of design options before describing the recommended >> solution. I find this confusing. It would be much cleaner if there was >> a normative section that talked about what is recommended, and an >> informative section (or appendix) that would discuss options that are >> not part of the recommended set. >> >> INTRODUCTION, paragraph 13: >>> 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. >> I'm a bit confused by this. Title says this is for "split scenario" >> bootstrapping. Abstract then says it's therefore generally applicable >> for any bootstrapping scenario? (Also, it'd be good if the abstract >> could define the words "split scenario" from the title somewhere, so >> that folks not familiar with the term understand what it means.) >> >> >> Section 5.1., paragraph 1: >>> As >>> mentioned before in the document, the only information that needs to >>> be pre-configured on the Mobile Node is the domain name of the >>> Mobility Service Provider. >> This paragraph says "need only domain name." Next paragraph says "MN >> is configured with DNS server." So apparently MN needs to be configure >> with at least two pieces of information? >> >> *Sam Hartman:* >> *Discuss:* >> *[2007-06-21]* A question to the aps folks: Doesn't the first label of >> aSRV >> registration need to be a well known port or at least get taken from >> the same namespace? If so, has mip6 been registered there? Also, is >> ipv6 an acceptable second label for the srv record? >> >> I'm concerned that the anycast behavior modifies IKEV2. I don't think >> it is appropriate for MIP6 to be extending or modifying IKE in MIP6 >> applications. Wouldn't it be better to run that extension by the >> IPsec community and make it available generally? >> >> *Russ Housley:* >> *Discuss:* >> *[2007-06-20]* >> Significant comments were included in the Gen-ART review from >> Brian Carpenter. These need to be handled as any other Last >> Call comments. (Note: Last Call is not concluded yet.) >> >> *Tim Polk:* >> *Discuss:* >> *[2007-06-20]* This document is underspecified with respect to >> certificate processing and retrieval and CRL >> checking. The document refers to CRL checking, but Figure 3 and the >> accompanying text >> seem to imply online status checking. Without additional details, it >> seems unlikely interoperable >> implementations could be developed. > And from Brian Carpenter's last call comments: > >>> ...The Mobile Node sends the IKE_SA_INIT request to the >>> anycast address. The node which has the anycast address assigned to >>> one of its network interfaces... >> >> That is not IPv6 anycast. The definition of IPv6 anycast addresses is >> quite clear (RFC 4291): >> >> Anycast: An identifier for a set of interfaces (typically >> belonging to different nodes). A packet sent to an >> anycast address is delivered to one of the interfaces >> identified by that address (the "nearest" one, according >> to the routing protocols' measure of distance). >> >> In other words, an anycast HA implementation would assign >> the anycast address to *all* the HAs and the first one to >> respond would "win". >> >> What is described in the current draft is a perfectly reasonable >> redirect mechanism for load sharing (albeit with a single point >> of failure) but it is *not* IPv6 anycast. It would be anycast >> if *any* of the HAs could respond with the redirect. >> >> Either the design should be modified to do this, or the word >> "anycast" should be dropped from the description. >> >> I don't know IKEv2 well enough to find fault with the cookie >> mechanism for implementing a secure redirect. Even though >> it's a bit of a hack, it seems to work. I note that RFC 4306 >> does not use the term '"under attack" cookie'. >> >> ... >>> The use of anycast address as specified above requires the >>> implementation of anycast forwarding in such a way that the Home >>> Agent can distinguish between an IKE_SA_INIT forwarded through an >>> anycast address and one sent directly from the Mobile Node. One >>> possible mechanism is to use IP-in-ip tunneling for forwarding the >>> IKE_SA_INIT. In this case, the Home Agent can identify a forwarded >>> IKE_SA_INIT based on the incoming interface or based on the >>> additional IP header. Other mechanisms may be used. >> >> This is underspecified and will make it impossible to deploy >> heterogeneous HAs together. >> >> ... >>> A mobile node's security associations with its home agent may expire >>> while it still has a valid binding cache entry at the the home >> agent. >>> In this case, the mobile node MUST NOT use an anycast address as the >>> destination address in the IKE_SA_INIT exchange to setup new >> security >>> associations. It MUST try to setup security associations with its >>> existing home agent. >> >> By definition, the MN doesn't know that a given address is an anycast >> address, since anycast addresses are syntactically indistinguishable. >> I think you mean: if the MN obtained its HA address via the "under >> attack" >> cookie exchange, it MUST continue to use that address and not revert >> to the address it got from DNS. >> >>> 5.3.2. Home Address auto-configuration by the Mobile Node >> ... >>> For this reason the Mobile Node needs to obtain the home link >>> prefixes through the IKEv2 exchange. In the Configuration Payload >>> during the IKE_AUTH exchange, the Mobile Node includes the >>> MIP6_HOME_PREFIX attribute in the CFG_REQUEST message. The Home >>> Agent, when it processes this message, should include in the >>> CFG_REPLY payload prefix information for one prefix on the home >> link. >> >> It seems that 'should' should be a MUST. I don't see any alternative >> case. >> >>> 5.4. Authorization and Authentication with MSA >> ... >>> The definition of this backend communication is out of the scope of >>> this document. In [16] a list of goals for such a communication is >>> provided. >> ... >>> 6. Home Address registration in the DNS >> ... >>> ...The >>> detailed description of the communication between Home Agent and AAA >>> is out of the scope of this document. More details are provided in >>> [16]. >> >> I see a significant dependency here. I don't see how interoperable >> implementations can be made while these issues are undefined. If >> these issues are left open, there is a high risk of MSA/MSP interop >> depending on interim or proprietary choices. I don't get this, since >> the whole point of an MSA/MSP split is presumably to avoid >> walled garden deployments. Since [16] is Informative, there is >> nothing at present to prevent this. >> >>> 9.2. Home Address Assignment through IKEv2 >> ... >>> RFC 3775 [1] requires that a Home Agent check authorization of a >> home >>> address received during a Binding Update. Therefore, the home agent >>> MUST authorize each home address allocation and use. This >>> authorization is based on linking the mobile node identity used in >>> the IKEv2 authentication process and the home address. Home agents >>> MUST support at least the following two modes of authorization: >>> >>> o Configured home address(es) for each mobile node. In this mode, >>> the home agent or infrastructure nodes behind it know what >>> addresses a specific mobile node is authorized to use. The >> mobile >>> node is allowed to request these addresses, or if the mobile node >>> requests any home address, these addresses are returned to it. >>> >>> o First-come-first-served (FCFS). In this mode, the home agent >>> maintains a pool of "used" addresses, and allows mobile nodes to >>> request any address, as long as it is not used by another mobile >>> node. >> >> It isn't obvious why both are needed, but in any case the document >> should specify whether these are MUST implement or MUST deploy. >> >>> 9.5. Dynamic DNS Update >>> >>> If a Home Agent performs dynamic DNS update on behalf of the Mobile >>> Node directly with the DNS server, the Home Agent MUST have a >>> security association of some type with the DNS server. The security >>> association MAY be established either using DNSSEC [18] or TSIG/TKEY >>> [19][20]. A security association is required even if the DNS server >>> is in the same administrative domain as the Home Agent. The >> security >>> association SHOULD be separate from the security associations used >>> for other purposes, such as AAA. >> >> Should 'required' be 'REQUIRED'? >> >> Since use of dynamic DNS is optional, is this a >> 'MUST implement' security requirement? >> >> ... >>> In the case where the Mobility Service Provider is different from >> the >>> Mobility Service Authorizer, the network administrators may want to >>> limit the number of cross-administrative domain security >>> associations. If the Mobile Node's FQDN is in the Mobility Service >>> Authorizer's domain, since a security association for AAA signaling >>> involved in mobility service authorization is required in any case, >>> the Home Agent can send the Mobile Node's FQDN to the AAA server >>> under the HA-AAA server security association, and the AAA server can >>> perform the update. In that case, a security association is >> required >>> between the AAA server and DNS server for the dynamic DNS update. >>> See [16] for a deeper discussion of the Home Agent to AAA server >>> interface. >> >> Again, is this 'MUST implement'? If so, it increases my concern about >> [16] being non-normative (and again two paragraphs below). >> >>> Regardless of whether the AAA server or Home Agent performs DNS >>> update, the authorization of the Mobile Node to update a FQDN >> MUST be >>> checked prior to the performance of the update. It is an >>> implementation issue as to how authorization is determined. >> >> Again, worrisome in terms of an MN implementer knowing >> what to implement. We don't want MNs that only work with certain >> types of HA/MSA/MSP setups. >> >> Editorial: >> ---------- >> >> (these are typos that are actually technical errors) >> >>> 3. Split scenario >> ... >>> ... the Mobile Node potentially requires a certificate >>> revocation list check (CTL check) >> >> s/CTL/CRL/ >> >>> 5.1. Home Agent Address Discovery >> ... >>> The Mobile Node needs to obtain the IP address of the DNS server >>> before it can send a DNS request. >> >> s/the DNS server/a DNS server/ >> >>> 5.1.1. DNS lookup by Home Agent Name >> ... >>> Note that the configuration of a fixed home agent FQDN does allow >>> dynamic assignment of a localized home agent. >> >> s/does/does not/ >> >>> 5.2. IPsec Security Associations setup >> ... >>> ... This is >>> needed because the Mobile Node has to provide it is the owner of the >>> FQDN provided in the subsequent DNS Update Option. >> >> s/provide/prove/ > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 26 09:14: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 1I3AsT-0003ml-BY; Tue, 26 Jun 2007 09:14:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3AsR-0003mY-VF for mip6@ietf.org; Tue, 26 Jun 2007 09:14:40 -0400 Received: from s-utl02-atpop.stsn.net ([72.254.128.202]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I3AsR-00024f-Cp for mip6@ietf.org; Tue, 26 Jun 2007 09:14:39 -0400 Received: from s-utl02-atpop.stsn.net ([127.0.0.1]) by s-utl02-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007062609141900795 ; Tue, 26 Jun 2007 09:14:19 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.286,BAYES_00: -1.665 X-Spam-Level: Received: from [127.0.0.1] ([10.86.122.70]) by s-utl02-atpop.stsn.net; Tue, 26 Jun 2007 09:14:18 -0400 Message-ID: <4681111D.7070905@azairenet.com> Date: Tue, 26 Jun 2007 06:14:05 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Giaretta, Gerardo" Subject: Re: [Mip6] RE: bootstrapping-split anycast/ikev2 ha selection feature References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4e722e9456ead69ba4cdd21dd3d3600 Cc: draft-ietf-mip6-bootstrapping-split@tools.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 Giaretta, Gerardo wrote: > Hi Jari, > > I'm fine if we separate the anycast functionality from this draft. > > This functionality was not in the original design team solution and was > added later based on WG discussion. I see it as an optimization that may > be useful in some scenarios, but not generally needed to dynamically > bootstrap MIPv6. > > I would like to get the opinions from Francis and Kilian too, as they > suggested the anycast extension. It is true that they suggested it, but we had WG consensus to add this feature. So it means the MIP6 WG thinks it is a good optimization. :) Vijay > > Thanks > Gerardo > >> -----Original Message----- >> From: Jari Arkko [mailto:jari.arkko@piuha.net] >> Sent: Tuesday, June 26, 2007 11:16 AM >> To: draft-ietf-mip6-bootstrapping-split@tools.ietf.org >> Cc: Mobile IPv6 Mailing List; Sam Hartman; Brian E Carpenter >> Subject: bootstrapping-split anycast/ikev2 ha selection feature >> >> Authors, WG, >> >> IETF last call and IESG review produced a number of >> comments relating to the selection of a home agent >> via anycast. See in particular Sam Hartman's Discuss >> and Brian Carpenter's comments. >> >> There a number of ways in which we could address >> these issues. What I would like to try is to separate >> the anycast functionality from this draft and pursue >> it as a general IKEv2 extension for any application. >> The mip6 document would then advance immediately. >> Would this be a good way forward? Comments >> appreciated. >> >> Here are the comments from the IESG: >>> *Lars Eggert:* >>> *Comment:* >>> *[2007-06-20]* For all the different components of the solution, > the >>> document >>> discusses a number of design options before describing the > recommended >>> solution. I find this confusing. It would be much cleaner if there > was >>> a normative section that talked about what is recommended, and an >>> informative section (or appendix) that would discuss options that > are >>> not part of the recommended set. >>> >>> INTRODUCTION, paragraph 13: >>>> 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. >>> I'm a bit confused by this. Title says this is for "split > scenario" >>> bootstrapping. Abstract then says it's therefore generally > applicable >>> for any bootstrapping scenario? (Also, it'd be good if the > abstract >>> could define the words "split scenario" from the title somewhere, > so >>> that folks not familiar with the term understand what it means.) >>> >>> >>> Section 5.1., paragraph 1: >>>> As >>>> mentioned before in the document, the only information that > needs >> to >>>> be pre-configured on the Mobile Node is the domain name of the >>>> Mobility Service Provider. >>> This paragraph says "need only domain name." Next paragraph says > "MN >>> is configured with DNS server." So apparently MN needs to be > configure >>> with at least two pieces of information? >>> >>> *Sam Hartman:* >>> *Discuss:* >>> *[2007-06-21]* A question to the aps folks: Doesn't the first label > of >>> aSRV >>> registration need to be a well known port or at least get taken from >>> the same namespace? If so, has mip6 been registered there? Also, > is >>> ipv6 an acceptable second label for the srv record? >>> >>> I'm concerned that the anycast behavior modifies IKEV2. I don't > think >>> it is appropriate for MIP6 to be extending or modifying IKE in MIP6 >>> applications. Wouldn't it be better to run that extension by the >>> IPsec community and make it available generally? >>> >>> *Russ Housley:* >>> *Discuss:* >>> *[2007-06-20]* >>> Significant comments were included in the Gen-ART review from >>> Brian Carpenter. These need to be handled as any other Last >>> Call comments. (Note: Last Call is not concluded yet.) >>> >>> *Tim Polk:* >>> *Discuss:* >>> *[2007-06-20]* This document is underspecified with respect to >>> certificate processing and retrieval and CRL >>> checking. The document refers to CRL checking, but Figure 3 and the >>> accompanying text >>> seem to imply online status checking. Without additional details, > it >>> seems unlikely interoperable >>> implementations could be developed. >> And from Brian Carpenter's last call comments: >> >>>> ...The Mobile Node sends the IKE_SA_INIT request to the >>>> anycast address. The node which has the anycast address > assigned >> to >>>> one of its network interfaces... >>> That is not IPv6 anycast. The definition of IPv6 anycast addresses > is >>> quite clear (RFC 4291): >>> >>> Anycast: An identifier for a set of interfaces (typically >>> belonging to different nodes). A packet sent to an >>> anycast address is delivered to one of the interfaces >>> identified by that address (the "nearest" one, > according >>> to the routing protocols' measure of distance). >>> >>> In other words, an anycast HA implementation would assign >>> the anycast address to *all* the HAs and the first one to >>> respond would "win". >>> >>> What is described in the current draft is a perfectly reasonable >>> redirect mechanism for load sharing (albeit with a single point >>> of failure) but it is *not* IPv6 anycast. It would be anycast >>> if *any* of the HAs could respond with the redirect. >>> >>> Either the design should be modified to do this, or the word >>> "anycast" should be dropped from the description. >>> >>> I don't know IKEv2 well enough to find fault with the cookie >>> mechanism for implementing a secure redirect. Even though >>> it's a bit of a hack, it seems to work. I note that RFC 4306 >>> does not use the term '"under attack" cookie'. >>> >>> ... >>>> The use of anycast address as specified above requires the >>>> implementation of anycast forwarding in such a way that the > Home >>>> Agent can distinguish between an IKE_SA_INIT forwarded through > an >>>> anycast address and one sent directly from the Mobile Node. > One >>>> possible mechanism is to use IP-in-ip tunneling for forwarding > the >>>> IKE_SA_INIT. In this case, the Home Agent can identify a > forwarded >>>> IKE_SA_INIT based on the incoming interface or based on the >>>> additional IP header. Other mechanisms may be used. >>> This is underspecified and will make it impossible to deploy >>> heterogeneous HAs together. >>> >>> ... >>>> A mobile node's security associations with its home agent may >> expire >>>> while it still has a valid binding cache entry at the the home >>> agent. >>>> In this case, the mobile node MUST NOT use an anycast address > as >> the >>>> destination address in the IKE_SA_INIT exchange to setup new >>> security >>>> associations. It MUST try to setup security associations with > its >>>> existing home agent. >>> By definition, the MN doesn't know that a given address is an > anycast >>> address, since anycast addresses are syntactically > indistinguishable. >>> I think you mean: if the MN obtained its HA address via the "under >>> attack" >>> cookie exchange, it MUST continue to use that address and not revert >>> to the address it got from DNS. >>> >>>> 5.3.2. Home Address auto-configuration by the Mobile Node >>> ... >>>> For this reason the Mobile Node needs to obtain the home link >>>> prefixes through the IKEv2 exchange. In the Configuration > Payload >>>> during the IKE_AUTH exchange, the Mobile Node includes the >>>> MIP6_HOME_PREFIX attribute in the CFG_REQUEST message. The > Home >>>> Agent, when it processes this message, should include in the >>>> CFG_REPLY payload prefix information for one prefix on the home >>> link. >>> >>> It seems that 'should' should be a MUST. I don't see any alternative >>> case. >>> >>>> 5.4. Authorization and Authentication with MSA >>> ... >>>> The definition of this backend communication is out of the > scope of >>>> this document. In [16] a list of goals for such a > communication is >>>> provided. >>> ... >>>> 6. Home Address registration in the DNS >>> ... >>>> ...The >>>> detailed description of the communication between Home Agent > and >> AAA >>>> is out of the scope of this document. More details are > provided in >>>> [16]. >>> I see a significant dependency here. I don't see how interoperable >>> implementations can be made while these issues are undefined. If >>> these issues are left open, there is a high risk of MSA/MSP interop >>> depending on interim or proprietary choices. I don't get this, since >>> the whole point of an MSA/MSP split is presumably to avoid >>> walled garden deployments. Since [16] is Informative, there is >>> nothing at present to prevent this. >>> >>>> 9.2. Home Address Assignment through IKEv2 >>> ... >>>> RFC 3775 [1] requires that a Home Agent check authorization of > a >>> home >>>> address received during a Binding Update. Therefore, the home >> agent >>>> MUST authorize each home address allocation and use. This >>>> authorization is based on linking the mobile node identity used > in >>>> the IKEv2 authentication process and the home address. Home > agents >>>> MUST support at least the following two modes of authorization: >>>> >>>> o Configured home address(es) for each mobile node. In this > mode, >>>> the home agent or infrastructure nodes behind it know what >>>> addresses a specific mobile node is authorized to use. The >>> mobile >>>> node is allowed to request these addresses, or if the mobile >> node >>>> requests any home address, these addresses are returned to > it. >>>> o First-come-first-served (FCFS). In this mode, the home > agent >>>> maintains a pool of "used" addresses, and allows mobile > nodes to >>>> request any address, as long as it is not used by another > mobile >>>> node. >>> It isn't obvious why both are needed, but in any case the document >>> should specify whether these are MUST implement or MUST deploy. >>> >>>> 9.5. Dynamic DNS Update >>>> >>>> If a Home Agent performs dynamic DNS update on behalf of the > Mobile >>>> Node directly with the DNS server, the Home Agent MUST have a >>>> security association of some type with the DNS server. The >> security >>>> association MAY be established either using DNSSEC [18] or >> TSIG/TKEY >>>> [19][20]. A security association is required even if the DNS >> server >>>> is in the same administrative domain as the Home Agent. The >>> security >>>> association SHOULD be separate from the security associations > used >>>> for other purposes, such as AAA. >>> Should 'required' be 'REQUIRED'? >>> >>> Since use of dynamic DNS is optional, is this a >>> 'MUST implement' security requirement? >>> >>> ... >>>> In the case where the Mobility Service Provider is different > from >>> the >>>> Mobility Service Authorizer, the network administrators may > want to >>>> limit the number of cross-administrative domain security >>>> associations. If the Mobile Node's FQDN is in the Mobility > Service >>>> Authorizer's domain, since a security association for AAA > signaling >>>> involved in mobility service authorization is required in any > case, >>>> the Home Agent can send the Mobile Node's FQDN to the AAA > server >>>> under the HA-AAA server security association, and the AAA > server >> can >>>> perform the update. In that case, a security association is >>> required >>>> between the AAA server and DNS server for the dynamic DNS > update. >>>> See [16] for a deeper discussion of the Home Agent to AAA > server >>>> interface. >>> Again, is this 'MUST implement'? If so, it increases my concern > about >>> [16] being non-normative (and again two paragraphs below). >>> >>>> Regardless of whether the AAA server or Home Agent performs DNS >>>> update, the authorization of the Mobile Node to update a FQDN >>> MUST be >>>> checked prior to the performance of the update. It is an >>>> implementation issue as to how authorization is determined. >>> Again, worrisome in terms of an MN implementer knowing >>> what to implement. We don't want MNs that only work with certain >>> types of HA/MSA/MSP setups. >>> >>> Editorial: >>> ---------- >>> >>> (these are typos that are actually technical errors) >>> >>>> 3. Split scenario >>> ... >>>> ... the Mobile Node potentially requires a certificate >>>> revocation list check (CTL check) >>> s/CTL/CRL/ >>> >>>> 5.1. Home Agent Address Discovery >>> ... >>>> The Mobile Node needs to obtain the IP address of the DNS > server >>>> before it can send a DNS request. >>> s/the DNS server/a DNS server/ >>> >>>> 5.1.1. DNS lookup by Home Agent Name >>> ... >>>> Note that the configuration of a fixed home agent FQDN does > allow >>>> dynamic assignment of a localized home agent. >>> s/does/does not/ >>> >>>> 5.2. IPsec Security Associations setup >>> ... >>>> ... This is >>>> needed because the Mobile Node has to provide it is the owner > of >> the >>>> FQDN provided in the subsequent DNS Update Option. >>> s/provide/prove/ > > > _______________________________________________ > 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 Jun 26 10:10: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 1I3Bkf-0005K6-DB; Tue, 26 Jun 2007 10:10:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Bka-0005HC-E1 for mip6@ietf.org; Tue, 26 Jun 2007 10:10:36 -0400 Received: from cluster-f.mailcontrol.com ([85.119.2.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3BgU-0007sA-BS for mip6@ietf.org; Tue, 26 Jun 2007 10:06:51 -0400 Received: from rly11f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly11f.srv.mailcontrol.com (MailControl) with ESMTP id l5QE64KF023177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Jun 2007 15:06:11 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly11f.srv.mailcontrol.com (MailControl) id l5QE5xoA022717 for mip6@ietf.org; Tue, 26 Jun 2007 15:05:59 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly11f-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l5QE5r3g022472; Tue, 26 Jun 2007 15:05:58 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 086e_b4f41dc8_23ec_11dc_9010_0030482aac25; Tue, 26 Jun 2007 15:54:06 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007062616054971-1943989 ; Tue, 26 Jun 2007 16:05:49 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.151,BAYES_00: -1.665,TOTAL_SCORE: -1.514 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Tue, 26 Jun 2007 16:03:58 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature In-Reply-To: <4680D95F.10403@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature Thread-Index: Ace30wObTQaipUIVSkyrKS7U00S/gAADwP0Q References: <4680D95F.10403@piuha.net> To: "Jari Arkko" , Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de> Date: Tue, 26 Jun 2007 16:05:33 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-07-07-10 (www.mailcontrol.com) on 10.70.1.121 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: b5216aa5b0df24d46eaed76d4f65aa31 Cc: Mobile IPv6 Mailing List , Sam Hartman , Brian E Carpenter 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 Jari, As Vijay said, Brian's comment about wrong use of "anycast" is a misunderstanding due to unclear wording in the draft. It was the intention that multiple node (i.e., typcially all HAs) have the anycast address assigned and that *any* one of those (i.e., the one that receive the IKE_SA_INIT request) forward it to the "best" HA. The text in section 5.2.1 should be modified accordingly. This should resolve Brian's main concern. Regarding the proposal to separate the anycast assignment from the draft: The MIPv6 WG has already extended IKEv2 in various ways even in the same draft, e.g., the MIP6_HOME_PREFIX attribute in the CFG_REQUEST message or the "USE_ASSIGNED_HoA" Notify Payload for address assignment in draft-ietf-mip6-bootstrapping-split. I don't understand why the anycast mechanism should be handled differently (i.e., separated from the draft) than the other IKEv2 extensions. Also, I'm concerned about the delay introduced by such a separation and that it may have impacts on potential deployments. Some operator folks (e.g., Jean-Michel if I remember correctly) requested a HA assignment mechanism for the split scenario, and the anycast IKE mechanism is currently the only mechanism providing this.=20 So in conclusion, I also prefer to keep it in the document. A compromise could be to keep the mechanism in the draft and at the same time pursue a general anycast-based IKEv2 extension in another WG. When the general IKEv2 anycast extension will be completed and standardized, the MIPv6-specific mechanism in the split scenario draft can still be removed (in a bis-version).=20 Kilian > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Dienstag, 26. Juni 2007 11:16 > To: draft-ietf-mip6-bootstrapping-split@tools.ietf.org > Cc: Mobile IPv6 Mailing List; Sam Hartman; Brian E Carpenter > Subject: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature >=20 > Authors, WG, >=20 > IETF last call and IESG review produced a number of > comments relating to the selection of a home agent > via anycast. See in particular Sam Hartman's Discuss > and Brian Carpenter's comments. >=20 > There a number of ways in which we could address > these issues. What I would like to try is to separate > the anycast functionality from this draft and pursue > it as a general IKEv2 extension for any application. > The mip6 document would then advance immediately. > Would this be a good way forward? Comments > appreciated. >=20 > Here are the comments from the IESG: > > *Lars Eggert:* > > *Comment:* > > *[2007-06-20]* For all the different components of the=20 > solution, the > > document > > discusses a number of design options before describing=20 > the recommended > > solution. I find this confusing. It would be much cleaner=20 > if there was > > a normative section that talked about what is recommended, and an > > informative section (or appendix) that would discuss=20 > options that are > > not part of the recommended set. > > > > INTRODUCTION, paragraph 13: > > > 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=20 > than basic > > > network access, and is therefore generically applicable to any > > > bootstrapping case. > > > > I'm a bit confused by this. Title says this is for "split=20 > scenario" > > bootstrapping. Abstract then says it's therefore=20 > generally applicable > > for any bootstrapping scenario? (Also, it'd be good if=20 > the abstract > > could define the words "split scenario" from the title=20 > somewhere, so > > that folks not familiar with the term understand what it means.) > > > > > > Section 5.1., paragraph 1: > > > As > > > mentioned before in the document, the only information=20 > that needs to > > > be pre-configured on the Mobile Node is the domain name of the > > > Mobility Service Provider. > > > > This paragraph says "need only domain name." Next=20 > paragraph says "MN > > is configured with DNS server." So apparently MN needs to=20 > be configure > > with at least two pieces of information? > > > > *Sam Hartman:* > > *Discuss:* > > *[2007-06-21]* A question to the aps folks: Doesn't the=20 > first label of > > aSRV > > registration need to be a well known port or at least get taken from > > the same namespace? If so, has mip6 been registered there?=20 > Also, is > > ipv6 an acceptable second label for the srv record? > > > > I'm concerned that the anycast behavior modifies IKEV2. I=20 > don't think > > it is appropriate for MIP6 to be extending or modifying IKE in MIP6 > > applications. Wouldn't it be better to run that extension by the > > IPsec community and make it available generally? > > > > *Russ Housley:* > > *Discuss:* > > *[2007-06-20]* > > Significant comments were included in the Gen-ART review from > > Brian Carpenter. These need to be handled as any other Last > > Call comments. (Note: Last Call is not concluded yet.) > > > > *Tim Polk:* > > *Discuss:* > > *[2007-06-20]* This document is underspecified with respect to > > certificate processing and retrieval and CRL > > checking. The document refers to CRL checking, but Figure 3 and the > > accompanying text > > seem to imply online status checking. Without additional=20 > details, it > > seems unlikely interoperable > > implementations could be developed. > And from Brian Carpenter's last call comments: >=20 > > > ...The Mobile Node sends the IKE_SA_INIT request to the > > > anycast address. The node which has the anycast=20 > address assigned to > > > one of its network interfaces... > > =20 > > That is not IPv6 anycast. The definition of IPv6 anycast=20 > addresses is > > quite clear (RFC 4291): > > =20 > > Anycast: An identifier for a set of interfaces (typically > > belonging to different nodes). A packet sent to an > > anycast address is delivered to one of the interfaces > > identified by that address (the "nearest"=20 > one, according > > to the routing protocols' measure of distance). > > =20 > > In other words, an anycast HA implementation would assign > > the anycast address to *all* the HAs and the first one to > > respond would "win". > > =20 > > What is described in the current draft is a perfectly reasonable > > redirect mechanism for load sharing (albeit with a single point > > of failure) but it is *not* IPv6 anycast. It would be anycast > > if *any* of the HAs could respond with the redirect. > > =20 > > Either the design should be modified to do this, or the word > > "anycast" should be dropped from the description. > > =20 > > I don't know IKEv2 well enough to find fault with the cookie > > mechanism for implementing a secure redirect. Even though > > it's a bit of a hack, it seems to work. I note that RFC 4306 > > does not use the term '"under attack" cookie'. > > =20 > > ... > > > The use of anycast address as specified above requires the > > > implementation of anycast forwarding in such a way=20 > that the Home > > > Agent can distinguish between an IKE_SA_INIT forwarded=20 > through an > > > anycast address and one sent directly from the Mobile=20 > Node. One > > > possible mechanism is to use IP-in-ip tunneling for=20 > forwarding the > > > IKE_SA_INIT. In this case, the Home Agent can=20 > identify a forwarded > > > IKE_SA_INIT based on the incoming interface or based on the > > > additional IP header. Other mechanisms may be used. > > =20 > > This is underspecified and will make it impossible to deploy > > heterogeneous HAs together. > > =20 > > ... > > > A mobile node's security associations with its home=20 > agent may expire > > > while it still has a valid binding cache entry at the the home > > agent. > > > In this case, the mobile node MUST NOT use an anycast=20 > address as the > > > destination address in the IKE_SA_INIT exchange to setup new > > security > > > associations. It MUST try to setup security=20 > associations with its > > > existing home agent. > > =20 > > By definition, the MN doesn't know that a given address is=20 > an anycast > > address, since anycast addresses are syntactically=20 > indistinguishable. > > I think you mean: if the MN obtained its HA address via the "under > > attack" > > cookie exchange, it MUST continue to use that address and not revert > > to the address it got from DNS. > > =20 > > > 5.3.2. Home Address auto-configuration by the Mobile Node > > ... > > > For this reason the Mobile Node needs to obtain the home link > > > prefixes through the IKEv2 exchange. In the=20 > Configuration Payload > > > during the IKE_AUTH exchange, the Mobile Node includes the > > > MIP6_HOME_PREFIX attribute in the CFG_REQUEST message.=20 > The Home > > > Agent, when it processes this message, should include in the > > > CFG_REPLY payload prefix information for one prefix on the home > > link. > > =20 > > It seems that 'should' should be a MUST. I don't see any alternative > > case. > > =20 > > > 5.4. Authorization and Authentication with MSA > > ... > > > The definition of this backend communication is out of=20 > the scope of > > > this document. In [16] a list of goals for such a=20 > communication is > > > provided. > > ... > > > 6. Home Address registration in the DNS > > ... > > > ...The > > > detailed description of the communication between Home=20 > Agent and AAA > > > is out of the scope of this document. More details=20 > are provided in > > > [16]. > > =20 > > I see a significant dependency here. I don't see how interoperable > > implementations can be made while these issues are undefined. If =20 > > these issues are left open, there is a high risk of MSA/MSP interop > > depending on interim or proprietary choices. I don't get this, since > > the whole point of an MSA/MSP split is presumably to avoid > > walled garden deployments. Since [16] is Informative, there is > > nothing at present to prevent this. > > =20 > > > 9.2. Home Address Assignment through IKEv2 > > ... > > > RFC 3775 [1] requires that a Home Agent check=20 > authorization of a > > home > > > address received during a Binding Update. Therefore,=20 > the home agent > > > MUST authorize each home address allocation and use. This > > > authorization is based on linking the mobile node=20 > identity used in > > > the IKEv2 authentication process and the home address.=20 > Home agents > > > MUST support at least the following two modes of authorization: > > > =20 > > > o Configured home address(es) for each mobile node. =20 > In this mode, > > > the home agent or infrastructure nodes behind it know what > > > addresses a specific mobile node is authorized to use. The > > mobile > > > node is allowed to request these addresses, or if=20 > the mobile node > > > requests any home address, these addresses are=20 > returned to it. > > > =20 > > > o First-come-first-served (FCFS). In this mode, the=20 > home agent > > > maintains a pool of "used" addresses, and allows=20 > mobile nodes to > > > request any address, as long as it is not used by=20 > another mobile > > > node. > > =20 > > It isn't obvious why both are needed, but in any case the document > > should specify whether these are MUST implement or MUST deploy. > > =20 > > > 9.5. Dynamic DNS Update > > > =20 > > > If a Home Agent performs dynamic DNS update on behalf=20 > of the Mobile > > > Node directly with the DNS server, the Home Agent MUST have a > > > security association of some type with the DNS server.=20 > The security > > > association MAY be established either using DNSSEC=20 > [18] or TSIG/TKEY > > > [19][20]. A security association is required even if=20 > the DNS server > > > is in the same administrative domain as the Home Agent. The > > security > > > association SHOULD be separate from the security=20 > associations used > > > for other purposes, such as AAA. > > =20 > > Should 'required' be 'REQUIRED'? > > =20 > > Since use of dynamic DNS is optional, is this a > > 'MUST implement' security requirement? > > =20 > > ... > > > In the case where the Mobility Service Provider is=20 > different from > > the > > > Mobility Service Authorizer, the network=20 > administrators may want to > > > limit the number of cross-administrative domain security > > > associations. If the Mobile Node's FQDN is in the=20 > Mobility Service > > > Authorizer's domain, since a security association for=20 > AAA signaling > > > involved in mobility service authorization is required=20 > in any case, > > > the Home Agent can send the Mobile Node's FQDN to the=20 > AAA server > > > under the HA-AAA server security association, and the=20 > AAA server can > > > perform the update. In that case, a security association is > > required > > > between the AAA server and DNS server for the dynamic=20 > DNS update. > > > See [16] for a deeper discussion of the Home Agent to=20 > AAA server > > > interface. > > =20 > > Again, is this 'MUST implement'? If so, it increases my=20 > concern about > > [16] being non-normative (and again two paragraphs below). > > =20 > > > Regardless of whether the AAA server or Home Agent performs DNS > > > update, the authorization of the Mobile Node to update a FQDN > > MUST be > > > checked prior to the performance of the update. It is an > > > implementation issue as to how authorization is determined. > > =20 > > Again, worrisome in terms of an MN implementer knowing > > what to implement. We don't want MNs that only work with certain > > types of HA/MSA/MSP setups. > > =20 > > Editorial: > > ---------- > > =20 > > (these are typos that are actually technical errors) > > =20 > > > 3. Split scenario > > ... > > > ... the Mobile Node potentially requires a certificate > > > revocation list check (CTL check) > > =20 > > s/CTL/CRL/ > > =20 > > > 5.1. Home Agent Address Discovery > > ... > > > The Mobile Node needs to obtain the IP address of the=20 > DNS server > > > before it can send a DNS request. > > =20 > > s/the DNS server/a DNS server/ > > =20 > > > 5.1.1. DNS lookup by Home Agent Name > > ... > > > Note that the configuration of a fixed home agent FQDN=20 > does allow > > > dynamic assignment of a localized home agent. > > =20 > > s/does/does not/ > > =20 > > > 5.2. IPsec Security Associations setup > > ... > > > ... This is > > > needed because the Mobile Node has to provide it is=20 > the owner of the > > > FQDN provided in the subsequent DNS Update Option. > > =20 > > s/provide/prove/ >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=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 Tue Jun 26 12:25: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 1I3Dqq-0003R6-TF; Tue, 26 Jun 2007 12:25:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Dqp-0003Qn-8T for mip6@ietf.org; Tue, 26 Jun 2007 12:25:11 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3DqG-0002AN-8M for mip6@ietf.org; Tue, 26 Jun 2007 12:25:11 -0400 Message-ID: <0a5e01c7b80e$7b893130$576115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jari Arkko" , References: <4680D95F.10403@piuha.net> Date: Tue, 26 Jun 2007 09:24:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f Cc: Mobile IPv6 Mailing List , Sam Hartman , Brian E Carpenter Subject: [Mip6] Re: bootstrapping-split anycast/ikev2 ha selection feature 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 Jari, I'd certainly be happy with that solution. If this change is acceptable to the WG, I'd suggest that we remove the anycast, then when the general solution is on track for publication, we update the bootstrapping RFC to include the anycast feature. I think this will facilitate getting the bootstrapping work completed. jak ----- Original Message ----- From: "Jari Arkko" To: Cc: "Mobile IPv6 Mailing List" ; "Sam Hartman" ; "Brian E Carpenter" Sent: Tuesday, June 26, 2007 2:16 AM Subject: bootstrapping-split anycast/ikev2 ha selection feature Authors, WG, IETF last call and IESG review produced a number of comments relating to the selection of a home agent via anycast. See in particular Sam Hartman's Discuss and Brian Carpenter's comments. There a number of ways in which we could address these issues. What I would like to try is to separate the anycast functionality from this draft and pursue it as a general IKEv2 extension for any application. The mip6 document would then advance immediately. Would this be a good way forward? Comments appreciated. Here are the comments from the IESG: > *Lars Eggert:* > *Comment:* > *[2007-06-20]* For all the different components of the solution, the > document > discusses a number of design options before describing the recommended > solution. I find this confusing. It would be much cleaner if there was > a normative section that talked about what is recommended, and an > informative section (or appendix) that would discuss options that are > not part of the recommended set. > > INTRODUCTION, paragraph 13: > > 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. > > I'm a bit confused by this. Title says this is for "split scenario" > bootstrapping. Abstract then says it's therefore generally applicable > for any bootstrapping scenario? (Also, it'd be good if the abstract > could define the words "split scenario" from the title somewhere, so > that folks not familiar with the term understand what it means.) > > > Section 5.1., paragraph 1: > > As > > mentioned before in the document, the only information that needs to > > be pre-configured on the Mobile Node is the domain name of the > > Mobility Service Provider. > > This paragraph says "need only domain name." Next paragraph says "MN > is configured with DNS server." So apparently MN needs to be configure > with at least two pieces of information? > > *Sam Hartman:* > *Discuss:* > *[2007-06-21]* A question to the aps folks: Doesn't the first label of > aSRV > registration need to be a well known port or at least get taken from > the same namespace? If so, has mip6 been registered there? Also, is > ipv6 an acceptable second label for the srv record? > > I'm concerned that the anycast behavior modifies IKEV2. I don't think > it is appropriate for MIP6 to be extending or modifying IKE in MIP6 > applications. Wouldn't it be better to run that extension by the > IPsec community and make it available generally? > > *Russ Housley:* > *Discuss:* > *[2007-06-20]* > Significant comments were included in the Gen-ART review from > Brian Carpenter. These need to be handled as any other Last > Call comments. (Note: Last Call is not concluded yet.) > > *Tim Polk:* > *Discuss:* > *[2007-06-20]* This document is underspecified with respect to > certificate processing and retrieval and CRL > checking. The document refers to CRL checking, but Figure 3 and the > accompanying text > seem to imply online status checking. Without additional details, it > seems unlikely interoperable > implementations could be developed. And from Brian Carpenter's last call comments: > > ...The Mobile Node sends the IKE_SA_INIT request to the > > anycast address. The node which has the anycast address assigned to > > one of its network interfaces... > > That is not IPv6 anycast. The definition of IPv6 anycast addresses is > quite clear (RFC 4291): > > Anycast: An identifier for a set of interfaces (typically > belonging to different nodes). A packet sent to an > anycast address is delivered to one of the interfaces > identified by that address (the "nearest" one, according > to the routing protocols' measure of distance). > > In other words, an anycast HA implementation would assign > the anycast address to *all* the HAs and the first one to > respond would "win". > > What is described in the current draft is a perfectly reasonable > redirect mechanism for load sharing (albeit with a single point > of failure) but it is *not* IPv6 anycast. It would be anycast > if *any* of the HAs could respond with the redirect. > > Either the design should be modified to do this, or the word > "anycast" should be dropped from the description. > > I don't know IKEv2 well enough to find fault with the cookie > mechanism for implementing a secure redirect. Even though > it's a bit of a hack, it seems to work. I note that RFC 4306 > does not use the term '"under attack" cookie'. > > ... > > The use of anycast address as specified above requires the > > implementation of anycast forwarding in such a way that the Home > > Agent can distinguish between an IKE_SA_INIT forwarded through an > > anycast address and one sent directly from the Mobile Node. One > > possible mechanism is to use IP-in-ip tunneling for forwarding the > > IKE_SA_INIT. In this case, the Home Agent can identify a forwarded > > IKE_SA_INIT based on the incoming interface or based on the > > additional IP header. Other mechanisms may be used. > > This is underspecified and will make it impossible to deploy > heterogeneous HAs together. > > ... > > A mobile node's security associations with its home agent may expire > > while it still has a valid binding cache entry at the the home > agent. > > In this case, the mobile node MUST NOT use an anycast address as the > > destination address in the IKE_SA_INIT exchange to setup new > security > > associations. It MUST try to setup security associations with its > > existing home agent. > > By definition, the MN doesn't know that a given address is an anycast > address, since anycast addresses are syntactically indistinguishable. > I think you mean: if the MN obtained its HA address via the "under > attack" > cookie exchange, it MUST continue to use that address and not revert > to the address it got from DNS. > > > 5.3.2. Home Address auto-configuration by the Mobile Node > ... > > For this reason the Mobile Node needs to obtain the home link > > prefixes through the IKEv2 exchange. In the Configuration Payload > > during the IKE_AUTH exchange, the Mobile Node includes the > > MIP6_HOME_PREFIX attribute in the CFG_REQUEST message. The Home > > Agent, when it processes this message, should include in the > > CFG_REPLY payload prefix information for one prefix on the home > link. > > It seems that 'should' should be a MUST. I don't see any alternative > case. > > > 5.4. Authorization and Authentication with MSA > ... > > The definition of this backend communication is out of the scope of > > this document. In [16] a list of goals for such a communication is > > provided. > ... > > 6. Home Address registration in the DNS > ... > > ...The > > detailed description of the communication between Home Agent and AAA > > is out of the scope of this document. More details are provided in > > [16]. > > I see a significant dependency here. I don't see how interoperable > implementations can be made while these issues are undefined. If > these issues are left open, there is a high risk of MSA/MSP interop > depending on interim or proprietary choices. I don't get this, since > the whole point of an MSA/MSP split is presumably to avoid > walled garden deployments. Since [16] is Informative, there is > nothing at present to prevent this. > > > 9.2. Home Address Assignment through IKEv2 > ... > > RFC 3775 [1] requires that a Home Agent check authorization of a > home > > address received during a Binding Update. Therefore, the home agent > > MUST authorize each home address allocation and use. This > > authorization is based on linking the mobile node identity used in > > the IKEv2 authentication process and the home address. Home agents > > MUST support at least the following two modes of authorization: > > > > o Configured home address(es) for each mobile node. In this mode, > > the home agent or infrastructure nodes behind it know what > > addresses a specific mobile node is authorized to use. The > mobile > > node is allowed to request these addresses, or if the mobile node > > requests any home address, these addresses are returned to it. > > > > o First-come-first-served (FCFS). In this mode, the home agent > > maintains a pool of "used" addresses, and allows mobile nodes to > > request any address, as long as it is not used by another mobile > > node. > > It isn't obvious why both are needed, but in any case the document > should specify whether these are MUST implement or MUST deploy. > > > 9.5. Dynamic DNS Update > > > > If a Home Agent performs dynamic DNS update on behalf of the Mobile > > Node directly with the DNS server, the Home Agent MUST have a > > security association of some type with the DNS server. The security > > association MAY be established either using DNSSEC [18] or TSIG/TKEY > > [19][20]. A security association is required even if the DNS server > > is in the same administrative domain as the Home Agent. The > security > > association SHOULD be separate from the security associations used > > for other purposes, such as AAA. > > Should 'required' be 'REQUIRED'? > > Since use of dynamic DNS is optional, is this a > 'MUST implement' security requirement? > > ... > > In the case where the Mobility Service Provider is different from > the > > Mobility Service Authorizer, the network administrators may want to > > limit the number of cross-administrative domain security > > associations. If the Mobile Node's FQDN is in the Mobility Service > > Authorizer's domain, since a security association for AAA signaling > > involved in mobility service authorization is required in any case, > > the Home Agent can send the Mobile Node's FQDN to the AAA server > > under the HA-AAA server security association, and the AAA server can > > perform the update. In that case, a security association is > required > > between the AAA server and DNS server for the dynamic DNS update. > > See [16] for a deeper discussion of the Home Agent to AAA server > > interface. > > Again, is this 'MUST implement'? If so, it increases my concern about > [16] being non-normative (and again two paragraphs below). > > > Regardless of whether the AAA server or Home Agent performs DNS > > update, the authorization of the Mobile Node to update a FQDN > MUST be > > checked prior to the performance of the update. It is an > > implementation issue as to how authorization is determined. > > Again, worrisome in terms of an MN implementer knowing > what to implement. We don't want MNs that only work with certain > types of HA/MSA/MSP setups. > > Editorial: > ---------- > > (these are typos that are actually technical errors) > > > 3. Split scenario > ... > > ... the Mobile Node potentially requires a certificate > > revocation list check (CTL check) > > s/CTL/CRL/ > > > 5.1. Home Agent Address Discovery > ... > > The Mobile Node needs to obtain the IP address of the DNS server > > before it can send a DNS request. > > s/the DNS server/a DNS server/ > > > 5.1.1. DNS lookup by Home Agent Name > ... > > Note that the configuration of a fixed home agent FQDN does allow > > dynamic assignment of a localized home agent. > > s/does/does not/ > > > 5.2. IPsec Security Associations setup > ... > > ... This is > > needed because the Mobile Node has to provide it is the owner of the > > FQDN provided in the subsequent DNS Update Option. > > s/provide/prove/ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 26 12:44: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 1I3E9w-0004em-Ml; Tue, 26 Jun 2007 12:44:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3E9v-0004eh-Qe for mip6@ietf.org; Tue, 26 Jun 2007 12:44:55 -0400 Received: from an-out-0708.google.com ([209.85.132.245]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3E9v-0007kF-Jb for mip6@ietf.org; Tue, 26 Jun 2007 12:44:55 -0400 Received: by an-out-0708.google.com with SMTP id c17so431394anc for ; Tue, 26 Jun 2007 09:43:42 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=t4bFU0v/B5hlCwHv5LW9AAOgOm0Hk5Y5CmlEd4MGGRaGwuYygaGBgvCygoK7tPacW73N3nX2Wnt5okJI2YyJAF/w6/w+ESNYroI2sXock2USOjG/UlA4S7RrGIi+Dg19mFqrCh/9LtIPs5RdW3Wgjb8NttGKbO6u1owSPZp4SBM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XPgpsJ35Fv1qwvlU5Gcef91HYdpR/jRArLSYEbHIa+C7BHzn6HIsCpFl2yg/rN2uaUdO9tzFtS9GzFXheXBULD4/U++b/IrRUlajJCAic7mu7NxTihxpKC8BjwrzbPGSMOAaukG+ss8D3kfq20leinDFZ6o8ppMlckMuvSlDHho= Received: by 10.100.197.15 with SMTP id u15mr3921798anf.1182876222783; Tue, 26 Jun 2007 09:43:42 -0700 (PDT) Received: by 10.100.135.16 with HTTP; Tue, 26 Jun 2007 09:43:42 -0700 (PDT) Message-ID: <729b68be0706260943q6c3aba16oa8fe3ba0d96dea8b@mail.gmail.com> Date: Tue, 26 Jun 2007 18:43:42 +0200 From: "Jean-Michel Combes" To: "Kilian Weniger" Subject: Re: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4680D95F.10403@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org, Mobile IPv6 Mailing List , Brian E Carpenter , Sam Hartman 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, 2007/6/26, Kilian Weniger : > Hi Jari, > [snip] > > Also, I'm concerned about the delay introduced by such a separation and > that it may have impacts on potential deployments. Some operator folks > (e.g., Jean-Michel if I remember correctly) Yes. I confirm this fact. The two main reasons were: 1. The HAs are owned by an operator and so it is natural this ones decides finally which HA will be provided to a MN. 2. A HA is a point of failure for IPv6 mobility protocols (eg. MIPv6, NEMO) and, from a security point of view, I don't like the idea to have the list of all the HAs owned by an operator easily accessible just with a DNS request. Best regards. JMC. > requested a HA assignment > mechanism for the split scenario, and the anycast IKE mechanism is > currently the only mechanism providing this. > > So in conclusion, I also prefer to keep it in the document. > > A compromise could be to keep the mechanism in the draft and at the same > time pursue a general anycast-based IKEv2 extension in another WG. When > the general IKEv2 anycast extension will be completed and standardized, > the MIPv6-specific mechanism in the split scenario draft can still be > removed (in a bis-version). > > Kilian > > [snip] _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 26 12:50: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 1I3EEt-0003df-Cb; Tue, 26 Jun 2007 12:50:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3EEr-0003da-Ss for mip6@ietf.org; Tue, 26 Jun 2007 12:50:01 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3EEq-0008Ab-Sx for mip6@ietf.org; Tue, 26 Jun 2007 12:50:01 -0400 Message-ID: <0a8e01c7b811$f95b8d30$576115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Kilian Weniger" , "Jari Arkko" , References: <4680D95F.10403@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de> Subject: Re: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature Date: Tue, 26 Jun 2007 09:49:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29 Cc: Mobile IPv6 Mailing List , Sam Hartman , Brian E Carpenter 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 While I don't feel strongly about most of the points made below (though I don't agree), there is an implication here that not having the anycast feature would somehow delay deployment of the bootstrapping solution described in this draft. Let's be pretty clear about this: the probability of this draft being implemented and deployed is effectively zero right now as far as I know. Neither of the 3G's or Wimax Forum have included this in their next generation architecture and, as we all know, what these groups specify in their architecture is what gets deployed. So I don't agree that this is an argument for keeping anycast in the draft. That said, I would really like to get this draft finished and I don't believe, given the slim chances for deployment, that it really makes much difference at this point if anycast is there or not. This is likely to be another one of those RFCs that languishes with little or no implementation and deployment, until with a good deal of luck, some set of favorable technical and business circumstances develop causing interest to perk up (example: the FCC agrees to Frontline's request for a 700 MHz allocation for general and public saftey use resulting in a new business model for wireless outside of the traditional cellular carriers). I agree with Sam's argument that it makes sense to separate anycast/IKEv2 out as a general feature, get a draft going on that, then do an update on this document that describes how to use anycast for bootstrapping. Unlike the other "extensions" of IPsec/IKE that the WG specified, this particular one involves fundamental changes in the basic key agreement protocol, and if there is some kind of subtle bug, it could result in an attacker being able to spoof a victim into establishing a security association. Cases like this where there are multiple parties and lots of stuff going on are often difficult to reason about. In summary, having anycast/IKEv2 in as a feature isn't critical at this time, I think we ought to wait and make sure it is done right, then update bootstrapping to include it. jak ----- Original Message ----- From: "Kilian Weniger" To: "Jari Arkko" ; Cc: "Mobile IPv6 Mailing List" ; "Sam Hartman" ; "Brian E Carpenter" Sent: Tuesday, June 26, 2007 7:05 AM Subject: RE: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature Hi Jari, As Vijay said, Brian's comment about wrong use of "anycast" is a misunderstanding due to unclear wording in the draft. It was the intention that multiple node (i.e., typcially all HAs) have the anycast address assigned and that *any* one of those (i.e., the one that receive the IKE_SA_INIT request) forward it to the "best" HA. The text in section 5.2.1 should be modified accordingly. This should resolve Brian's main concern. Regarding the proposal to separate the anycast assignment from the draft: The MIPv6 WG has already extended IKEv2 in various ways even in the same draft, e.g., the MIP6_HOME_PREFIX attribute in the CFG_REQUEST message or the "USE_ASSIGNED_HoA" Notify Payload for address assignment in draft-ietf-mip6-bootstrapping-split. I don't understand why the anycast mechanism should be handled differently (i.e., separated from the draft) than the other IKEv2 extensions. Also, I'm concerned about the delay introduced by such a separation and that it may have impacts on potential deployments. Some operator folks (e.g., Jean-Michel if I remember correctly) requested a HA assignment mechanism for the split scenario, and the anycast IKE mechanism is currently the only mechanism providing this. So in conclusion, I also prefer to keep it in the document. A compromise could be to keep the mechanism in the draft and at the same time pursue a general anycast-based IKEv2 extension in another WG. When the general IKEv2 anycast extension will be completed and standardized, the MIPv6-specific mechanism in the split scenario draft can still be removed (in a bis-version). Kilian > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Dienstag, 26. Juni 2007 11:16 > To: draft-ietf-mip6-bootstrapping-split@tools.ietf.org > Cc: Mobile IPv6 Mailing List; Sam Hartman; Brian E Carpenter > Subject: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature > > Authors, WG, > > IETF last call and IESG review produced a number of > comments relating to the selection of a home agent > via anycast. See in particular Sam Hartman's Discuss > and Brian Carpenter's comments. > > There a number of ways in which we could address > these issues. What I would like to try is to separate > the anycast functionality from this draft and pursue > it as a general IKEv2 extension for any application. > The mip6 document would then advance immediately. > Would this be a good way forward? Comments > appreciated. > > Here are the comments from the IESG: > > *Lars Eggert:* > > *Comment:* > > *[2007-06-20]* For all the different components of the > solution, the > > document > > discusses a number of design options before describing > the recommended > > solution. I find this confusing. It would be much cleaner > if there was > > a normative section that talked about what is recommended, and an > > informative section (or appendix) that would discuss > options that are > > not part of the recommended set. > > > > INTRODUCTION, paragraph 13: > > > 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. > > > > I'm a bit confused by this. Title says this is for "split > scenario" > > bootstrapping. Abstract then says it's therefore > generally applicable > > for any bootstrapping scenario? (Also, it'd be good if > the abstract > > could define the words "split scenario" from the title > somewhere, so > > that folks not familiar with the term understand what it means.) > > > > > > Section 5.1., paragraph 1: > > > As > > > mentioned before in the document, the only information > that needs to > > > be pre-configured on the Mobile Node is the domain name of the > > > Mobility Service Provider. > > > > This paragraph says "need only domain name." Next > paragraph says "MN > > is configured with DNS server." So apparently MN needs to > be configure > > with at least two pieces of information? > > > > *Sam Hartman:* > > *Discuss:* > > *[2007-06-21]* A question to the aps folks: Doesn't the > first label of > > aSRV > > registration need to be a well known port or at least get taken from > > the same namespace? If so, has mip6 been registered there? > Also, is > > ipv6 an acceptable second label for the srv record? > > > > I'm concerned that the anycast behavior modifies IKEV2. I > don't think > > it is appropriate for MIP6 to be extending or modifying IKE in MIP6 > > applications. Wouldn't it be better to run that extension by the > > IPsec community and make it available generally? > > > > *Russ Housley:* > > *Discuss:* > > *[2007-06-20]* > > Significant comments were included in the Gen-ART review from > > Brian Carpenter. These need to be handled as any other Last > > Call comments. (Note: Last Call is not concluded yet.) > > > > *Tim Polk:* > > *Discuss:* > > *[2007-06-20]* This document is underspecified with respect to > > certificate processing and retrieval and CRL > > checking. The document refers to CRL checking, but Figure 3 and the > > accompanying text > > seem to imply online status checking. Without additional > details, it > > seems unlikely interoperable > > implementations could be developed. > And from Brian Carpenter's last call comments: > > > > ...The Mobile Node sends the IKE_SA_INIT request to the > > > anycast address. The node which has the anycast > address assigned to > > > one of its network interfaces... > > > > That is not IPv6 anycast. The definition of IPv6 anycast > addresses is > > quite clear (RFC 4291): > > > > Anycast: An identifier for a set of interfaces (typically > > belonging to different nodes). A packet sent to an > > anycast address is delivered to one of the interfaces > > identified by that address (the "nearest" > one, according > > to the routing protocols' measure of distance). > > > > In other words, an anycast HA implementation would assign > > the anycast address to *all* the HAs and the first one to > > respond would "win". > > > > What is described in the current draft is a perfectly reasonable > > redirect mechanism for load sharing (albeit with a single point > > of failure) but it is *not* IPv6 anycast. It would be anycast > > if *any* of the HAs could respond with the redirect. > > > > Either the design should be modified to do this, or the word > > "anycast" should be dropped from the description. > > > > I don't know IKEv2 well enough to find fault with the cookie > > mechanism for implementing a secure redirect. Even though > > it's a bit of a hack, it seems to work. I note that RFC 4306 > > does not use the term '"under attack" cookie'. > > > > ... > > > The use of anycast address as specified above requires the > > > implementation of anycast forwarding in such a way > that the Home > > > Agent can distinguish between an IKE_SA_INIT forwarded > through an > > > anycast address and one sent directly from the Mobile > Node. One > > > possible mechanism is to use IP-in-ip tunneling for > forwarding the > > > IKE_SA_INIT. In this case, the Home Agent can > identify a forwarded > > > IKE_SA_INIT based on the incoming interface or based on the > > > additional IP header. Other mechanisms may be used. > > > > This is underspecified and will make it impossible to deploy > > heterogeneous HAs together. > > > > ... > > > A mobile node's security associations with its home > agent may expire > > > while it still has a valid binding cache entry at the the home > > agent. > > > In this case, the mobile node MUST NOT use an anycast > address as the > > > destination address in the IKE_SA_INIT exchange to setup new > > security > > > associations. It MUST try to setup security > associations with its > > > existing home agent. > > > > By definition, the MN doesn't know that a given address is > an anycast > > address, since anycast addresses are syntactically > indistinguishable. > > I think you mean: if the MN obtained its HA address via the "under > > attack" > > cookie exchange, it MUST continue to use that address and not revert > > to the address it got from DNS. > > > > > 5.3.2. Home Address auto-configuration by the Mobile Node > > ... > > > For this reason the Mobile Node needs to obtain the home link > > > prefixes through the IKEv2 exchange. In the > Configuration Payload > > > during the IKE_AUTH exchange, the Mobile Node includes the > > > MIP6_HOME_PREFIX attribute in the CFG_REQUEST message. > The Home > > > Agent, when it processes this message, should include in the > > > CFG_REPLY payload prefix information for one prefix on the home > > link. > > > > It seems that 'should' should be a MUST. I don't see any alternative > > case. > > > > > 5.4. Authorization and Authentication with MSA > > ... > > > The definition of this backend communication is out of > the scope of > > > this document. In [16] a list of goals for such a > communication is > > > provided. > > ... > > > 6. Home Address registration in the DNS > > ... > > > ...The > > > detailed description of the communication between Home > Agent and AAA > > > is out of the scope of this document. More details > are provided in > > > [16]. > > > > I see a significant dependency here. I don't see how interoperable > > implementations can be made while these issues are undefined. If > > these issues are left open, there is a high risk of MSA/MSP interop > > depending on interim or proprietary choices. I don't get this, since > > the whole point of an MSA/MSP split is presumably to avoid > > walled garden deployments. Since [16] is Informative, there is > > nothing at present to prevent this. > > > > > 9.2. Home Address Assignment through IKEv2 > > ... > > > RFC 3775 [1] requires that a Home Agent check > authorization of a > > home > > > address received during a Binding Update. Therefore, > the home agent > > > MUST authorize each home address allocation and use. This > > > authorization is based on linking the mobile node > identity used in > > > the IKEv2 authentication process and the home address. > Home agents > > > MUST support at least the following two modes of authorization: > > > > > > o Configured home address(es) for each mobile node. > In this mode, > > > the home agent or infrastructure nodes behind it know what > > > addresses a specific mobile node is authorized to use. The > > mobile > > > node is allowed to request these addresses, or if > the mobile node > > > requests any home address, these addresses are > returned to it. > > > > > > o First-come-first-served (FCFS). In this mode, the > home agent > > > maintains a pool of "used" addresses, and allows > mobile nodes to > > > request any address, as long as it is not used by > another mobile > > > node. > > > > It isn't obvious why both are needed, but in any case the document > > should specify whether these are MUST implement or MUST deploy. > > > > > 9.5. Dynamic DNS Update > > > > > > If a Home Agent performs dynamic DNS update on behalf > of the Mobile > > > Node directly with the DNS server, the Home Agent MUST have a > > > security association of some type with the DNS server. > The security > > > association MAY be established either using DNSSEC > [18] or TSIG/TKEY > > > [19][20]. A security association is required even if > the DNS server > > > is in the same administrative domain as the Home Agent. The > > security > > > association SHOULD be separate from the security > associations used > > > for other purposes, such as AAA. > > > > Should 'required' be 'REQUIRED'? > > > > Since use of dynamic DNS is optional, is this a > > 'MUST implement' security requirement? > > > > ... > > > In the case where the Mobility Service Provider is > different from > > the > > > Mobility Service Authorizer, the network > administrators may want to > > > limit the number of cross-administrative domain security > > > associations. If the Mobile Node's FQDN is in the > Mobility Service > > > Authorizer's domain, since a security association for > AAA signaling > > > involved in mobility service authorization is required > in any case, > > > the Home Agent can send the Mobile Node's FQDN to the > AAA server > > > under the HA-AAA server security association, and the > AAA server can > > > perform the update. In that case, a security association is > > required > > > between the AAA server and DNS server for the dynamic > DNS update. > > > See [16] for a deeper discussion of the Home Agent to > AAA server > > > interface. > > > > Again, is this 'MUST implement'? If so, it increases my > concern about > > [16] being non-normative (and again two paragraphs below). > > > > > Regardless of whether the AAA server or Home Agent performs DNS > > > update, the authorization of the Mobile Node to update a FQDN > > MUST be > > > checked prior to the performance of the update. It is an > > > implementation issue as to how authorization is determined. > > > > Again, worrisome in terms of an MN implementer knowing > > what to implement. We don't want MNs that only work with certain > > types of HA/MSA/MSP setups. > > > > Editorial: > > ---------- > > > > (these are typos that are actually technical errors) > > > > > 3. Split scenario > > ... > > > ... the Mobile Node potentially requires a certificate > > > revocation list check (CTL check) > > > > s/CTL/CRL/ > > > > > 5.1. Home Agent Address Discovery > > ... > > > The Mobile Node needs to obtain the IP address of the > DNS server > > > before it can send a DNS request. > > > > s/the DNS server/a DNS server/ > > > > > 5.1.1. DNS lookup by Home Agent Name > > ... > > > Note that the configuration of a fixed home agent FQDN > does allow > > > dynamic assignment of a localized home agent. > > > > s/does/does not/ > > > > > 5.2. IPsec Security Associations setup > > ... > > > ... This is > > > needed because the Mobile Node has to provide it is > the owner of the > > > FQDN provided in the subsequent DNS Update Option. > > > > s/provide/prove/ > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 26 13:51:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3FC9-0003xi-QY; Tue, 26 Jun 2007 13:51:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3FC9-0003xd-4e for mip6@ietf.org; Tue, 26 Jun 2007 13:51:17 -0400 Received: from an-out-0708.google.com ([209.85.132.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3FBb-0000S2-5F for mip6@ietf.org; Tue, 26 Jun 2007 13:51:17 -0400 Received: by an-out-0708.google.com with SMTP id c17so435896anc for ; Tue, 26 Jun 2007 10:50:42 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aVQsfgYmSwIhed/klOJYH8A+fZkm1kJvYa4ettVP+UZHFLctiF77beWKHfdhirhX6+WcFouUclajjtogW/dnXvvoalRuertHVmmi3Hw1XSY21eD43Ouyk8AtzmQkinoj1kl8BnEQXD4AZrNbplAzpM4kBV014KDcGIIQzgs0kd0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oExBE2cZ/+33Gwk70tNbV+D01Y/IH/FCWuwAIDqkkqTT6Xc6Zdwt7xd5/cJw0YhLHBfT72kZe3cPo6nf3eoyolG2VyNmEKfKwGqTAefBjYwU3qdLfp9dCehFdBOmvBy0q/ES078wBbJ7NFdAjeBN88RBqXkBcEc2mn8H7OzTrNE= Received: by 10.100.106.5 with SMTP id e5mr4003938anc.1182880242162; Tue, 26 Jun 2007 10:50:42 -0700 (PDT) Received: by 10.100.135.16 with HTTP; Tue, 26 Jun 2007 10:50:42 -0700 (PDT) Message-ID: <729b68be0706261050i54cde09fv35ebbeb8c78c427d@mail.gmail.com> Date: Tue, 26 Jun 2007 19:50:42 +0200 From: "Jean-Michel Combes" To: "Vijay Devarapalli" Subject: Re: [Mip6] Deprecating Routing Header Type 0 In-Reply-To: <4675751F.9000608@azairenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4675751F.9000608@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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, it seems that the issue is solved (from the new pre-version of the draft): "Firewall policy intended to protect against packets containing RH0 MUST NOT simply filter all traffic with a routing header; it must be possible to disable forwarding of type 0 traffic without blocking other types of routing headers. In addition, the default configuration MUST permit forwarding of traffic using a RH other than 0." Source: http://www1.ietf.org/mail-archive/web/ipv6/current/msg07849.html Best regards. JMC. 2007/6/17, Vijay Devarapalli : > Hello folks, > > There is a discussion going on in the IPv6 WG about deprecating > the use of Routing Header Type 0. See the following URL for the > discussion on this topic. > > http://www1.ietf.org/mail-archive/web/ipv6/current/msg07634.html > > For more information on security threats due to Routing Header > Type 0, see http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf. > It is an interesting read. > > Some folks are suggesting "knee-jerk" reactions of blocking all > messages with a routing header in them. This would of course > break MIPv6. MIPv6 uses Router Header Type 2. It would be > especially bad if the firewalls start blocking them instead of > the hosts or the routers that receive such messages. > > Comments? > > Vijay > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 26 14:22: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 1I3Ffw-0000Mw-OM; Tue, 26 Jun 2007 14:22:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Ffu-0000MU-M9 for mip6@ietf.org; Tue, 26 Jun 2007 14:22:02 -0400 Received: from s-utl02-atpop.stsn.net ([72.254.128.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3Ffj-0004zo-Nd for mip6@ietf.org; Tue, 26 Jun 2007 14:22:02 -0400 Received: from s-utl02-atpop.stsn.net ([127.0.0.1]) by s-utl02-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007062614213002062 ; Tue, 26 Jun 2007 14:21:30 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.257,BAYES_00: -1.665 X-Spam-Level: Received: from [127.0.0.1] ([10.86.122.70]) by s-utl02-atpop.stsn.net; Tue, 26 Jun 2007 14:21:28 -0400 Message-ID: <4681590C.6010904@azairenet.com> Date: Tue, 26 Jun 2007 11:21:00 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature References: <4680D95F.10403@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de> <0a8e01c7b811$f95b8d30$576115ac@dcml.docomolabsusa.com> In-Reply-To: <0a8e01c7b811$f95b8d30$576115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org, Mobile IPv6 Mailing List , Kilian Weniger , Sam Hartman , Brian E Carpenter 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 James Kempf wrote: > Let's be pretty clear about this: the probability of this draft being > implemented and deployed is effectively zero right now as far as I know. > Neither of the 3G's or Wimax Forum have included this in their next > generation architecture and, as we all know, what these groups specify > in their architecture is what gets deployed. I believe 3GPP2 is moving towards using IPsec with Mobile IPv6. Anybody knows better? If/when this happens, configuring a home address is going to be through IKEv2. Regarding 3GPP, I am attending the 3GPP SA2 meeting this week in Orlando. There is one contribution, advocating the use of DNS to discovery a Mobile IPv6 home agent, that is being handled in this meeting. We may know at the end of this week how 3GPP is going bootstrap a Mobile IPv6 home agent. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 26 14:44: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 1I3G1g-0006Kr-6X; Tue, 26 Jun 2007 14:44:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3G1e-0006Kl-Gs for mip6@ietf.org; Tue, 26 Jun 2007 14:44:30 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3G14-0000Hn-Gv for mip6@ietf.org; Tue, 26 Jun 2007 14:44:30 -0400 Message-ID: <0b0301c7b821$f1cec540$576115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Vijay Devarapalli" References: <4680D95F.10403@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de> <0a8e01c7b811$f95b8d30$576115ac@dcml.docomolabsusa.com> <4681590C.6010904@azairenet.com> Subject: Re: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature Date: Tue, 26 Jun 2007 11:43:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org, Mobile IPv6 Mailing List , Kilian Weniger , Sam Hartman , Brian E Carpenter 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 believe 3GPP2 is moving towards using IPsec with Mobile IPv6. Anybody knows better? If/when this happens, configuring a home address is going to be through IKEv2. jak>> Just because they use IKEv2 doesn't mean they'll use split bootstrapping. I think they already have provision in their architecture for the integrated scenerio (some kind of DHCP hack) in fact, if I recall correctly, they specifically asked IETF to standardize the integrated scenerio, through not through a formal liason. At least, at the time the design team concluded, 3GPP2's interest was the justification for doing the integrated scenerio. Regarding 3GPP, I am attending the 3GPP SA2 meeting this week in Orlando. There is one contribution, advocating the use of DNS to discovery a Mobile IPv6 home agent, that is being handled in this meeting. We may know at the end of this week how 3GPP is going bootstrap a Mobile IPv6 home agent. jak>> Hmm. From my perhaps now out of date knowledge of the LTE architecture, SA2 has been slowly whittled away at any relevence of MIP6 for LTE until it would only be on S2a and S2b, between WLAN or other non3GPP network and 3GPP networks. I think the option of using Mobile IP has already been there since R99 in a somewhat different form, but nobody deployed it. jak>> My point isn't that split bootstrapping will never get deployed, my point is that given the rather tenuous interest exhibited by the 3Gs and Wimax Forum at this time (which I don't see your note contradicting), there is not any real need to put a feature in that looks, with some justification in my opinion, to require some extra thought. I think the bootstrapping draft without anycast/IKE is sufficient until such time as anycast/IKE has been thoroughly examined and found OK. Certainly, split bootstrapping becomes much more functional and interesting with anycast/IKE, but I think it can be added later. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 26 15:01: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 1I3GIO-0005FW-PK; Tue, 26 Jun 2007 15:01:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3GIN-0005FQ-MA for mip6@ietf.org; Tue, 26 Jun 2007 15:01:47 -0400 Received: from s-utl02-atpop.stsn.net ([72.254.128.202]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I3GIN-0000KT-Ew for mip6@ietf.org; Tue, 26 Jun 2007 15:01:47 -0400 Received: from s-utl02-atpop.stsn.net ([127.0.0.1]) by s-utl02-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007062615011302188 ; Tue, 26 Jun 2007 15:01:13 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: -0.666,BAYES_00: -1.665, LOCAL_OBFU_GENERIC: 1.8 X-Spam-Level: Received: from [127.0.0.1] ([10.86.122.70]) by s-utl02-atpop.stsn.net; Tue, 26 Jun 2007 15:01:09 -0400 Message-ID: <46816254.1020306@azairenet.com> Date: Tue, 26 Jun 2007 12:00:36 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature References: <4680D95F.10403@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de> <0a8e01c7b811$f95b8d30$576115ac@dcml.docomolabsusa.com> <4681590C.6010904@azairenet.com> <0b0301c7b821$f1cec540$576115ac@dcml.docomolabsusa.com> In-Reply-To: <0b0301c7b821$f1cec540$576115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 (I trimmed the cc list) Irrespective of which SDO adopts this mechanism, we still need a generic mechanism to discover a MIPv6 home agent. And we need a mechanism that works independent of any access network. DNS-based HA discovery fulfills that. James Kempf wrote: > I believe 3GPP2 is moving towards using IPsec with Mobile IPv6. > Anybody knows better? If/when this happens, configuring a home > address is going to be through IKEv2. > > jak>> Just because they use IKEv2 doesn't mean they'll use split > bootstrapping. I think they already have provision in their architecture > for the integrated scenerio (some kind of DHCP hack) in fact, if I > recall correctly, they specifically asked IETF to standardize the > integrated scenerio, through not through a formal liason. At least, at > the time the design team concluded, 3GPP2's interest was the > justification for doing the integrated scenerio. Note that draft-ietf-mip6-bootstrapping-integrated has a normative dependency to the split scenario solution document to setup IPsec security associations. > jak>> My point isn't that split bootstrapping will never get deployed, > my point is that given the rather tenuous interest exhibited by the 3Gs > and Wimax Forum at this time (which I don't see your note > contradicting), there is not any real need to put a feature in that > looks, with some justification in my opinion, to require some extra > thought. I think the bootstrapping draft without anycast/IKE is > sufficient until such time as anycast/IKE has been thoroughly examined > and found OK. Certainly, split bootstrapping becomes much more > functional and interesting with anycast/IKE, but I think it can be added > later. Ok. I do agree that the IKEv2 anycast method is not required for split scenario bootstrapping to work. The main advantage is that it brings together anycast-based load balancing with DNS-based solution. Many folks were concerned that DNS-based mechanism only allows a "discovery of home agent", not "assignment of a home agent". Assignment is now possible with the anycast approach. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 26 15:22: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 1I3Gcm-0007RC-4w; Tue, 26 Jun 2007 15:22:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Gck-0007R4-BO for mip6@ietf.org; Tue, 26 Jun 2007 15:22:50 -0400 Received: from vms044pub.verizon.net ([206.46.252.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3GcW-0001mP-5R for mip6@ietf.org; Tue, 26 Jun 2007 15:22:50 -0400 Received: from vms229.mailsrvcs.net ([192.168.1.2]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JK900DTACHJ6NS0@vms044.mailsrvcs.net> for mip6@ietf.org; Tue, 26 Jun 2007 14:22:31 -0500 (CDT) Received: from 129.55.200.20 ([129.55.200.20]) by vms229.mailsrvcs.net (Verizon Webmail) with HTTP; Tue, 26 Jun 2007 14:22:30 -0500 (CDT) Date: Tue, 26 Jun 2007 14:22:30 -0500 (CDT) From: Tim Enos Subject: Re: [Mip6] Deprecating Routing Header Type 0 X-Originating-IP: [129.55.200.20] To: Vijay Devarapalli , Jean-Michel Combes Message-id: <17262567.23687431182885751273.JavaMail.root@vms229.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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 Hello all, This is a good discussion to have. As there was much overlap between the first two listed drafts: http://ietf.org/internet-drafts/draft-savola-ipv6-rtheader-00.txt http://ietf.org/internet-drafts/draft-jabley-ipv6-rh0-is-evil-00.txt A combined effort was begun, the most recently published version thereof being the following: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-rh0-00.txt AFAIK, in no case in any of the above linked documents (or elsewhere for that matter) do any of the draft authors advocate/suggest blocking all packets containing any routing header. Even though the draft is merely focusing on RH0 deprecation (and not firewall policy per se), the text of section 4.2 below should be clear. Quoting directly from -ietf-ipv6-deprecate-rh0-00: "4.2. Packet Filtering Firewall policy intended to protect against packets containing RH0 should be constructed such that routing headers of other types (which may well have legitimate and benign applications) are handled on their own merits. For example, discarding all packets with any type of routing header simply as a reaction to the problems with RH0 is inappropriate, and may hamper future functionality designed using non-type 0 routing headers. For example, Mobile IPv6 uses the type 2 Routing Header [RFC3775]. Where filtering capabilities do not facilitate matching specific types of Routing Headers, filtering based on the presence of any Routing Headers on IPv6 routers, regardless of type, is strongly discouraged." It can be seen that the above imprecation remains in the current draft revision candidate (as clearly pointed out by Jean-Michel). Hope this helps, Best Regards, Tim Enos Rom 8:28 >Hi, > >it seems that the issue is solved (from the new pre-version of the draft): >"Firewall policy intended to protect against packets containing RH0 >MUST NOT simply filter all traffic with a routing header; it must be >possible to disable forwarding of type 0 traffic without blocking >other types of routing headers. In addition, the default configuration >MUST permit forwarding of traffic using a RH other than 0." >Source: http://www1.ietf.org/mail-archive/web/ipv6/current/msg07849.html > >Best regards. > >JMC. > >2007/6/17, Vijay Devarapalli : >> Hello folks, >> >> There is a discussion going on in the IPv6 WG about deprecating >> the use of Routing Header Type 0. See the following URL for the >> discussion on this topic. >> >> http://www1.ietf.org/mail-archive/web/ipv6/current/msg07634.html >> >> For more information on security threats due to Routing Header >> Type 0, see http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf. >> It is an interesting read. >> >> Some folks are suggesting "knee-jerk" reactions of blocking all >> messages with a routing header in them. This would of course >> break MIPv6. MIPv6 uses Router Header Type 2. It would be >> especially bad if the firewalls start blocking them instead of >> the hosts or the routers that receive such messages. >> >> Comments? >> >> Vijay >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 26 15:30: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 1I3Gjf-0008HV-Mg; Tue, 26 Jun 2007 15:29:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Gje-0008Ct-Ls for mip6@ietf.org; Tue, 26 Jun 2007 15:29:58 -0400 Received: from s-utl01-atpop.stsn.net ([72.254.128.201]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I3Gje-0003Rh-Bt for mip6@ietf.org; Tue, 26 Jun 2007 15:29:58 -0400 Received: from s-utl01-atpop.stsn.net ([127.0.0.1]) by s-utl01-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007062615291426857 ; Tue, 26 Jun 2007 15:29:14 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.029,BAYES_00: -1.665 X-Spam-Level: Received: from [127.0.0.1] ([10.86.122.70]) by s-utl01-atpop.stsn.net; Tue, 26 Jun 2007 15:29:10 -0400 Message-ID: <468168E9.1020402@azairenet.com> Date: Tue, 26 Jun 2007 12:28:41 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Tim Enos Subject: Re: [Mip6] Deprecating Routing Header Type 0 References: <17262567.23687431182885751273.JavaMail.root@vms229.mailsrvcs.net> In-Reply-To: <17262567.23687431182885751273.JavaMail.root@vms229.mailsrvcs.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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 Tim Enos wrote: > Hello all, > > This is a good discussion to have. > > As there was much overlap between the first two listed drafts: > > http://ietf.org/internet-drafts/draft-savola-ipv6-rtheader-00.txt > > http://ietf.org/internet-drafts/draft-jabley-ipv6-rh0-is-evil-00.txt > > A combined effort was begun, the most recently published version thereof being the following: > > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-rh0-00.txt > > AFAIK, in no case in any of the above linked documents (or elsewhere for that matter) do any of the draft authors advocate/suggest blocking all packets containing any routing header. True. But there were other emails on the IPv6 mailing list which said block all, then enable for each application. I would like "block RH0, allow all other", at least as far as IETF specification goes. In practice, it could be different and not in our control. Regarding the draft, I was looking for much stronger language about firewalls not blocking all messages with a routing header. The new version has this stronger language. Vijay > > Even though the draft is merely focusing on RH0 deprecation (and not firewall policy per se), the text of section 4.2 below should be clear. > > Quoting directly from -ietf-ipv6-deprecate-rh0-00: > > "4.2. Packet Filtering > > Firewall policy intended to protect against packets containing RH0 should be constructed such that routing headers of other types (which may well have legitimate and benign applications) are handled on their own merits. For example, discarding all packets with any type of routing header simply as a reaction to the problems with RH0 is inappropriate, and may hamper future functionality designed using non-type 0 routing headers. For example, Mobile IPv6 uses the type 2 > Routing Header [RFC3775]. > > Where filtering capabilities do not facilitate matching specific types of Routing Headers, filtering based on the presence of any Routing Headers on IPv6 routers, regardless of type, is strongly discouraged." > > It can be seen that the above imprecation remains in the current draft revision candidate (as clearly pointed out by Jean-Michel). > > Hope this helps, > > Best Regards, > > Tim Enos > Rom 8:28 > > >> Hi, >> >> it seems that the issue is solved (from the new pre-version of the draft): >> "Firewall policy intended to protect against packets containing RH0 >> MUST NOT simply filter all traffic with a routing header; it must be >> possible to disable forwarding of type 0 traffic without blocking >> other types of routing headers. In addition, the default configuration >> MUST permit forwarding of traffic using a RH other than 0." >> Source: http://www1.ietf.org/mail-archive/web/ipv6/current/msg07849.html >> >> Best regards. >> >> JMC. >> >> 2007/6/17, Vijay Devarapalli : >>> Hello folks, >>> >>> There is a discussion going on in the IPv6 WG about deprecating >>> the use of Routing Header Type 0. See the following URL for the >>> discussion on this topic. >>> >>> http://www1.ietf.org/mail-archive/web/ipv6/current/msg07634.html >>> >>> For more information on security threats due to Routing Header >>> Type 0, see http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf. >>> It is an interesting read. >>> >>> Some folks are suggesting "knee-jerk" reactions of blocking all >>> messages with a routing header in them. This would of course >>> break MIPv6. MIPv6 uses Router Header Type 2. It would be >>> especially bad if the firewalls start blocking them instead of >>> the hosts or the routers that receive such messages. >>> >>> Comments? >>> >>> Vijay >>> >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >>> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 26 15:30: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 1I3Gk8-00019A-9o; Tue, 26 Jun 2007 15:30:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Gk6-00011c-Be for mip6@ietf.org; Tue, 26 Jun 2007 15:30:26 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3Gk5-0003RL-Vv for mip6@ietf.org; Tue, 26 Jun 2007 15:30:26 -0400 Message-ID: <0b1801c7b828$4fb40930$576115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Vijay Devarapalli" References: <4680D95F.10403@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de> <0a8e01c7b811$f95b8d30$576115ac@dcml.docomolabsusa.com> <4681590C.6010904@azairenet.com> <0b0301c7b821$f1cec540$576115ac@dcml.docomolabsusa.com> <46816254.1020306@azairenet.com> Subject: Re: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature Date: Tue, 26 Jun 2007 12:29:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Irrespective of which SDO adopts this mechanism, we still need a generic mechanism to discover a MIPv6 home agent. And we need a mechanism that works independent of any access network. DNS-based HA discovery fulfills that. jak>> Agree. Ok. I do agree that the IKEv2 anycast method is not required for split scenario bootstrapping to work. The main advantage is that it brings together anycast-based load balancing with DNS-based solution. Many folks were concerned that DNS-based mechanism only allows a "discovery of home agent", not "assignment of a home agent". Assignment is now possible with the anycast approach. jak>> Agree also. But I believe Sam has raised some legitimate concerns, and I don't see any harm in taking some time to ensure that there are no suprises in anycast/IKEv2. jak>> How about this? - Split off anycast/IKEv2 and immediately put it into a draft for discussion in the right security forum. Sam can tell us what WG he thinks it should be sent to. If the draft gets written by July 2 (this coming Monday!) it might even be possible to start discussion in Chicago. - Split off bootstrapping on top of anycast/IKEv2 and immediately put it into an update WG draft for the MIP6 WG, with normative dependency on the anycast/IKEv2 draft. The anycast feature can advance separately from the base bootstrapping draft, until people are sufficiently comfortable with anycast/IKEv2. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 26 15:34: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 1I3GoP-00057M-DL; Tue, 26 Jun 2007 15:34:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3GoN-000579-O7 for mip6@ietf.org; Tue, 26 Jun 2007 15:34:51 -0400 Received: from s-utl01-atpop.stsn.net ([72.254.128.201]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I3GoN-0004GX-HC for mip6@ietf.org; Tue, 26 Jun 2007 15:34:51 -0400 Received: from s-utl01-atpop.stsn.net ([127.0.0.1]) by s-utl01-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007062615344926885 ; Tue, 26 Jun 2007 15:34:49 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: -0.873,BAYES_00: -1.665, LOCAL_OBFU_GENERIC: 1.8 X-Spam-Level: Received: from [127.0.0.1] ([10.86.122.70]) by s-utl01-atpop.stsn.net; Tue, 26 Jun 2007 15:34:46 -0400 Message-ID: <46816A07.50903@azairenet.com> Date: Tue, 26 Jun 2007 12:33:27 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature References: <4680D95F.10403@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de> <0a8e01c7b811$f95b8d30$576115ac@dcml.docomolabsusa.com> <4681590C.6010904@azairenet.com> <0b0301c7b821$f1cec540$576115ac@dcml.docomolabsusa.com> <46816254.1020306@azairenet.com> <0b1801c7b828$4fb40930$576115ac@dcml.docomolabsusa.com> In-Reply-To: <0b1801c7b828$4fb40930$576115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 James Kempf wrote: > Irrespective of which SDO adopts this mechanism, we still need a > generic mechanism to discover a MIPv6 home agent. And we need a > mechanism that works independent of any access network. DNS-based > HA discovery fulfills that. > > jak>> Agree. > > Ok. I do agree that the IKEv2 anycast method is not required for > split scenario bootstrapping to work. The main advantage is that > it brings together anycast-based load balancing with DNS-based > solution. Many folks were concerned that DNS-based mechanism only > allows a "discovery of home agent", not "assignment of a home agent". > Assignment is now possible with the anycast approach. > > jak>> Agree also. But I believe Sam has raised some legitimate concerns, > and I don't see any harm in taking some time to ensure that there are no > suprises in anycast/IKEv2. His concern was about MIPv6 WG not being chartered with extending IKEv2. Was there anything else? > jak>> How about this? > > - Split off anycast/IKEv2 and immediately put it into a draft for > discussion in the right security forum. Sam can tell us what WG he > thinks it should be sent to. If the draft gets written by July 2 (this > coming Monday!) it might even be possible to start discussion in Chicago. > > - Split off bootstrapping on top of anycast/IKEv2 and immediately put > it into an update WG draft for the MIP6 WG, with normative dependency on > the anycast/IKEv2 draft. > > The anycast feature can advance separately from the base bootstrapping > draft, until people are sufficiently comfortable with anycast/IKEv2. I don't have a problem with splitting the spec, but we really haven't see any significant issue yet. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 26 15:51: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 1I3H42-0004Gs-NP; Tue, 26 Jun 2007 15:51:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3H41-0004Gm-FY for mip6@ietf.org; Tue, 26 Jun 2007 15:51:01 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3H41-0005tE-3Z for mip6@ietf.org; Tue, 26 Jun 2007 15:51:01 -0400 Message-ID: <0b3601c7b82b$43257020$576115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Vijay Devarapalli" References: <4680D95F.10403@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de> <0a8e01c7b811$f95b8d30$576115ac@dcml.docomolabsusa.com> <4681590C.6010904@azairenet.com> <0b0301c7b821$f1cec540$576115ac@dcml.docomolabsusa.com> <46816254.1020306@azairenet.com> <0b1801c7b828$4fb40930$576115ac@dcml.docomolabsusa.com> <46816A07.50903@azairenet.com> Subject: Re: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature Date: Tue, 26 Jun 2007 12:50:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 > jak>> Agree also. But I believe Sam has raised some legitimate concerns, > and I don't see any harm in taking some time to ensure that there are no > suprises in anycast/IKEv2. His concern was about MIPv6 WG not being chartered with extending IKEv2. Was there anything else? jak>> Well then maybe it's my issue. My issue is that it makes sense to me to spend some additional time considering whether there are some subtle bugs in anycast/IKEv2. It is a major modification in how key exchange is done, and a subtle bug could result in an attacker able to spoof a victim into thinking trust is established and setting up a security association. Maybe I've been spending too much time lately with my head embedded in security protocols, but I really don't think we want to set ourselves up for a WEP Catastrophe. If I thought there was sufficient deployment pressure, I might be more inclined to push for including it in the document, but I just don't see any deployment pressure there. I don't have a problem with splitting the spec, but we really haven't see any significant issue yet. jak>> The point is that reasoning about protocols where there are multiple parties involved is difficult, and therefore I think it makes sense to spend time making sure the protocol is right. Maybe Sam had to couch his concern in some bureaucratese about the MIP6 group not doing IKEv2 enhancements, but his core point is still valid, in my opinion. Let's take some time to make sure it is right, publish it as a document that will benefit any protocol that wants to use it. Right now, it's hidden at the end of this very MIPv6 specific document. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mext-bounces@ietf.org Tue Jun 26 17:05:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3IEC-0003As-C0; Tue, 26 Jun 2007 17:05:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3HDE-0005Hq-LX; Tue, 26 Jun 2007 16:00:32 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3HDE-000743-6r; Tue, 26 Jun 2007 16:00:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D608A175CA; Tue, 26 Jun 2007 20:00:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I3HCj-0006C0-Ex; Tue, 26 Jun 2007 16:00:01 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Tue, 26 Jun 2007 16:00:01 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 X-Mailman-Approved-At: Tue, 26 Jun 2007 17:05:35 -0400 Cc: mext@ietf.org Subject: [MEXT] WG Review: Mobility EXTensions for IPv6 (mext) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by July 2. +++ Mobility EXTensions for IPv6 (MEXT) Chair(s): TBD Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: mext@ietf.org https://www1.ietf.org/mailman/listinfo/mext http://www1.ietf.org/mail-archive/web/mext/current/index.html Description of Working Group: Mobile IPv6 specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions. In addition, NEMO network mobility mechanisms built on top of Mobile IPv6 allow managing the mobility of an entire network, as it changes its point of attachment to the Internet. The base specifications consist of: o RFC 3775 o RFC 3963 o RFC 4877 The MEXT Working Group continues the work of the MIP6, NEMO, and MONAMI6 Working Groups. The primary goal of MEXT will be to (A) enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios. Additionally, (B) the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. (C) The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. Deployment considerations call for (A.1) solutions to enable dual-stack operation, (A.2) allowing the use of multiple interfaces in mobile nodes, (A.3) mechanisms to support high-availability home agents, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, (A.5) address the specific needs of automotive and aviation communities for route optimisation in network mobility, and (A.6) support for AAA is needed as a continuation of earlier work on bootstrapping. Work items related to large scale deployment include: (A.1) A Solution for MIP6 session continuity for dual stack hosts which attach to IPv4 access networks. Additionally provide a mechanism for carrying IPv4 packets via the Home agent for MIP6 capable dual-stack hosts. (A.2) A protocol based solution for enhancing the reliability of home agents and a method to force a host to switch home agents. A mechanism to force an MN to switch the HA that is currently serving it. This is required in deployments where the HA needs to be taken offline for maintenance. (A.3) Use of multiple interfaces. Today, the protocols do not provide suppport for simultaneous differentiated use of multiple access technologies. Several proposals exist for such support, and some of them have been implemented and tested. When a mobile host/router uses multiple network interfaces simultaneously, or when multiple prefixes are available on a single network interface, the mobile host/router would end up with multiple Care-of Addresses (CoAs). In addition, the Home Agent might be attached to multiple network interfaces, or to a single network interface with multiple prefixes, hence resulting in the option to use multiple IP addresses for the Home Agent. This could result in the possibility of using a multitude of bi-directional tunnels between pairs of {Home Agent address, CoA} and a number of associated issues: establishment, selection and modification of multiple simultaneous tunnels. The objective of the WG is to produce a clear problem statement and to produce standard track specifications to the problems associated with the simultaneous use of multiple addresses for either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support and their variants (FMIPv6, HMIPv6, etc). Where the effects of having multiple prefixes on a single interface is identical to the effects of having multiple interfaces each with a single prefix, the WG will consider a generalized approach to cater for multiple prefixes available to a mobile host/router. The WG uses existing tunneling mechanisms defined for Mobile IPv6. The involved nodes need to select which tunnel instance to use when multiple ones are available due to multiple addresses on either end. But the WG does not plan to define a new mechanism for this, but rather document how to use existing mechanisms based upon preferences or policies. In particular, the WG will consider that a tunnel is alive as long as packets can be exchanged with the corresponding peer. In addition, local information, such as interface up/down events, or other failure detection mechanisms can be used to quickly detect failure of tunnel(s). Deliverables related to this include - A document explaining the motivations for a node using multiple interfaces and the scenarios where it may end up with multiple global addresses on its interfaces [Informational] - An analysis document explaining what are the limitations for mobile hosts using multiple simultaneous Care-of Addresses and Home Agent addresses using Mobile IPv6, whether issues are specific to Mobile IPv6 or not [Informational]. - A protocol extension to support the registration of multiple Care-of Addresses at a given Home Agent address [Standard Track]. - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport [both Standard Track]. (A.4) Work on solutions to deal with firewalls and the problems that firewalls cause as identified in RFC 4487. (A.5) Route optimization of network mobility. Three use cases have been identified for this. These are called the Aviation case, the Automotive case, and the Personal Mobile Router (consumer electronics) case, though the actual technical problems are characterized by the type of movements and environments more than by the specific industry using the technology. The group will explore these cases to gather requirements and proceed with solving the open issues. (1) Airline and spacecraft community, who are deploying NEMO for control systems, as well as Internet connectivity and entertainment systems. This use case is characterized by fast (~ 1000 km/h) moving objects over large distances (across continents). The main technical problem is that tunneling-based solutions imply a roundtrip to another continent and that BGP based solutions imply significant churn in the global Internet routing table. (2) Automotive industry who are deploying NEMO for in-car communication, entertainment, and data gathering, possible control systems use, and communication to roadside devices. This use case is characterized by moderately fast (~ 100-300 km/h) moving objects that employ local or cellular networks for connectivity. (3) Personal Mobile Routers, which are consumer devices that allow the user to bring a NEMO network with the user while mobile, and communicate with peer NEMO Basic Support nodes and nodes served by them. After gathering the requirements for these types of deployments, the working group will evaluate what type of route optimization needs to be performed (if any), and formulate a solution to those problems. If no requirements for those scenarios can be collected by the deadline, it will be assumed that the work is premature, and that type of deployment will be dropped from the WG. The group will only consider airline and spacecraft solutions that combine tunneling solutions for small movements with either federated tunnel servers or slowly changing end host prefixes. The group will only consider personal mobile router requirements about optimized routes to another mobile router belonging to the same operator. The group will only consider automotive industry requirements to allow MR-attached hosts to directly access the network where MR has attached to. Work on automotive and personal mobile router solutions requires rechartering. The WG will not consider extensions to routing protocols. The group will not consider general multi-homing problems that are not related to the deployment and maintenance of Mobile IPv6 or NEMO Basic Support protocols. The group will also not consider general route optimization, or other problems that are not related to the deployment and maintenance of NEMO Basic Support protocols. Similarly, the group will not consider or rely on the results of general routing architecture, Internet architecture, or identifier-locator split issues that are discussed in separate, long term efforts elsewhere in the IETF. Finally, the group will not consider solutions that require changes from correspondent nodes in the general Internet (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG require AAA support for Mobile IPv6. Part of this work is already being done in the DIME WG, but the MEXT WG is chartered to complete a design for RADIUS. Work items related to base specification maintenance include: (B.1) Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. One specific area of concern that should be analyzed and addressed relates to multilink subnets. This work item relates only to corrections and clarifications. The working group shall not revisit design decisions or change the protocol. (B.2) Update the IANA considerations of RFC 3775 to allow extensions for experimental purposes as well passing of optional vendor-specific information. (B.3) Finish working group documents that are currently in process, and submit for RFC. This includes prefix delegation protocol mechanism for network mobility, and a MIB for NEMO Basic Support. Work items related to informational documentation include: (C.1) Produce a design rationale that documents the historical thinking behind the introduction of an alternative security mechanism, the Authentication Protocol (RFC 4285). Goals and Milestones: Aug 2007 Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments Aug 2007 Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments Aug 2007 Submit Multiple CoA Registration to IESG Sep 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational. Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard. Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard Oct 2007 Submit -00 draft on Route Optimization needs for Personal Mobile Router Nov 2007 Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational Nov 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational. Dec 2007 Submit -00 draft for solution to aircraft/spacecraft problem Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard. Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard Jan 2007 Submit final doc on Route Optimization Needs for Automobile and Highway Deployments, for Informational Jan 2007 Submit final doc on Route Optimization needs for Personal Mobile Router, for Informational Feb 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. Feb 2008 Determine how to proceed with remaining automotive/Personal Mobile Router solutions Mar 2008 Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard Mar 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Apr 2008 Submit Flow/binding policy format to IESG, for Proposed Standard Apr 2008 Submit Flow/binding policy transport to IESG, for Proposed Standard Apr 2007 Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard. May 2008 Submit final doc for solution to aircraft/spacecraft problem to the IESG, for Proposed Standard May 2008 Recharter to work on the remaining automotive/Personal Mobile Router solutions Jul 2007 Submit Multiple Interfaces Motivations and Scenario to IESG, for Informational Jul 2007 Submit Analysis of the use of Multiple Simultaneous Care-of Addresses and Home Agent addresses, for Informational Aug 2008 Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. Aug 2008 Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mip6-bounces@ietf.org Tue Jun 26 19:25: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 1I3KPO-0007XB-9c; Tue, 26 Jun 2007 19:25:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3KPN-0007X2-32 for mip6@ietf.org; Tue, 26 Jun 2007 19:25:17 -0400 Received: from vms046pub.verizon.net ([206.46.252.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3KOW-0006Kh-O3 for mip6@ietf.org; Tue, 26 Jun 2007 19:25:17 -0400 Received: from vms229.mailsrvcs.net ([192.168.1.2]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JK900G6TNOKR681@vms046.mailsrvcs.net> for mip6@ietf.org; Tue, 26 Jun 2007 18:24:20 -0500 (CDT) Received: from 129.55.200.20 ([129.55.200.20]) by vms229.mailsrvcs.net (Verizon Webmail) with HTTP; Tue, 26 Jun 2007 18:24:19 -0500 (CDT) Date: Tue, 26 Jun 2007 18:24:19 -0500 (CDT) From: Tim Enos Subject: Re: [Mip6] Deprecating Routing Header Type 0 X-Originating-IP: [129.55.200.20] To: Vijay Devarapalli , Tim Enos Message-id: <31722940.23785561182900260191.JavaMail.root@vms229.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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/all, > >True. But there were other emails on the IPv6 mailing list which >said block all, then enable for each application. Good point, and IMO such an approach would be a bit draconian. Given the ability to do so, filtering on RH type should be what people do. Even so, _my_ (main) focus is what the authors of the would-be spec are saying and writing. Given that, and what appears to be the majority viewpoint in the group, RH2 is safe. > I would like "block RH0, allow all other", at least as far as IETF specification goes. I am thinking that specifying firewall policy for the remaining RH types is probably beyond the scope of the draft. To my knowledge, the purpose of the draft was merely to deprecate RH0 and say why. That said, I'd not argue the point (here or elsewhere) and defer to group judgement. FWIW, IMO "block RH0, allow all other" is reasonable. Given an ability to filter per RH type, that would be one of 251 (2^n - 5) remaining possibilities, where: n=8 (number of bits in the Routing Type field), and the (-5) comes from adding: (-1) for a deprecated RH0 (-1) for Nimrod which is RH1 (-1) for MIPv6 which is RH2 (-1) for RFC3692-style Experiment 1 which is RH253 (-1) for RFC3692-style Experiment 2 which is RH254 I got the above from http://www.iana.org/assignments/ipv6-parameters > In practice, it could be different and not in our control. I would expect that to be true as well. There may well be some extant firewall implementations that lack the granularity to filter per RH type. The question at each such site then becomes one of "Shall we permit all RH types, or deny all of them?" Again, I don't think the answer to that question is best answered in the RH0 deprecation draft. Best Regards, Tim Rom 8:28 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 27 03:21: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 1I3Rph-0002kb-8r; Wed, 27 Jun 2007 03:20:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Rpf-0002iH-GT for mip6@ietf.org; Wed, 27 Jun 2007 03:20:55 -0400 Received: from cluster-j.mailcontrol.com ([86.111.223.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3RpW-0007yb-SR for mip6@ietf.org; Wed, 27 Jun 2007 03:20:55 -0400 Received: from rly16j.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly16j.srv.mailcontrol.com (MailControl) with ESMTP id l5R7KgaS000352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Jun 2007 08:20:42 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly16j.srv.mailcontrol.com (MailControl) id l5R7JpFr031785 for mip6@ietf.org; Wed, 27 Jun 2007 08:19:51 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly16j-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l5R7JoN7031742; Wed, 27 Jun 2007 08:19:51 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 4eca_27e5b536_247d_11dc_93b7_0030482aac25; Wed, 27 Jun 2007 09:08:07 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007062709194767-19823 ; Wed, 27 Jun 2007 09:19:47 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.148,BAYES_00: -1.665,TOTAL_SCORE: -1.517 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Wed, 27 Jun 2007 09:17:54 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: Re: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature In-Reply-To: <0b3601c7b82b$43257020$576115ac@dcml.docomolabsusa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature Thread-Index: Ace4K2f09cBTQgWnRWmciinnqMIG5QAVd9WQ References: <4680D95F.10403@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de><0a8e01c7b811$f95b8d30$576115ac@dcml.docomolabsusa.com><4681590C.6010904@azairenet.com><0b0301c7b821$f1cec540$576115ac@dcml.docomolabsusa.com><46816254.1020306@azairenet.com><0b1801c7b828$4fb40930$576115ac@dcml.docomolabsusa.com><46816A07.50903@azairenet.com> <0b3601c7b82b$43257020$576115ac@dcml.docomolabsusa.com> To: "Jari Arkko" , Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB2E9A9B@lan-ex-02.panasonic.de> Date: Wed, 27 Jun 2007 09:19: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-10 (www.mailcontrol.com) on 10.74.1.126 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Mobile IPv6 Mailing List , Sam Hartman , Brian E Carpenter 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'm not sure what exactly Sam meant with his comment, maybe he can clarify. He said: > I'm concerned that the anycast behavior modifies IKEV2. I don't think > it is appropriate for MIP6 to be extending or modifying IKE in MIP6 > applications. Wouldn't it be better to run that extension by the > IPsec community and make it available generally? Is it that he has concerns with MIP6 WG modifying/extending IKEv2 for MIPv6 applications in general or is it that he has security concerns specifically with the anycast extension? If it is the latter, I do understand the argument to split off the anycast IKEv2 extension (although it is difficult to evaluate a security concern if there is no information what exactly the threat/security issue might be). But if it is the former, I don't see a strong argument to split it off, since MIP6 WG modified or extended IKEv2 already many times. Fact is that the anycast extension is on the table since November 2005. It had consensus among the authors of the split scenario WG draft (incl. James ;), was discussed several times on the mailing list, went through WGLC, and now through IETF last call/IESG review. During all this time nobody raised a security issue with the solution in the draft AFAIK. Also, several MIP6 people (e.g., Vijay, Francis) discussed the anycast extension with IKEv2/IPsec experts from other WGs and no security concern was raised AFAIK.=20 Regarding the argument of broadening the applicability, I guess we can have the same argument for other IKEv2 extensions done in MIP6 WG. For instance, the MIP6_HOME_PREFIX attribute for HoA auto-configuration in draft-ietf-mip6-bootstrapping-split could also be useful for other applications than MIPv6 to allow stateless address autoconfiguration of a remote address, right? So why not split this off? I don't see why it should be different for the anycast extension.=20 And from the other IETF last call/IESG review comments there should not be any technical issue left with the anycast extension that would result in a delay of standardization of the split scenario bootstrapping mechanisms IMHO. In conclusion, if Sam has no security concerns specifically with the anycast extension, I still don't see why we should remove it from the draft.=20 BR, Kilian 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 Jun 27 04:17: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 1I3Sie-0002Rf-UA; Wed, 27 Jun 2007 04:17:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Sid-0002QK-48 for mip6@ietf.org; Wed, 27 Jun 2007 04:17:43 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Shv-0003WB-Nn for mip6@ietf.org; Wed, 27 Jun 2007 04:17:43 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2274F1986A6; Wed, 27 Jun 2007 11:16:59 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D9C73198691; Wed, 27 Jun 2007 11:16:58 +0300 (EEST) Message-ID: <46821CFA.5050106@piuha.net> Date: Wed, 27 Jun 2007 11:16:58 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Kilian Weniger Subject: Re: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature References: <4680D95F.10403@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de><0a8e01c7b811$f95b8d30$576115ac@dcml.docomolabsusa.com><4681590C.6010904@azairenet.com><0b0301c7b821$f1cec540$576115ac@dcml.docomolabsusa.com><46816254.1020306@azairenet.com><0b1801c7b828$4fb40930$576115ac@dcml.docomolabsusa.com><46816A07.50903@azairenet.com> <0b3601c7b82b$43257020$576115ac@dcml.docomolabsusa.com> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A9B@lan-ex-02.panasonic.de> In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB2E9A9B@lan-ex-02.panasonic.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org, Mobile IPv6 Mailing List , Sam Hartman , Brian E Carpenter 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 Kilian, A comment regarding the MIP6 WG role: > But if it is the former, I don't see a strong argument > to split it off, since MIP6 WG modified or extended IKEv2 already many > times. > MIP6 WG has been chartered to work on Mobile IPv6 protocol and its extensions. It is true that we have dealt with some extensions to IPsec/IKE in areas where IPsec and mobility mechanisms have had to interact. However, I think it is reasonable to keep those interactions to minimum, and strive to maintain independence and generality. In particular, where we see something might be a generally useful feature for the IPsec protocol set, it seems wrong to develop a version of specific to one particular application. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 27 04:48:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3TC2-0005m7-CD; Wed, 27 Jun 2007 04:48:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3TC1-0005m0-2X for mip6@ietf.org; Wed, 27 Jun 2007 04:48:05 -0400 Received: from cluster-j.mailcontrol.com ([86.111.223.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3TBh-0001kS-4r for mip6@ietf.org; Wed, 27 Jun 2007 04:48:05 -0400 Received: from rly49j.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly49j.srv.mailcontrol.com (MailControl) with ESMTP id l5R8kf2L002508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Jun 2007 09:47:28 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly49j.srv.mailcontrol.com (MailControl) id l5R8kN6a000904 for mip6@ietf.org; Wed, 27 Jun 2007 09:46:23 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly49j-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l5R8kGvw000326; Wed, 27 Jun 2007 09:46:23 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 4f20_3af687f2_2489_11dc_98c3_0030482aac25; Wed, 27 Jun 2007 10:34:33 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007062710460920-28853 ; Wed, 27 Jun 2007 10:46:09 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.147,BAYES_00: -1.665,TOTAL_SCORE: -1.518 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Wed, 27 Jun 2007 10:44:15 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature In-Reply-To: <46821CFA.5050106@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature Thread-Index: Ace4k7ZkQO4VB8LRSJmbESvf2aWJSwAAHNrg References: <4680D95F.10403@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de><0a8e01c7b811$f95b8d30$576115ac@dcml.docomolabsusa.com><4681590C.6010904@azairenet.com><0b0301c7b821$f1cec540$576115ac@dcml.docomolabsusa.com><46816254.1020306@azairenet.com><0b1801c7b828$4fb40930$576115ac@dcml.docomolabsusa.com><46816A07.50903@azairenet.com> <0b3601c7b82b$43257020$576115ac@dcml.docomolabsusa.com> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A9B@lan-ex-02.panasonic.de> <46821CFA.5050106@piuha.net> To: "Jari Arkko" , "Kilian Weniger" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB2E9AB7@lan-ex-02.panasonic.de> Date: Wed, 27 Jun 2007 10:45:48 +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.74.1.159 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org, Mobile IPv6 Mailing List , Sam Hartman , Brian E Carpenter 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 Jari, I fully agree that it makes sense to apply the independence and generality principle when it makes sense. I also agree that it may make sense in this case, although this case may be a bit special for the following reasons: IMHO, we should apply this principle 1) earlier in the process of a document, so that the standardization of the "to-be-generalized" mechanism is not unnecessarily and significantly delayed. 2) equally to all mechanisms/drafts. For instance, what about stateless address autoconfiguration of a remote address, i.e., HoA auto-configuration with MIP6_HOME_PREFIX attribute in draft-ietf-mip6-bootstrapping-split? Shouldn't this also be a candidate? So if it is only about broadening the applicability, how about a compromise in this special case: We keep the anycast IKE mechanism in the split scenario draft (to avoid delay in standardization) and in parallel pursue a generalized IKEv2 anycast extension in a new document. When this is completed, we can replace the text in the split scenario bootstrapping document (in a bis version) with a reference to the generalized version. We could do the same with the stateless address autoconfiguration of a remote address mechanism. Kilian > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Mittwoch, 27. Juni 2007 10:17 > To: Kilian Weniger > Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org;=20 > Mobile IPv6 Mailing List; Sam Hartman; Brian E Carpenter > Subject: Re: [Mip6] bootstrapping-split anycast/ikev2 ha=20 > selection feature >=20 > Kilian, >=20 > A comment regarding the MIP6 WG role: >=20 > > But if it is the former, I don't see a strong argument > > to split it off, since MIP6 WG modified or extended IKEv2=20 > already many > > times. > > =20 > MIP6 WG has been chartered to work on Mobile IPv6 > protocol and its extensions. It is true that we have > dealt with some extensions to IPsec/IKE in areas where > IPsec and mobility mechanisms have had to interact. > However, I think it is reasonable to keep those > interactions to minimum, and strive to maintain > independence and generality. In particular, where > we see something might be a generally useful > feature for the IPsec protocol set, it seems wrong > to develop a version of specific to one particular > application. >=20 > Jari >=20 >=20 >=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 mext-bounces@ietf.org Wed Jun 27 06:08: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 1I3URQ-0002WZ-Gd; Wed, 27 Jun 2007 06:08:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3URE-00022q-GJ for mext@ietf.org; Wed, 27 Jun 2007 06:07:52 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3UQJ-0005O9-N7 for mext@ietf.org; Wed, 27 Jun 2007 06:07:52 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1182938811!2338471!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 6441 invoked from network); 27 Jun 2007 10:06:52 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-7.tower-153.messagelabs.com with SMTP; 27 Jun 2007 10:06:52 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l5RA6pn7027274 for ; Wed, 27 Jun 2007 05:06:51 -0500 (CDT) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l5RA6ow8011429 for ; Wed, 27 Jun 2007 05:06:50 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.1.41]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l5RA6nGV011410 for ; Wed, 27 Jun 2007 05:06:49 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Wed, 27 Jun 2007 11:06:47 +0100 Message-ID: <468236AE.8060805@gmail.com> Date: Wed, 27 Jun 2007 12:06:38 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Jari Arkko Subject: Re: some dates (was: [MEXT] new charter version) References: <467FB99E.3000105@piuha.net> In-Reply-To: <467FB99E.3000105@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000752-1, 26/06/2007), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 27 Jun 2007 10:06:47.0881 (UTC) FILETIME=[DF978390:01C7B8A2] X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Just to say some dates should be updated to 2008 instead of 2007. Jari Arkko wrote: [...] > Dec 2007 Submit -00 draft for solution to aircraft/spacecraft problem > Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG > for publication as a Proposed Standard. > Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the > IESG, for Proposed Standard > > Jan 2007 Submit final doc on Route Optimization Needs for Automobile > and Highway Deployments, for Informational > Jan 2007 Submit final doc on Route Optimization needs for Personal > Mobile Router, for Informational ^here. > Feb 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for > publication as a proposed standard. > Feb 2008 Determine how to proceed with remaining automotive/Personal > Mobile Router solutions Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mip6-bounces@ietf.org Wed Jun 27 06:27: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 1I3Uk1-0007xu-5y; Wed, 27 Jun 2007 06:27:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Uk0-0007xm-7Y for mip6@ietf.org; Wed, 27 Jun 2007 06:27:16 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3UjM-0002ms-F2 for mip6@ietf.org; Wed, 27 Jun 2007 06:27:16 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1182939995!1802402!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 4772 invoked from network); 27 Jun 2007 10:26:35 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-5.tower-153.messagelabs.com with SMTP; 27 Jun 2007 10:26:35 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l5RAQZIr003195 for ; Wed, 27 Jun 2007 03:26:35 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l5RAQYtX014267 for ; Wed, 27 Jun 2007 05:26:34 -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 l5RAQXoP014255 for ; Wed, 27 Jun 2007 05:26:33 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Wed, 27 Jun 2007 11:26:32 +0100 Message-ID: <46823B56.1050105@gmail.com> Date: Wed, 27 Jun 2007 12:26:30 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Mobile IPv6 Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000752-1, 26/06/2007), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 27 Jun 2007 10:26:32.0609 (UTC) FILETIME=[A1BEA910:01C7B8A5] X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Mip6] Prefix Table for DSMIPv6? 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 Do you think it is necessary to add a Prefix Table at HA, in the DSMIPv6 spec that contains the list of IPv4 Mobile Network Prefixes and their corresponding IPv4 Home Addresses? This table would be used by the DSMIPv6 HA to check the IPv4 MNP received in a BU against the corresponding prefix (same IPv4 HoA) in the Prefix Table. The table helps avoid a security risk whereby a DSMIPv6 MR claims the IPv4 Mobile Network Prefix of a victim DSMIPv6 MR, of the same DSMIPv6 HA. This table is used by NEMOv6 (rfc3963) and NEMOv4 (draft state). In spec and in implementation. 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 mext-bounces@ietf.org Wed Jun 27 06: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 1I3UkM-0008NK-CI; Wed, 27 Jun 2007 06:27:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3UkH-0008Db-F5 for mext@ietf.org; Wed, 27 Jun 2007 06:27:33 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Ujd-0002nW-I3 for mext@ietf.org; Wed, 27 Jun 2007 06:27:33 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 54A331986A6; Wed, 27 Jun 2007 13:26:52 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0E526198691; Wed, 27 Jun 2007 13:26:52 +0300 (EEST) Message-ID: <46823B6B.9020600@piuha.net> Date: Wed, 27 Jun 2007 13:26:51 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Alexandru Petrescu References: <467FB99E.3000105@piuha.net> <468236AE.8060805@gmail.com> In-Reply-To: <468236AE.8060805@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mext@ietf.org Subject: [MEXT] Re: some dates X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Ah, of course. Thanks for catching this. Jari Alexandru Petrescu kirjoitti: > Just to say some dates should be updated to 2008 instead of 2007. > > Jari Arkko wrote: > [...] >> Dec 2007 Submit -00 draft for solution to aircraft/spacecraft problem >> Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG >> for publication as a Proposed Standard. >> Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the >> IESG, for Proposed Standard >> >> Jan 2007 Submit final doc on Route Optimization Needs for Automobile >> and Highway Deployments, for Informational >> Jan 2007 Submit final doc on Route Optimization needs for Personal >> Mobile Router, for Informational > > ^here. > >> Feb 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for >> publication as a proposed standard. >> Feb 2008 Determine how to proceed with remaining automotive/Personal >> Mobile Router solutions > > Alex > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mip6-bounces@ietf.org Wed Jun 27 09:54: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 1I3Xym-0004lZ-LW; Wed, 27 Jun 2007 09:54:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Xyl-0004ky-Mr for mip6@ietf.org; Wed, 27 Jun 2007 09:54:43 -0400 Received: from s-utl02-atpop.stsn.net ([72.254.128.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3XyJ-0002vv-Pg for mip6@ietf.org; Wed, 27 Jun 2007 09:54:43 -0400 Received: from s-utl02-atpop.stsn.net ([127.0.0.1]) by s-utl02-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007062709540106046 ; Wed, 27 Jun 2007 09:54:01 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.165,BAYES_00: -1.665 X-Spam-Level: Received: from [127.0.0.1] ([10.86.126.76]) by s-utl02-atpop.stsn.net; Wed, 27 Jun 2007 09:53:57 -0400 Message-ID: <46826BDD.8020102@azairenet.com> Date: Wed, 27 Jun 2007 06:53:33 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Brian E Carpenter References: <4680D95F.10403@piuha.net> <46811047.7080707@azairenet.com> <46821A47.5050405@gmail.com> In-Reply-To: <46821A47.5050405@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org, Mobile IPv6 Mailing List , Sam Hartman Subject: [Mip6] Re: bootstrapping-split anycast/ikev2 ha selection feature 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 E Carpenter wrote: > Hi, > > On 2007-06-26 15:10, Vijay Devarapalli wrote: >> Hello Jari, Brian and Sam, >> >> I saw three significant comments regarding the use of anycast address. >> Let me respond to them. >> >> 1. The MIPv6 community has a very good understanding of how IPv6 >> anycast works. We have been using it for the dynamic home agent >> address discovery [RFC 3775] for years. The text in the document >> that talks about assigning the anycast address to the one of the >> interfaces is the result of some "careless text". Sorry about >> that. Needs to be fixed. All the home agents in the anycast group >> would have the anycast address configured. > > That would be fine for me. (There are some other points in my review > though...) Gerardo, the editor for this document, is a bit busy now. We will respond to the comments soon. >> >> 2. The mobile node might not know it is using anycast address >> since anycast addresses are supposed to look like unicast address. >> MIPv6 home agents anycast address is a special reserved address. >> See RFC 2526. The mobile node would know. > > OK, but the text didn't make it fully clear that *only* the RFC2526 HA > anycast address would be used. You are right. Need to add some text pointing to RFC 2526. Thanks Vijay >> 3. MIPv6 WG shouldn't be extending IKEv2. Why? Since when? We >> have added quite a few attributes/payloads/etc... to IKEv2 already. >> We have specified a mechanism to dynamically update the IKEv2 SA >> (the 'K' bit in RFC 3775 and 3776). We dynamically update the >> tunnel mode IPsec SA with a binding update. > > Unlike Sam, I've got no opinion on that. > > Brian >> >> For this document we have extended IKEv2 to ignore the mismatch >> between the destination address on the IKE_SA_INIT request from >> the MN and the source address on the IKE_SA_INIT response to the >> MN. We spoke to a number of IKEv2/IPsec folks on this topic. Most >> agreed that the "MUST" in RFC 4306 about matching the destination >> address on the IKE_SA_INIT request and the source address on the >> IKE_SA_INIT response is wrong. It shouldn't have been a "MUST". >> >> So I don't yet see a reason to remove it. >> >> Vijay >> >> Jari Arkko wrote: >>> Authors, WG, >>> >>> IETF last call and IESG review produced a number of >>> comments relating to the selection of a home agent >>> via anycast. See in particular Sam Hartman's Discuss >>> and Brian Carpenter's comments. >>> >>> There a number of ways in which we could address >>> these issues. What I would like to try is to separate >>> the anycast functionality from this draft and pursue >>> it as a general IKEv2 extension for any application. >>> The mip6 document would then advance immediately. >>> Would this be a good way forward? Comments >>> appreciated. >>> >>> Here are the comments from the IESG: >>>> *Lars Eggert:* >>>> *Comment:* >>>> *[2007-06-20]* For all the different components of the solution, the >>>> document >>>> discusses a number of design options before describing the >>>> recommended >>>> solution. I find this confusing. It would be much cleaner if there >>>> was >>>> a normative section that talked about what is recommended, and an >>>> informative section (or appendix) that would discuss options that are >>>> not part of the recommended set. >>>> >>>> INTRODUCTION, paragraph 13: >>>>> 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. >>>> I'm a bit confused by this. Title says this is for "split scenario" >>>> bootstrapping. Abstract then says it's therefore generally applicable >>>> for any bootstrapping scenario? (Also, it'd be good if the abstract >>>> could define the words "split scenario" from the title somewhere, so >>>> that folks not familiar with the term understand what it means.) >>>> >>>> >>>> Section 5.1., paragraph 1: >>>>> As >>>>> mentioned before in the document, the only information that >>>>> needs to >>>>> be pre-configured on the Mobile Node is the domain name of the >>>>> Mobility Service Provider. >>>> This paragraph says "need only domain name." Next paragraph says "MN >>>> is configured with DNS server." So apparently MN needs to be >>>> configure >>>> with at least two pieces of information? >>>> >>>> *Sam Hartman:* >>>> *Discuss:* >>>> *[2007-06-21]* A question to the aps folks: Doesn't the first label of >>>> aSRV >>>> registration need to be a well known port or at least get taken from >>>> the same namespace? If so, has mip6 been registered there? Also, is >>>> ipv6 an acceptable second label for the srv record? >>>> >>>> I'm concerned that the anycast behavior modifies IKEV2. I don't think >>>> it is appropriate for MIP6 to be extending or modifying IKE in MIP6 >>>> applications. Wouldn't it be better to run that extension by the >>>> IPsec community and make it available generally? >>>> >>>> *Russ Housley:* >>>> *Discuss:* >>>> *[2007-06-20]* >>>> Significant comments were included in the Gen-ART review from >>>> Brian Carpenter. These need to be handled as any other Last >>>> Call comments. (Note: Last Call is not concluded yet.) >>>> >>>> *Tim Polk:* >>>> *Discuss:* >>>> *[2007-06-20]* This document is underspecified with respect to >>>> certificate processing and retrieval and CRL >>>> checking. The document refers to CRL checking, but Figure 3 and the >>>> accompanying text >>>> seem to imply online status checking. Without additional details, it >>>> seems unlikely interoperable >>>> implementations could be developed. >>> And from Brian Carpenter's last call comments: >>> >>>>> ...The Mobile Node sends the IKE_SA_INIT request to the >>>>> anycast address. The node which has the anycast address >>>>> assigned to >>>>> one of its network interfaces... >>>> >>>> That is not IPv6 anycast. The definition of IPv6 anycast addresses is >>>> quite clear (RFC 4291): >>>> >>>> Anycast: An identifier for a set of interfaces (typically >>>> belonging to different nodes). A packet sent to an >>>> anycast address is delivered to one of the interfaces >>>> identified by that address (the "nearest" one, according >>>> to the routing protocols' measure of distance). >>>> >>>> In other words, an anycast HA implementation would assign >>>> the anycast address to *all* the HAs and the first one to >>>> respond would "win". >>>> >>>> What is described in the current draft is a perfectly reasonable >>>> redirect mechanism for load sharing (albeit with a single point >>>> of failure) but it is *not* IPv6 anycast. It would be anycast >>>> if *any* of the HAs could respond with the redirect. >>>> >>>> Either the design should be modified to do this, or the word >>>> "anycast" should be dropped from the description. >>>> >>>> I don't know IKEv2 well enough to find fault with the cookie >>>> mechanism for implementing a secure redirect. Even though >>>> it's a bit of a hack, it seems to work. I note that RFC 4306 >>>> does not use the term '"under attack" cookie'. >>>> >>>> ... >>>>> The use of anycast address as specified above requires the >>>>> implementation of anycast forwarding in such a way that the Home >>>>> Agent can distinguish between an IKE_SA_INIT forwarded through an >>>>> anycast address and one sent directly from the Mobile Node. One >>>>> possible mechanism is to use IP-in-ip tunneling for forwarding the >>>>> IKE_SA_INIT. In this case, the Home Agent can identify a forwarded >>>>> IKE_SA_INIT based on the incoming interface or based on the >>>>> additional IP header. Other mechanisms may be used. >>>> >>>> This is underspecified and will make it impossible to deploy >>>> heterogeneous HAs together. >>>> >>>> ... >>>>> A mobile node's security associations with its home agent may >>>>> expire >>>>> while it still has a valid binding cache entry at the the home >>>> agent. >>>>> In this case, the mobile node MUST NOT use an anycast address as >>>>> the >>>>> destination address in the IKE_SA_INIT exchange to setup new >>>> security >>>>> associations. It MUST try to setup security associations with its >>>>> existing home agent. >>>> >>>> By definition, the MN doesn't know that a given address is an anycast >>>> address, since anycast addresses are syntactically indistinguishable. >>>> I think you mean: if the MN obtained its HA address via the "under >>>> attack" >>>> cookie exchange, it MUST continue to use that address and not revert >>>> to the address it got from DNS. >>>> >>>>> 5.3.2. Home Address auto-configuration by the Mobile Node >>>> ... >>>>> For this reason the Mobile Node needs to obtain the home link >>>>> prefixes through the IKEv2 exchange. In the Configuration Payload >>>>> during the IKE_AUTH exchange, the Mobile Node includes the >>>>> MIP6_HOME_PREFIX attribute in the CFG_REQUEST message. The Home >>>>> Agent, when it processes this message, should include in the >>>>> CFG_REPLY payload prefix information for one prefix on the home >>>> link. >>>> >>>> It seems that 'should' should be a MUST. I don't see any alternative >>>> case. >>>> >>>>> 5.4. Authorization and Authentication with MSA >>>> ... >>>>> The definition of this backend communication is out of the scope of >>>>> this document. In [16] a list of goals for such a communication is >>>>> provided. >>>> ... >>>>> 6. Home Address registration in the DNS >>>> ... >>>>> ...The >>>>> detailed description of the communication between Home Agent and >>>>> AAA >>>>> is out of the scope of this document. More details are provided in >>>>> [16]. >>>> >>>> I see a significant dependency here. I don't see how interoperable >>>> implementations can be made while these issues are undefined. If >>>> these issues are left open, there is a high risk of MSA/MSP interop >>>> depending on interim or proprietary choices. I don't get this, since >>>> the whole point of an MSA/MSP split is presumably to avoid >>>> walled garden deployments. Since [16] is Informative, there is >>>> nothing at present to prevent this. >>>> >>>>> 9.2. Home Address Assignment through IKEv2 >>>> ... >>>>> RFC 3775 [1] requires that a Home Agent check authorization of a >>>> home >>>>> address received during a Binding Update. Therefore, the home >>>>> agent >>>>> MUST authorize each home address allocation and use. This >>>>> authorization is based on linking the mobile node identity used in >>>>> the IKEv2 authentication process and the home address. Home agents >>>>> MUST support at least the following two modes of authorization: >>>>> >>>>> o Configured home address(es) for each mobile node. In this mode, >>>>> the home agent or infrastructure nodes behind it know what >>>>> addresses a specific mobile node is authorized to use. The >>>> mobile >>>>> node is allowed to request these addresses, or if the mobile >>>>> node >>>>> requests any home address, these addresses are returned to it. >>>>> >>>>> o First-come-first-served (FCFS). In this mode, the home agent >>>>> maintains a pool of "used" addresses, and allows mobile nodes to >>>>> request any address, as long as it is not used by another mobile >>>>> node. >>>> >>>> It isn't obvious why both are needed, but in any case the document >>>> should specify whether these are MUST implement or MUST deploy. >>>> >>>>> 9.5. Dynamic DNS Update >>>>> >>>>> If a Home Agent performs dynamic DNS update on behalf of the Mobile >>>>> Node directly with the DNS server, the Home Agent MUST have a >>>>> security association of some type with the DNS server. The >>>>> security >>>>> association MAY be established either using DNSSEC [18] or >>>>> TSIG/TKEY >>>>> [19][20]. A security association is required even if the DNS >>>>> server >>>>> is in the same administrative domain as the Home Agent. The >>>> security >>>>> association SHOULD be separate from the security associations used >>>>> for other purposes, such as AAA. >>>> >>>> Should 'required' be 'REQUIRED'? >>>> >>>> Since use of dynamic DNS is optional, is this a >>>> 'MUST implement' security requirement? >>>> >>>> ... >>>>> In the case where the Mobility Service Provider is different from >>>> the >>>>> Mobility Service Authorizer, the network administrators may want to >>>>> limit the number of cross-administrative domain security >>>>> associations. If the Mobile Node's FQDN is in the Mobility Service >>>>> Authorizer's domain, since a security association for AAA signaling >>>>> involved in mobility service authorization is required in any case, >>>>> the Home Agent can send the Mobile Node's FQDN to the AAA server >>>>> under the HA-AAA server security association, and the AAA server >>>>> can >>>>> perform the update. In that case, a security association is >>>> required >>>>> between the AAA server and DNS server for the dynamic DNS update. >>>>> See [16] for a deeper discussion of the Home Agent to AAA server >>>>> interface. >>>> >>>> Again, is this 'MUST implement'? If so, it increases my concern about >>>> [16] being non-normative (and again two paragraphs below). >>>> >>>>> Regardless of whether the AAA server or Home Agent performs DNS >>>>> update, the authorization of the Mobile Node to update a FQDN >>>> MUST be >>>>> checked prior to the performance of the update. It is an >>>>> implementation issue as to how authorization is determined. >>>> >>>> Again, worrisome in terms of an MN implementer knowing >>>> what to implement. We don't want MNs that only work with certain >>>> types of HA/MSA/MSP setups. >>>> >>>> Editorial: >>>> ---------- >>>> >>>> (these are typos that are actually technical errors) >>>> >>>>> 3. Split scenario >>>> ... >>>>> ... the Mobile Node potentially requires a certificate >>>>> revocation list check (CTL check) >>>> >>>> s/CTL/CRL/ >>>> >>>>> 5.1. Home Agent Address Discovery >>>> ... >>>>> The Mobile Node needs to obtain the IP address of the DNS server >>>>> before it can send a DNS request. >>>> >>>> s/the DNS server/a DNS server/ >>>> >>>>> 5.1.1. DNS lookup by Home Agent Name >>>> ... >>>>> Note that the configuration of a fixed home agent FQDN does allow >>>>> dynamic assignment of a localized home agent. >>>> >>>> s/does/does not/ >>>> >>>>> 5.2. IPsec Security Associations setup >>>> ... >>>>> ... This is >>>>> needed because the Mobile Node has to provide it is the owner of >>>>> the >>>>> FQDN provided in the subsequent DNS Update Option. >>>> >>>> s/provide/prove/ >>> >> >> >> >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 27 13:02: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 1I3atx-0003cT-Sb; Wed, 27 Jun 2007 13:01:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3atv-0003cN-Vl for mip6@ietf.org; Wed, 27 Jun 2007 13:01:55 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3asr-0003YP-UA for mip6@ietf.org; Wed, 27 Jun 2007 13:01:55 -0400 Message-ID: <0c6f01c7b8dc$b5850ca0$576115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Kilian Weniger" , "Jari Arkko" References: <4680D95F.10403@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de><0a8e01c7b811$f95b8d30$576115ac@dcml.docomolabsusa.com><4681590C.6010904@azairenet.com><0b0301c7b821$f1cec540$576115ac@dcml.docomolabsusa.com><46816254.1020306@azairenet.com><0b1801c7b828$4fb40930$576115ac@dcml.docomolabsusa.com><46816A07.50903@azairenet.com> <0b3601c7b82b$43257020$576115ac@dcml.docomolabsusa.com> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A9B@lan-ex-02.panasonic.de> <46821CFA.5050106@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9AB7@lan-ex-02.panasonic.de> Subject: Re: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature Date: Wed, 27 Jun 2007 10:00:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org, Mobile IPv6 Mailing List , Sam Hartman , Brian E Carpenter 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 Killian, I fully agree that it makes sense to apply the independence and generality principle when it makes sense. I also agree that it may make sense in this case, although this case may be a bit special for the following reasons: IMHO, we should apply this principle 1) earlier in the process of a document, so that the standardization of the "to-be-generalized" mechanism is not unnecessarily and significantly delayed. 2) equally to all mechanisms/drafts. For instance, what about stateless address autoconfiguration of a remote address, i.e., HoA auto-configuration with MIP6_HOME_PREFIX attribute in draft-ietf-mip6-bootstrapping-split? Shouldn't this also be a candidate? jak>> As I recall, the authors and design team discussed issuing MIP6_HOME_PREFIX as a separate draft and rejected the idea because we felt that it was, as Jari says, a specific extension for Mobile IPv6. I believe we talked with someone in SAAG about this at the time we were considering putting it into a separate draft, and we were told to include it in the bootstrapping draft rather than separate it out. Other authors please correct me if my memory is faulty here. Also, as I mentioned in a previous post, anycast/IKEv2 is a change in key agreement, which is a much more serious and deep change in the security protocol than MIP6_HOME_PREFIX. Therefore, it makes perfect sense to me to spend more time on making sure it is right. So if it is only about broadening the applicability, how about a compromise in this special case: We keep the anycast IKE mechanism in the split scenario draft (to avoid delay in standardization) and in parallel pursue a generalized IKEv2 anycast extension in a new document. When this is completed, we can replace the text in the split scenario bootstrapping document (in a bis version) with a reference to the generalized version. We could do the same with the stateless address autoconfiguration of a remote address mechanism. jak>> I disagree with this. There is, as I said, no compelling deployment reason that bootstrapping needs to be standardized right away (though I personally would really like to see this work *done* and published). Also, regarding your comment that I supported this extension, it was only "consent by silence", and that only in public. I have always believed that bootstrapping without anycast/IKEv2 would be useful in and of itself, and at the time adding anycast/IKEv2 was under consideration, we exchanged email among you, Francis, the other authors, and me about this. I have always had some concerns about it but was willing to forgo airing them since the WG seemed to be behind it, and because I couldn't quite articulate why I was uneasy. Recently, spending more of my time reviewing security protocols for some other work I am doing, I've come to appreciate how difficult it is to get security protocols right, and how important it is to spend the proper amount of time in reviewing them, especially protocols like key agreement upon which the security of future transactions is based. I'm glad that the IESG has decided to raise this DISCUSS, though I wish Sam's comments had been more technicallly directed rather that saying "MIP6 shouldn't do this" which, to me, sounds like a juicy invitation for people in the MIP6 WG to push back. Finally, I think incuding this in the bootstrapping draft then later standardizing a general version is not a good idea, since it could result in deployed systems with serious security bugs, if some bug is found in the initial version (reference: the WEP Catastrophe in 802.11). jak>> If you care so much about this, why don't you write a draft right now sectioning off the anycast/IKEv2 protocol, submit it by the Monday deadline, and put it up for discussion in a security WG in Chicago? I'm sure Sam and Jari would be happy to assist getting you set up with the proper venue, since they are requesting that it be removed. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 27 20:30: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 1I3htq-0002p4-GC; Wed, 27 Jun 2007 20:30:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3htp-0002oR-AX for mip6@ietf.org; Wed, 27 Jun 2007 20:30:17 -0400 Received: from an-out-0708.google.com ([209.85.132.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3ht2-0007p4-6b for mip6@ietf.org; Wed, 27 Jun 2007 20:30:17 -0400 Received: by an-out-0708.google.com with SMTP id c17so83071anc for ; Wed, 27 Jun 2007 17:29:27 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PLggfnQYUhbM3e2jrPcMauieac1Vr5+ZSbXRKm2m10kE/nkt7w3sibmgniXnk6fn1Vyve2x2NkPvuBe5bmIhqohnF0ZfE661ZUfn6swoQ0ttCZ9lXwKRdl/rN+E2IysSZFgwYFRYmZVBl9qvRcOqNQYdRWGpEYU18Mw0qI0VIzI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GCuOqwBfizcFM2xL/AwyPq/ZgculgRqwYQgJL8KAFcHPo04f/s51XIt8caufzVNTWZeQbrZ4Gar8FVgDKAwK8gPYLY3NT5BmRadcgtU9B+Xfvx5QzR34vHFoV+g5bclSlIhX66VDlOIF/IN8JlwJp3klTmNk9joHP95jEnaKUBs= Received: by 10.100.194.7 with SMTP id r7mr791839anf.1182990567877; Wed, 27 Jun 2007 17:29:27 -0700 (PDT) Received: by 10.100.135.16 with HTTP; Wed, 27 Jun 2007 17:29:27 -0700 (PDT) Message-ID: <729b68be0706271729pe87e23coce0bf6f9a5f590b8@mail.gmail.com> Date: Thu, 28 Jun 2007 02:29:27 +0200 From: "Jean-Michel Combes" To: "James Kempf" Subject: Re: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature In-Reply-To: <0c6f01c7b8dc$b5850ca0$576115ac@dcml.docomolabsusa.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4680D95F.10403@piuha.net> <0b0301c7b821$f1cec540$576115ac@dcml.docomolabsusa.com> <46816254.1020306@azairenet.com> <0b1801c7b828$4fb40930$576115ac@dcml.docomolabsusa.com> <46816A07.50903@azairenet.com> <0b3601c7b82b$43257020$576115ac@dcml.docomolabsusa.com> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A9B@lan-ex-02.panasonic.de> <46821CFA.5050106@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9AB7@lan-ex-02.panasonic.de> <0c6f01c7b8dc$b5850ca0$576115ac@dcml.docomolabsusa.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org, Mobile IPv6 Mailing List , Kilian Weniger , Sam Hartman , Brian E Carpenter 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, 2007/6/27, James Kempf : > Killian, > > I fully agree that it makes sense to apply the independence and > generality principle when it makes sense. I also agree that it may make > sense in this case, although this case may be a bit special for the > following reasons: > > IMHO, we should apply this principle > 1) earlier in the process of a document, so that the standardization of > the "to-be-generalized" mechanism is not unnecessarily and significantly > delayed. > 2) equally to all mechanisms/drafts. For instance, what about stateless > address autoconfiguration of a remote address, i.e., HoA > auto-configuration with MIP6_HOME_PREFIX attribute in > draft-ietf-mip6-bootstrapping-split? Shouldn't this also be a candidate? > > jak>> As I recall, the authors and design team discussed issuing > MIP6_HOME_PREFIX as a separate draft and rejected the idea because we felt > that it was, as Jari says, a specific extension for Mobile IPv6. I believe > we talked with someone in SAAG about this at the time we were considering > putting it into a separate draft, and we were told to include it in the > bootstrapping draft rather than separate it out. Other authors please > correct me if my memory is faulty here. Also, as I mentioned in a previous > post, anycast/IKEv2 is a change in key agreement, which is a much more > serious and deep change in the security protocol than MIP6_HOME_PREFIX. > Therefore, it makes perfect sense to me to spend more time on making sure it > is right. As Kilian mentioned, there was also discussions with IPsec guys about the anycast/IKEv2 extension and, IIRC, no issues were raised. > > So if it is only about broadening the applicability, how about a > compromise in this special case: We keep the anycast IKE mechanism in > the split scenario draft (to avoid delay in standardization) and in > parallel pursue a generalized IKEv2 anycast extension in a new document. > When this is completed, we can replace the text in the split scenario > bootstrapping document (in a bis version) with a reference to the > generalized version. We could do the same with the stateless address > autoconfiguration of a remote address mechanism. > > jak>> I disagree with this. There is, as I said, no compelling deployment > reason that bootstrapping needs to be standardized right away (though I > personally would really like to see this work *done* and published). Also, > regarding your comment that I supported this extension, it was only "consent > by silence", and that only in public. I have always believed that > bootstrapping without anycast/IKEv2 would be useful in and of itself, and at > the time adding anycast/IKEv2 was under consideration, we exchanged email > among you, Francis, the other authors, and me about this. I have always had > some concerns about it but was willing to forgo airing them since the WG > seemed to be behind it, and because I couldn't quite articulate why I was > uneasy. Recently, spending more of my time reviewing security protocols for > some other work I am doing, I've come to appreciate how difficult it is to > get security protocols right, and how important it is to spend the proper > amount of time in reviewing them, especially protocols like key agreement > upon which the security of future transactions is based. I'm glad that the > IESG has decided to raise this DISCUSS, though I wish Sam's comments had > been more technicallly directed rather that saying "MIP6 shouldn't do this" > which, to me, sounds like a juicy invitation for people in the MIP6 WG to > push back. Finally, I think incuding this in the bootstrapping draft then > later standardizing a general version is not a good idea, since it could > result in deployed systems with serious security bugs, if some bug is found > in the initial version (reference: the WEP Catastrophe in 802.11). You mean there needs more discussion about it (cf. below what are my fears)? > > jak>> If you care so much about this, why don't you write a draft right now > sectioning off the anycast/IKEv2 protocol, submit it by the Monday deadline, > and put it up for discussion in a security WG in Chicago? I'm sure Sam and > Jari would be happy to assist getting you set up with the proper venue, > since they are requesting that it be removed. The issues I see now are that, knowing that IPsec WG is closed (even if the ML is, more or less, still alive): - I don't know where is the right place to discuss about this draft - I am afraid to see the same (bad - IMHO) results we had with the IFare BOF (knowing that a standardized IPsec Fail-Over solution is needed for the HA reliability and we have exactly the same issue here: a try for a general solution,which would be applied for MIPv6, and has been aborted, for the moment) Best regards. JMC. > > jak > > > > _______________________________________________ > 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 Jun 27 22:53: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 1I3k7z-00042v-1a; Wed, 27 Jun 2007 22:53:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3k7x-00042k-Kx for mip6@ietf.org; Wed, 27 Jun 2007 22:53:01 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3k7s-0002Kt-Va for mip6@ietf.org; Wed, 27 Jun 2007 22:53:01 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 19:52:55 -0700 Message-ID: <46832284.5080402@azairenet.com> Date: Wed, 27 Jun 2007 19:52:52 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Brian Haley Subject: Re: [Mip6] Consensus call: Make I-D draft-haley-mip6-mh-signaling-02.txt a WG doc References: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C3F@zrc2hxm2.corp.nortel.com> <46647E44.6030000@hp.com> In-Reply-To: <46647E44.6030000@hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jun 2007 02:52:55.0790 (UTC) FILETIME=[6DAB68E0:01C7B92F] X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: Mobile IPv6 Mailing List , ext 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 Brian Haley wrote: > Hi Raj, > > Ahmad, Sri and I have talked off-line about how to go forward with > draft-haley and support draft-muhanna better. We've come to the > following conclusion (someone update if I got this wrong). > > Draft-haley will define a Generic Notification Message (GNM) which is a > new MH type, and also define two new sub-types - one for Signaling > Request, one for Signaling Reply (or some wording like that). > > The structures would look something like this: > > Generic Notification Message (w/MH message pieces, MH Type TBD) > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload Proto | Header Len | MH Type | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Checksum | GNM Type/Sub-Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > In essence, the message is just a container to transport notification > messages between mobility entities. > > They we'd define two Sub-types with the same semantics of the current > messages in draft-haley: > > Signaling Request (GNM Type TBD): > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number |A| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Signaling Reply (GNM Type TBD): > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | Status | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > This would give someone that wants to use the semantics of the Signaling > Messages an easy framework for implentation (sequencing, retransmission, > etc). All they would have to do is define a mobility option with their > data to go "inside". > > Ahmad would define a new GNM Sub-type for revocation, and whatever > structures and options to go with it. > > I'll update draft-haley with these changes if there are no objections. I have an objection. I would like to use the existing format of having a generic signaling message and using mobility options to carry the actual information. The above format has one drawback, in the sense that you can't carry more than piece of information since you use the subtype field to indicate what you are carrying. When you use mobility options, you don't really have that restriction. You can chain any number of mobility options. Vijay > > Thanks to Ahmad for the suggestions. > > -Brian > > > Ahmad Muhanna wrote: >> Hello, >> >> My understanding that the scope of draft-haley is as follows: >> >> o A generic container which can be used to communicate multiple >> functionalities while preserving the MH types. >> o Introduce a Generic Notification Messages and Generic Notification >> mechanism that can be used to communicate several common >> notification event(s) >> between the HA and the MN. >> >> Having said that, I would like to propose a small change to the >> current Draft-haley revision 02 which would hopefully enrich and >> enhance the >> draft. >> >> The following summarize the proposed changes: >> ============================================= >> 1. Define the first two bytes, of the current generic notification >> message, and call them , for example, Generic Mobility Container, >> GMC, or XYZ. >> >> 2. The Generic Mobility Container is 2 bytes length and can have up >> to 64k >> different values which we can call, for example, GMC Type. i.e. >> >> Generic Notification Request message, Generic Notification Ack, >> Binding Revocation Indication message, Binding Revocation Ack, >> etc. >> >> 3. Every common functionality defines its own messages and mechanism >> including its own mechanism as fits the need of the specified >> functionality. >> >> 4. Any functionality, e.g. Generic Notification, may define the >> use of any MH option inside its own messages or define new ones. >> >> Here is the format, let us use the Generic Notification and Binding >> Revocation as examples: >> 1. Generic Mobility Container Message >> ===================================== This Signaling Generic Mobility >> Container Message uses the MH Type value >> (TBD). >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | GMC Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> . . >> . Message Data . >> . . >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> 2. Generic Notification >> ======================= >> >> Let us assume that this application requires two messages, a Request and >> >> an acknowledgement. >> >> 3.1. Generic Notification Request >> ================================== >> This Generic Notification Request uses a GMC Type of (TBD). >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | GMC Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> . . >> . Generic Notification Request . >> . . >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> 3.2. Generic Notification Ack >> ============================== >> This Generic Notification Ack uses a GMC Type of (TBD). >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | GMC Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> . . >> . Generic Notification Ack . >> . . >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> 3. Binding Revocation >> ====================== >> >> The following are the revocation messages that are defined by >> the Binding Revocation Functionality as specified by the Binding >> Revocation for IPv6 Mobility draft. >> 2.1. Binding Revocation Indication >> ================================== >> >> This Binding Revocation Indication uses a GMC Type of (TBD). >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | GMC Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> . . >> . Binding Revocation Indication . >> . . >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> 2.2. Binding Revocation Acknowledgement >> ======================================== >> This Binding Revocation Acknowledgement uses a GMC Type (TBD). >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | GMC Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> . . >> . Binding Revocation Acknowledgement . >> . . >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Finally and as a suggestion, I would like to suggest that draft-haley >> address two things: >> 1. Introducing the Generic Mobility Container, GMC. >> 2. Define the Generic Notification Messages and the related Mechanism. >> >> While the Binding Revocation for IPv6 Mobility draft can define the >> Binding Revocation messages and the binding revocation mechanism. >> >> >> Best Regards, >> Ahmad >> >>> -----Original Message----- >>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] Sent: >>> Wednesday, May 30, 2007 12:23 PM >>> To: Mobile IPv6 Mailing List >>> 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 >>> >>> >>> 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 >>> >> >> >> _______________________________________________ >> 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 Jun 28 01:21: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 1I3mRt-0002Vq-T8; Thu, 28 Jun 2007 01:21:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3mRs-0002Rr-UR for mip6@ietf.org; Thu, 28 Jun 2007 01:21:44 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3mRi-0001s6-8F for mip6@ietf.org; Thu, 28 Jun 2007 01:21:44 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 27 Jun 2007 22:21:33 -0700 X-IronPort-AV: i="4.16,469,1175497200"; d="scan'208"; a="173481455:sNHT43020243" 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 l5S5LXuY002539; Wed, 27 Jun 2007 22:21:33 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5S5LXmp008394; Thu, 28 Jun 2007 05:21:33 GMT Date: Wed, 27 Jun 2007 22:21:32 -0700 (PDT) From: Sri Gundavelli To: Vijay Devarapalli Subject: Re: [Mip6] Consensus call: Make I-D draft-haley-mip6-mh-signaling-02.txt a WG doc In-Reply-To: <46832284.5080402@azairenet.com> Message-ID: References: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C3F@zrc2hxm2.corp.nortel.com> <46647E44.6030000@hp.com> <46832284.5080402@azairenet.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=878; t=1183008093; x=1183872093; 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]=20Consensus=20call=3A=20Make=09I-D=09draft-hal ey-mip6-mh-signaling-02.txt=0A=20a=20WG=20doc |Sender:=20; bh=X1TwbJEm/bx8ly0Uu6LjVHvjg9tIIz56m8DCDnmVcB4=; b=HSkIm2zltZhFkcjZVk3gcbirDtVh6GRygCHxjcMZJr5KketwEDeHA8XYBMFFaWC5St5pFW+2 BFE7PScPB6dJW5i6z7c//SrDKhorZZo1MvlUOE0D8xyQD785ZNK3UYTD/TNjDNLJqGYeA4YcK6 fmogf1W7ttXk+tItU4jvi1uyQ=; 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: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Mobile IPv6 Mailing List , Brian Haley 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, > > I have an objection. I would like to use the existing format of having > a generic signaling message and using mobility options to carry the > actual information. The above format has one drawback, in the sense > that you can't carry more than piece of information since you use the > subtype field to indicate what you are carrying. When you use mobility > options, you don't really have that restriction. You can chain any > number of mobility options. > The addition of sub-type does not disallow the addition of mobility options. It provides more flexibility for defining messages with a fixed format where it cannot be expressed or not suitable for expressing it as an option. Options are suitable for carrying a fixed fields, such as HoA, NAI ..etc. So, we can still do the same of chaining multiple options for the same sub-type. Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 28 04:34: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 1I3pRz-0008NE-HA; Thu, 28 Jun 2007 04:34:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3pRy-0008N5-EX for mip6@ietf.org; Thu, 28 Jun 2007 04:34:02 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3pR9-0002ZP-1m for mip6@ietf.org; Thu, 28 Jun 2007 04:34:02 -0400 Received: from rly27b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly27b.srv.mailcontrol.com (MailControl) with ESMTP id l5S8X6xo008808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Jun 2007 09:33:07 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly27b.srv.mailcontrol.com (MailControl) id l5S8WVqb007066 for mip6@ietf.org; Thu, 28 Jun 2007 09:32:31 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly27b-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l5S8WS2n006910; Thu, 28 Jun 2007 09:32:31 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 01cc_7ae348b0_2550_11dc_838f_0030482aac25; Thu, 28 Jun 2007 10:20:50 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007062810322435-107881 ; Thu, 28 Jun 2007 10:32:24 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.145,BAYES_00: -1.665,TOTAL_SCORE: -1.520 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Thu, 28 Jun 2007 10:30:27 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: *** Possibly SPAM *** Re: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature In-Reply-To: <0c6f01c7b8dc$b5850ca0$576115ac@dcml.docomolabsusa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: *** Possibly SPAM *** Re: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature Thread-Index: Ace43MhymoLtT+8zSN+58RuVYqpdVwAcDfUw References: <4680D95F.10403@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de><0a8e01c7b811$f95b8d30$576115ac@dcml.docomolabsusa.com><4681590C.6010904@azairenet.com><0b0301c7b821$f1cec540$576115ac@dcml.docomolabsusa.com><46816254.1020306@azairenet.com><0b1801c7b828$4fb40930$576115ac@dcml.docomolabsusa.com><46816A07.50903@azairenet.com> <0b3601c7b82b$43257020$576115ac@dcml.docomolabsusa.com> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A9B@lan-ex-02.panasonic.de> <46821CFA.5050106@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9AB7@lan-ex-02.panasonic.de> <0c6f01c7b8dc$b5850ca0$576115ac@dcml.docomolabsusa.com> To: "James Kempf" , "Kilian Weniger" , "Jari Arkko" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB2E9B96@lan-ex-02.panasonic.de> Date: Thu, 28 Jun 2007 10:32:01 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-07-07-10 (www.mailcontrol.com) on 10.66.1.137 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org, Mobile IPv6 Mailing List , Sam Hartman , Brian E Carpenter 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 James, > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 > Sent: Mittwoch, 27. Juni 2007 19:01 > To: Kilian Weniger; Jari Arkko > Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org;=20 > Mobile IPv6 Mailing List; Sam Hartman; Brian E Carpenter > Subject: *** Possibly SPAM *** Re: [Mip6] bootstrapping-split=20 > anycast/ikev2 ha selection feature >=20 > Killian, >=20 > I fully agree that it makes sense to apply the independence and > generality principle when it makes sense. I also agree that=20 > it may make > sense in this case, although this case may be a bit special for the > following reasons: >=20 > IMHO, we should apply this principle > 1) earlier in the process of a document, so that the=20 > standardization of > the "to-be-generalized" mechanism is not unnecessarily and=20 > significantly > delayed. > 2) equally to all mechanisms/drafts. For instance, what about=20 > stateless > address autoconfiguration of a remote address, i.e., HoA > auto-configuration with MIP6_HOME_PREFIX attribute in > draft-ietf-mip6-bootstrapping-split? Shouldn't this also be a=20 > candidate? >=20 > jak>> As I recall, the authors and design team discussed issuing=20 > MIP6_HOME_PREFIX as a separate draft and rejected the idea=20 > because we felt=20 > that it was, as Jari says, a specific extension for Mobile=20 > IPv6. I believe=20 Why is it specific to MIPv6? I guess stateless address autoconfiguration of a remote address is something that could also be useful for other applications and scenarios, e.g., using CGAs or privacy addresses in a VPN scenario, right? > we talked with someone in SAAG about this at the time we were=20 > considering=20 > putting it into a separate draft, and we were told to include=20 > it in the=20 > bootstrapping draft rather than separate it out. Other authors please=20 What was the reason? > correct me if my memory is faulty here. Also, as I mentioned=20 > in a previous=20 > post, anycast/IKEv2 is a change in key agreement, which is a=20 > much more=20 > serious and deep change in the security protocol than=20 > MIP6_HOME_PREFIX.=20 > Therefore, it makes perfect sense to me to spend more time on=20 > making sure it=20 > is right. As I said, fact is that the authors of the draft and the WG already spent quite some time (almost 2 years) on this, talked to IKE/Ipsec experts, and appearently all of them felt that the protocol is right. Otherwise the draft would not have passed WGLC and AD review.=20 Anyway, I have problems to understand your concerns, since you haven't described a specific security issue. If you have a specific issue in mind, can you please describe the specific threat and issue and how it can occur in the current protocol?=20 Please note that - due to the mandated cookie exchange, there are two subsequent IKE_SA_INIT request/reply exchanges. Only the IKE_SA_INIT request message of the initial IKE_SA_INIT exchange is anycasted and any following IKEv2 message (IKE_SA_INIT reply, request, reply, IKE_AUTH etc) is sent by unicast. - hence, a full RFC 4306 IKEv2 key exchange is done, which only comprise unicast messages and two parties only.=20 - the anycasted initial IKE_SA_INIT msg is forwarded between two HAs *located on the same link*, i.e., the route taken by the IKE_SA_INIT msg is the same in case of unicast and anycast (MN->home link) and no new potential locations for on-path attackers are introduced. - Since an IKE_SA_INIT request is not a protected message, it can be spoofed/eavesdropped/replayed/modified/forwarded/etc by anyone anyway, no matter if sent by unicast or anycast.=20 >=20 > So if it is only about broadening the applicability, how about a > compromise in this special case: We keep the anycast IKE mechanism in > the split scenario draft (to avoid delay in standardization) and in > parallel pursue a generalized IKEv2 anycast extension in a=20 > new document. > When this is completed, we can replace the text in the split scenario > bootstrapping document (in a bis version) with a reference to the > generalized version. We could do the same with the stateless address > autoconfiguration of a remote address mechanism. >=20 > jak>> I disagree with this. There is, as I said, no=20 > compelling deployment=20 > reason that bootstrapping needs to be standardized right away=20 > (though I=20 > personally would really like to see this work *done* and=20 > published). Also,=20 > regarding your comment that I supported this extension, it=20 > was only "consent=20 > by silence", and that only in public. I have always believed that=20 > bootstrapping without anycast/IKEv2 would be useful in and of=20 > itself, and at=20 > the time adding anycast/IKEv2 was under consideration, we=20 > exchanged email=20 > among you, Francis, the other authors, and me about this. I=20 > have always had=20 > some concerns about it but was willing to forgo airing them=20 > since the WG=20 > seemed to be behind it, and because I couldn't quite=20 > articulate why I was=20 > uneasy. Recently, spending more of my time reviewing security=20 > protocols for=20 > some other work I am doing, I've come to appreciate how=20 > difficult it is to=20 > get security protocols right, and how important it is to=20 > spend the proper=20 > amount of time in reviewing them, especially protocols like=20 > key agreement=20 > upon which the security of future transactions is based. I'm=20 > glad that the=20 > IESG has decided to raise this DISCUSS, though I wish Sam's=20 > comments had=20 > been more technicallly directed rather that saying "MIP6=20 > shouldn't do this"=20 > which, to me, sounds like a juicy invitation for people in=20 > the MIP6 WG to=20 > push back. Finally, I think incuding this in the=20 > bootstrapping draft then=20 > later standardizing a general version is not a good idea,=20 > since it could=20 > result in deployed systems with serious security bugs, if=20 > some bug is found=20 Note that I had the condition "if it is only about broadening the applicability" in my sentence above...=20 > in the initial version (reference: the WEP Catastrophe in 802.11). >=20 > jak>> If you care so much about this, why don't you write a=20 > draft right now=20 > sectioning off the anycast/IKEv2 protocol, submit it by the=20 > Monday deadline,=20 > and put it up for discussion in a security WG in Chicago? I'm=20 > sure Sam and=20 > Jari would be happy to assist getting you set up with the=20 > proper venue,=20 > since they are requesting that it be removed. Jean-Michel raised already some concerns. Another concern is that I'm not sure if there are enough people willing to spent time and energy in standardizing this generalized version. I myself probably won't. What is the motivation for the MIP6 people to again spent time and energy on this? They already have developed a solution, which was agreed by the WG to be standardized. So ideally this should be driven by people from the IKEv2 community. But are there enough people from this community that want to spent time and energy on this? Appearently they have not had a need for such a solution so far... Kilian 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 Thu Jun 28 07:34: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 1I3sGP-0003v5-95; Thu, 28 Jun 2007 07:34:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3sGN-0003v0-Lm for mip6@ietf.org; Thu, 28 Jun 2007 07:34:15 -0400 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3sGB-0000N9-Ir for mip6@ietf.org; Thu, 28 Jun 2007 07:34:15 -0400 Received: by nz-out-0506.google.com with SMTP id n1so46249nzf for ; Thu, 28 Jun 2007 04:34:03 -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=ED+sIoyEL8blDk/NEaBNa1hn0MsESliGAdUUyZC683TWdWzWs+J5GRZrznuVl0qSOsiuN3w83A60J16ZmXl85l0mn9rTxcFMGL/Qt/EE+rummimR/kJWpMIMvSx1txCsx05sq39qhF4OUsAT6hTQ5G5FMB9SP/HkGS+ueywtJ+w= 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=BIcFsHzdTeuHdEJNEGfplQfMMxzAaNsQaaWf/XVZZUYYQ8kwjnKcU1Pf2GtrEeGzBJtYwlwcNwUze8c8wiP9rTKJegp0Q4XBBbfjp/R0VHHkQQ3IdcgtRu0/dz7m1hWMQHLzWXFOZHEH/V0nZfldbrurXYYlLM4PSNoKzkKfciw= Received: by 10.141.146.11 with SMTP id y11mr379232rvn.1183030442563; Thu, 28 Jun 2007 04:34:02 -0700 (PDT) Received: from ?203.178.143.253? ( [203.178.143.253]) by mx.google.com with ESMTP id k2sm12117472rvb.2007.06.28.04.34.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jun 2007 04:34:01 -0700 (PDT) In-Reply-To: <46647E44.6030000@hp.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C3F@zrc2hxm2.corp.nortel.com> <46647E44.6030000@hp.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: [Mip6] Consensus call: Make I-D draft-haley-mip6-mh-signaling-02.txt a WG doc Date: Thu, 28 Jun 2007 20:33:56 +0900 To: Brian Haley X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: Mobile IPv6 Mailing List , ext 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 Brian and Ahmad, The MH Signaling Request/Ack Message are deprecated, and you introduce a new Generic Notification message, right? I am basically fine with this. However, the last Vijay's comment is valid. We cannot carry multiple messages in the same MH message. Why not using option-type of the MH option, instead of GNM Type/Sub- type? draft-haley defines a MH type value for the generic notification message and defines two MH options for signaling request and reply. regards, ryuji On 2007/06/05, at 6:04, Brian Haley wrote: > Hi Raj, > > Ahmad, Sri and I have talked off-line about how to go forward with > draft-haley and support draft-muhanna better. We've come to the > following conclusion (someone update if I got this wrong). > > Draft-haley will define a Generic Notification Message (GNM) which > is a new MH type, and also define two new sub-types - one for > Signaling Request, one for Signaling Reply (or some wording like > that). > > The structures would look something like this: > > Generic Notification Message (w/MH message pieces, MH Type TBD) > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > | Payload Proto | Header Len | MH Type | > Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > | Checksum | GNM Type/Sub- > Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > > In essence, the message is just a container to transport > notification messages between mobility entities. > > They we'd define two Sub-types with the same semantics of the > current messages in draft-haley: > > Signaling Request (GNM Type TBD): > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > | Sequence Number |A| > Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > > Signaling Reply (GNM Type TBD): > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > | Sequence Number | Status | > Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > > This would give someone that wants to use the semantics of the > Signaling Messages an easy framework for implentation (sequencing, > retransmission, etc). All they would have to do is define a > mobility option with their data to go "inside". > > Ahmad would define a new GNM Sub-type for revocation, and whatever > structures and options to go with it. > > I'll update draft-haley with these changes if there are no objections. > > Thanks to Ahmad for the suggestions. > > -Brian > > > Ahmad Muhanna wrote: >> Hello, >> My understanding that the scope of draft-haley is as follows: >> o A generic container which can be used to communicate >> multiple functionalities while preserving the MH types. >> o Introduce a Generic Notification Messages and Generic Notification >> mechanism that can be used to communicate several common >> notification event(s) >> between the HA and the MN. >> Having said that, I would like to propose a small change to the >> current Draft-haley revision 02 which would hopefully enrich and >> enhance the >> draft. >> The following summarize the proposed changes: >> ============================================= >> 1. Define the first two bytes, of the current generic >> notification >> message, and call them , for example, Generic Mobility >> Container, >> GMC, or XYZ. >> 2. The Generic Mobility Container is 2 bytes length and can >> have up >> to 64k >> different values which we can call, for example, GMC Type. >> i.e. >> Generic Notification Request message, Generic Notification >> Ack, >> Binding Revocation Indication message, Binding Revocation Ack, >> etc. >> 3. Every common functionality defines its own messages and >> mechanism >> including its own mechanism as fits the need of the specified >> functionality. >> 4. Any functionality, e.g. Generic Notification, may define >> the use of any MH option inside its own messages or define >> new ones. >> Here is the format, let us use the Generic Notification and >> Binding Revocation as examples: >> 1. Generic Mobility Container Message >> ===================================== This Signaling Generic >> Mobility Container Message uses the MH Type value >> (TBD). >> +-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> | GMC >> Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> >> | | >> . >> . >> . Message >> Data . >> . >> . >> >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> 2. Generic Notification >> ======================= >> Let us assume that this application requires two messages, a >> Request and >> an acknowledgement. >> 3.1. Generic Notification Request >> ================================== >> This Generic Notification Request uses a GMC Type of (TBD). >> +-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> | GMC >> Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> >> | | >> . >> . >> . Generic Notification >> Request . >> . >> . >> >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> 3.2. Generic Notification Ack >> ============================== >> This Generic Notification Ack uses a GMC Type of (TBD). >> +-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> | GMC >> Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> >> | | >> . >> . >> . Generic Notification >> Ack . >> . >> . >> >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> 3. Binding Revocation >> ====================== >> The following are the revocation messages that are defined by >> the Binding Revocation Functionality as specified by the Binding >> Revocation for IPv6 Mobility draft. >> 2.1. Binding Revocation Indication >> ================================== >> This Binding Revocation Indication uses a GMC Type of (TBD). >> +-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> | GMC >> Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> >> | | >> . >> . >> . Binding Revocation >> Indication . >> . >> . >> >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> 2.2. Binding Revocation Acknowledgement >> ======================================== >> This Binding Revocation Acknowledgement uses a GMC Type (TBD). >> +-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> | GMC >> Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> >> | | >> . >> . >> . Binding Revocation >> Acknowledgement . >> . >> . >> >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> Finally and as a suggestion, I would like to suggest that draft-haley >> address two things: >> 1. Introducing the Generic Mobility Container, GMC. >> 2. Define the Generic Notification Messages and the related >> Mechanism. >> While the Binding Revocation for IPv6 Mobility draft can define the >> Binding Revocation messages and the binding revocation mechanism. >> Best Regards, >> Ahmad >>> -----Original Message----- >>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] Sent: >>> Wednesday, May 30, 2007 12:23 PM >>> To: Mobile IPv6 Mailing List >>> 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 >>> >>> >>> Hello, >>> >>> At the Prague IETF (IETF68), the MIP6 WG discussed the following >>> I-D: >>> Mobility Header Signaling Message >> signaling-02.txt> >>> >>> 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 >>> >> _______________________________________________ >> 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 Jun 28 07:58: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 1I3sdl-0004a6-9l; Thu, 28 Jun 2007 07:58:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3sdk-0004Zu-5J for mip6@ietf.org; Thu, 28 Jun 2007 07:58:24 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3sdg-0006XZ-Rb for mip6@ietf.org; Thu, 28 Jun 2007 07:58:24 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 04:58:20 -0700 Message-ID: <4683A25A.6060707@azairenet.com> Date: Thu, 28 Jun 2007 04:58:18 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [Mip6] Consensus call: Make I-D draft-haley-mip6-mh-signaling-02.txt a WG doc References: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C3F@zrc2hxm2.corp.nortel.com> <46647E44.6030000@hp.com> <46832284.5080402@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jun 2007 11:58:20.0364 (UTC) FILETIME=[9F0920C0:01C7B97B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Mobile IPv6 Mailing List , Brian Haley 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: > Vijay, > >> >> I have an objection. I would like to use the existing format of having >> a generic signaling message and using mobility options to carry the >> actual information. The above format has one drawback, in the sense >> that you can't carry more than piece of information since you use the >> subtype field to indicate what you are carrying. When you use mobility >> options, you don't really have that restriction. You can chain any >> number of mobility options. >> > > The addition of sub-type does not disallow the addition of > mobility options. It provides more flexibility for defining > messages with a fixed format where it cannot be expressed > or not suitable for expressing it as an option. Options are > suitable for carrying a fixed fields, such as HoA, NAI ..etc. > So, we can still do the same of chaining multiple options for > the same sub-type. But, the subtype already tells you what the notification is about. You obviously cannot include another mobility option that carries information unrelated to the notification. I am not suggesting the use of options to carry information just to identify which home address or the NAI the information is related to. We already have mobility options that can carry this information. You just need to include them in this message. I am am talking about the use of mobility option to carry the actual contents of the notification message. This is what the earlier version of the draft was talking about. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 28 11:12: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 1I3vfj-00039g-Qs; Thu, 28 Jun 2007 11:12:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3vfi-00039a-IQ for mip6@ietf.org; Thu, 28 Jun 2007 11:12:38 -0400 Received: from atlrel6.hp.com ([156.153.255.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3vfi-0006Tr-DC for mip6@ietf.org; Thu, 28 Jun 2007 11:12:38 -0400 Received: from smtp2.fc.hp.com (smtp.cnd.hp.com [15.11.136.114]) by atlrel6.hp.com (Postfix) with ESMTP id 7A62C377AC; Thu, 28 Jun 2007 11:11:31 -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 8FAA818BE65; Thu, 28 Jun 2007 15:11:30 +0000 (UTC) Message-ID: <4683CFA1.8010609@hp.com> Date: Thu, 28 Jun 2007 11:11:29 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Consensus call: Make I-D draft-haley-mip6-mh-signaling-02.txt a WG doc References: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C3F@zrc2hxm2.corp.nortel.com> <46647E44.6030000@hp.com> <46832284.5080402@azairenet.com> <4683A25A.6060707@azairenet.com> In-Reply-To: <4683A25A.6060707@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Mobile IPv6 Mailing List , 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 Vijay Devarapalli wrote: > But, the subtype already tells you what the notification is about. > You obviously cannot include another mobility option that carries > information unrelated to the notification. We can define a sub-type (0) in the draft that says there is no specific information here, you must parse the options separately. Is that ok? -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 28 11:46: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 1I3wCf-00050T-P5; Thu, 28 Jun 2007 11:46:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3wCe-00050D-6m for mip6@ietf.org; Thu, 28 Jun 2007 11:46:40 -0400 Received: from s-utl02-atpop.stsn.net ([72.254.128.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3wCP-0000h5-Iq for mip6@ietf.org; Thu, 28 Jun 2007 11:46:40 -0400 Received: from s-utl02-atpop.stsn.net ([127.0.0.1]) by s-utl02-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007062811461711258 ; Thu, 28 Jun 2007 11:46:17 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: -1.292,BAYES_00: -1.665, SARE_SUB_DOUBLE_CONS: 1.111,SARE_SUB_RAND_LETTRS2: 1.666 X-Spam-Level: Received: from [127.0.0.1] ([10.86.115.79]) by s-utl02-atpop.stsn.net; Thu, 28 Jun 2007 11:46:16 -0400 Message-ID: <4683D7B9.8050105@azairenet.com> Date: Thu, 28 Jun 2007 08:46:01 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Brian Haley Subject: Re: [Mip6] Consensus call: Make I-D draft-haley-mip6-mh-signaling-02.txt a WG doc References: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C3F@zrc2hxm2.corp.nortel.com> <46647E44.6030000@hp.com> <46832284.5080402@azairenet.com> <4683A25A.6060707@azairenet.com> <4683CFA1.8010609@hp.com> In-Reply-To: <4683CFA1.8010609@hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Mobile IPv6 Mailing List , 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 Brian Haley wrote: > Vijay Devarapalli wrote: >> But, the subtype already tells you what the notification is about. >> You obviously cannot include another mobility option that carries >> information unrelated to the notification. > > We can define a sub-type (0) in the draft that says there is no specific > information here, you must parse the options separately. Is that ok? Yes, this will work. But why wouldn't this be the default for all notification messages? The mobility option tells us what the notification is about. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 28 13:49: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 1I3y7Q-00010G-JG; Thu, 28 Jun 2007 13:49:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3y7P-00010B-NE for mip6@ietf.org; Thu, 28 Jun 2007 13:49:23 -0400 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3y6n-0005wW-JC for mip6@ietf.org; Thu, 28 Jun 2007 13:49:23 -0400 Received: by nz-out-0506.google.com with SMTP id n1so157255nzf for ; Thu, 28 Jun 2007 10:48:45 -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=sJIoI+C3D0jV/JoiBddIHwxYzzE0JpAdGDz7MKQARUMY5X3sEQngt8cG2BuDW/qMZhw25+GpLqmc9ectHwtngnZj0rt9egzDKBW48CaGC/CdBXvGLIPQO2nSheFoW1/gz942dKcsnVCEIWa9jmYN8TrBY12MtQaFsywtFdWTqVM= 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=ZMrEzUaPIRIo2lrfR66NSaXhG+7m7wtahNbiOwSrE7ywBtC8VP22urqwzF1LA80Tv9PblC5kFvQPs9Gf2kewQYK4zW3wnrFwrLUvgFz3AXVlSBgiaDb7aAR4bk4YbWLyyxE6l4fv88POnoCaCshyxbpM3dxDUmRhFGo51QRjhSQ= Received: by 10.141.29.18 with SMTP id g18mr464636rvj.1183052924843; Thu, 28 Jun 2007 10:48:44 -0700 (PDT) Received: from ?203.178.143.253? ( [203.178.143.253]) by mx.google.com with ESMTP id g39sm12642918rvb.2007.06.28.10.48.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jun 2007 10:48:43 -0700 (PDT) In-Reply-To: <46647E44.6030000@hp.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437114A72C3F@zrc2hxm2.corp.nortel.com> <46647E44.6030000@hp.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <33096509-5B6B-404E-9CC5-3731816AB7AA@gmail.com> Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [Mip6] Consensus call: Make I-D draft-haley-mip6-mh-signaling-02.txt a WG doc Date: Fri, 29 Jun 2007 02:48:38 +0900 To: Brian Haley X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Cc: Mobile IPv6 Mailing List , ext 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 Brian and Ahmad, I was a bit confused about two different names (GNM type and sub- type) for the same field in the figure. I'm basically fine with this approach. Thanks Ahmad to correct me. regards, ryuji On 2007/06/05, at 6:04, Brian Haley wrote: > Hi Raj, > > Ahmad, Sri and I have talked off-line about how to go forward with > draft-haley and support draft-muhanna better. We've come to the > following conclusion (someone update if I got this wrong). > > Draft-haley will define a Generic Notification Message (GNM) which > is a new MH type, and also define two new sub-types - one for > Signaling Request, one for Signaling Reply (or some wording like > that). > > The structures would look something like this: > > Generic Notification Message (w/MH message pieces, MH Type TBD) > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > | Payload Proto | Header Len | MH Type | > Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > | Checksum | GNM Type/Sub- > Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > > In essence, the message is just a container to transport > notification messages between mobility entities. > > They we'd define two Sub-types with the same semantics of the > current messages in draft-haley: > > Signaling Request (GNM Type TBD): > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > | Sequence Number |A| > Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > > Signaling Reply (GNM Type TBD): > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > | Sequence Number | Status | > Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > > This would give someone that wants to use the semantics of the > Signaling Messages an easy framework for implentation (sequencing, > retransmission, etc). All they would have to do is define a > mobility option with their data to go "inside". > > Ahmad would define a new GNM Sub-type for revocation, and whatever > structures and options to go with it. > > I'll update draft-haley with these changes if there are no objections. > > Thanks to Ahmad for the suggestions. > > -Brian > > > Ahmad Muhanna wrote: >> Hello, >> My understanding that the scope of draft-haley is as follows: >> o A generic container which can be used to communicate >> multiple functionalities while preserving the MH types. >> o Introduce a Generic Notification Messages and Generic Notification >> mechanism that can be used to communicate several common >> notification event(s) >> between the HA and the MN. >> Having said that, I would like to propose a small change to the >> current Draft-haley revision 02 which would hopefully enrich and >> enhance the >> draft. >> The following summarize the proposed changes: >> ============================================= >> 1. Define the first two bytes, of the current generic >> notification >> message, and call them , for example, Generic Mobility >> Container, >> GMC, or XYZ. >> 2. The Generic Mobility Container is 2 bytes length and can >> have up >> to 64k >> different values which we can call, for example, GMC Type. >> i.e. >> Generic Notification Request message, Generic Notification >> Ack, >> Binding Revocation Indication message, Binding Revocation Ack, >> etc. >> 3. Every common functionality defines its own messages and >> mechanism >> including its own mechanism as fits the need of the specified >> functionality. >> 4. Any functionality, e.g. Generic Notification, may define >> the use of any MH option inside its own messages or define >> new ones. >> Here is the format, let us use the Generic Notification and >> Binding Revocation as examples: >> 1. Generic Mobility Container Message >> ===================================== This Signaling Generic >> Mobility Container Message uses the MH Type value >> (TBD). >> +-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> | GMC >> Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> >> | | >> . >> . >> . Message >> Data . >> . >> . >> >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> 2. Generic Notification >> ======================= >> Let us assume that this application requires two messages, a >> Request and >> an acknowledgement. >> 3.1. Generic Notification Request >> ================================== >> This Generic Notification Request uses a GMC Type of (TBD). >> +-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> | GMC >> Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> >> | | >> . >> . >> . Generic Notification >> Request . >> . >> . >> >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> 3.2. Generic Notification Ack >> ============================== >> This Generic Notification Ack uses a GMC Type of (TBD). >> +-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> | GMC >> Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> >> | | >> . >> . >> . Generic Notification >> Ack . >> . >> . >> >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> 3. Binding Revocation >> ====================== >> The following are the revocation messages that are defined by >> the Binding Revocation Functionality as specified by the Binding >> Revocation for IPv6 Mobility draft. >> 2.1. Binding Revocation Indication >> ================================== >> This Binding Revocation Indication uses a GMC Type of (TBD). >> +-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> | GMC >> Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> >> | | >> . >> . >> . Binding Revocation >> Indication . >> . >> . >> >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> 2.2. Binding Revocation Acknowledgement >> ======================================== >> This Binding Revocation Acknowledgement uses a GMC Type (TBD). >> +-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> | GMC >> Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> >> | | >> . >> . >> . Binding Revocation >> Acknowledgement . >> . >> . >> >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> Finally and as a suggestion, I would like to suggest that draft-haley >> address two things: >> 1. Introducing the Generic Mobility Container, GMC. >> 2. Define the Generic Notification Messages and the related >> Mechanism. >> While the Binding Revocation for IPv6 Mobility draft can define the >> Binding Revocation messages and the binding revocation mechanism. >> Best Regards, >> Ahmad >>> -----Original Message----- >>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] Sent: >>> Wednesday, May 30, 2007 12:23 PM >>> To: Mobile IPv6 Mailing List >>> 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 >>> >>> >>> Hello, >>> >>> At the Prague IETF (IETF68), the MIP6 WG discussed the following >>> I-D: >>> Mobility Header Signaling Message >> signaling-02.txt> >>> >>> 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 >>> >> _______________________________________________ >> 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 Jun 28 14:30: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 1I3yl5-00007r-8K; Thu, 28 Jun 2007 14:30:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3yl3-00006a-HL for mip6@ietf.org; Thu, 28 Jun 2007 14:30:21 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3yke-00089m-4e for mip6@ietf.org; Thu, 28 Jun 2007 14:30:21 -0400 Message-ID: <0ee501c7b9b2$52622730$576115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Kilian Weniger" , "Jari Arkko" References: <4680D95F.10403@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de><0a8e01c7b811$f95b8d30$576115ac@dcml.docomolabsusa.com><4681590C.6010904@azairenet.com><0b0301c7b821$f1cec540$576115ac@dcml.docomolabsusa.com><46816254.1020306@azairenet.com><0b1801c7b828$4fb40930$576115ac@dcml.docomolabsusa.com><46816A07.50903@azairenet.com> <0b3601c7b82b$43257020$576115ac@dcml.docomolabsusa.com> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A9B@lan-ex-02.panasonic.de> <46821CFA.5050106@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9AB7@lan-ex-02.panasonic.de> <0c6f01c7b8dc$b5850ca0$576115ac@dcml.docomolabsusa.com> <1FEB9B9F2EC38343955D02B2AE86AACB2E9B96@lan-ex-02.panasonic.de> Subject: Re: *** Possibly SPAM *** Re: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature Date: Thu, 28 Jun 2007 11:29:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org, Mobile IPv6 Mailing List , Sam Hartman , Brian E Carpenter 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 Why is it specific to MIPv6? I guess stateless address autoconfiguration of a remote address is something that could also be useful for other applications and scenarios, e.g., using CGAs or privacy addresses in a VPN scenario, right? jak>> Because the network operator of a VPN gateway in a typical VPN deployment wants the gateway, not the host, to control the address allocation. For a VPN application, why would the gateway want to allow the host to autogenerate the address? VPN gateways are not deployed on networks where hosts can connect, they are deployed in the middle of a corporate network on a subnet with no end hosts, so there is no question of wanting hosts on the "home" network as in MIP6 to autoconfigure an address that can be defended using CGA. So autoconfiguration is not a general feature that would appeal to all IKEv2 users, it is specific to MIP6. > we talked with someone in SAAG about this at the time we were > considering > putting it into a separate draft, and we were told to include > it in the > bootstrapping draft rather than separate it out. Other authors please What was the reason? jak>> See above. > correct me if my memory is faulty here. Also, as I mentioned > in a previous > post, anycast/IKEv2 is a change in key agreement, which is a > much more > serious and deep change in the security protocol than > MIP6_HOME_PREFIX. > Therefore, it makes perfect sense to me to spend more time on > making sure it > is right. As I said, fact is that the authors of the draft and the WG already spent quite some time (almost 2 years) on this, talked to IKE/Ipsec experts, and appearently all of them felt that the protocol is right. Otherwise the draft would not have passed WGLC and AD review. jak>> Killian, this feature was added in the last 6 months of the draft after you and Francis raised the issue, in fact, I think it was raised during WGLC if I recall. At that point, everybody (including me) just wanted to get the thing done. I don't think anyone can really say that there has been extensive review of this feature. Most people in the WG had checked out by that time. Anyway, I have problems to understand your concerns, since you haven't described a specific security issue. If you have a specific issue in mind, can you please describe the specific threat and issue and how it can occur in the current protocol? jak>> I've made these concerns abundently clear in my previous posts. I'll reiterate them here: jak>> 1) The feature involves modifying the key provisioning protocol, which is a fundamental security feature that, if compromised, can result in compromise of all future security transactions. In order to avoid a possible WEP Catastrophe, it makes sense to seperate out the feature into a standalone document and subject that to extensive review over a longer period of time. jak>> 2) The feature is one that is not specific to MIP6, and would be widely useful for many IKEv2 uses. Therefore, it makes sense to standardize it as a separate extension to IKE, rather than burying it at the end of an obscure MIP6 enhancement document. jak>> I really wish Sam and Jari had been more clear about the IESG's objections, and would argue them for themselves. I don't particularly like doing IESG's dirty work, but I do think they have a point here. Please note that - due to the mandated cookie exchange, there are two subsequent IKE_SA_INIT request/reply exchanges. Only the IKE_SA_INIT request message of the initial IKE_SA_INIT exchange is anycasted and any following IKEv2 message (IKE_SA_INIT reply, request, reply, IKE_AUTH etc) is sent by unicast. - hence, a full RFC 4306 IKEv2 key exchange is done, which only comprise unicast messages and two parties only. - the anycasted initial IKE_SA_INIT msg is forwarded between two HAs *located on the same link*, i.e., the route taken by the IKE_SA_INIT msg is the same in case of unicast and anycast (MN->home link) and no new potential locations for on-path attackers are introduced. - Since an IKE_SA_INIT request is not a protected message, it can be spoofed/eavesdropped/replayed/modified/forwarded/etc by anyone anyway, no matter if sent by unicast or anycast. jak>> Right, we discussed this. I still think it make sense to have more people look at this over a longer period of time. Experience with security protocols has shown that the more people that look at it, the more bugs are found. Jean-Michel raised already some concerns. Another concern is that I'm not sure if there are enough people willing to spent time and energy in standardizing this generalized version. I myself probably won't. What is the motivation for the MIP6 people to again spent time and energy on this? They already have developed a solution, which was agreed by the WG to be standardized. So ideally this should be driven by people from the IKEv2 community. But are there enough people from this community that want to spent time and energy on this? Appearently they have not had a need for such a solution so far... jak>> Well, what about you? Personally, if I had something like this that I really cared about, I'd much rather see it standardized as a general feature available to all IKEv2 users rather than buried at the end of an obscure enhancement to another protocol. And I would also want to know that it was reviewed by enough people to have some confidence that it is right. The ADs should be ready to help, since they are the ones insisting that it be removed. As for what WG to be standardized, that should be discussed with the ADs, but maybe it could be done through SAAG, like TLS over UDP was. It only takes one person who really cares about the protocol and is willing to do the work to make it happen. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 28 14:42: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 1I3yx7-00075i-R1; Thu, 28 Jun 2007 14:42:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3yx5-00071v-Sf for mip6@ietf.org; Thu, 28 Jun 2007 14:42:48 -0400 Received: from wx-out-0506.google.com ([66.249.82.226]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3yx5-0006P9-GO for mip6@ietf.org; Thu, 28 Jun 2007 14:42:47 -0400 Received: by wx-out-0506.google.com with SMTP id h27so534446wxd for ; Thu, 28 Jun 2007 11:41:51 -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; b=aUgQxsZruII9QCdEFhWhKXsv+LK6CcBL2Q0Ld5QHW0+c8sAIidrANsJrHUrePKIumUOVideLyynhB2acC8vBVmWDSO8tKNKlJnhZGwtBLBPddm33b6Gp/9t0gAIuxDe2x7UJoeMS5YPrh/YPDie/FlWi2jXVAU5SAzJyulKFvMw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=ngwRVLFXk1g0iIItfYnQYaHAZnEA3BLURVTk8imdahQTAmgU8Gn8czAHIM4iYKyyK0ruNhwRk7OmC+xSVlC/m5nEW2dyTI4hSyn+Kt2jYScrwpkhjYNv53twzh7kzIsNRxOALzlaoJyhaMNjNPY8bdY0ivg/odErv3FfjrHTx5U= Received: by 10.70.39.5 with SMTP id m5mr3302360wxm.1183056107604; Thu, 28 Jun 2007 11:41:47 -0700 (PDT) Received: by 10.70.20.17 with HTTP; Thu, 28 Jun 2007 11:41:47 -0700 (PDT) Message-ID: <18a603a60706281141q37f41b26g40a1f21807cd1ddb@mail.gmail.com> Date: Thu, 28 Jun 2007 20:41:47 +0200 From: "Pars Mutaf" To: "Mobile IPv6 Mailing List" MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [Mip6] Invitation to humanresolvers 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="===============0218507163==" Errors-To: mip6-bounces@ietf.org --===============0218507163== Content-Type: multipart/alternative; boundary="----=_Part_9895_27044392.1183056107578" ------=_Part_9895_27044392.1183056107578 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear all, This is an invitation to the "humanresolvers" mailing list created for investigating the "IP pairing" problem for personal mobile devices. Our goal is to understand and formally describe the problem, identify the engineering problems and if there is interest, go for a BoF when ready. If you have any ideas for better shaping the problem please don't hesitate. Regards, pars ps: I'll also invite other folks from other WGs but I prefered starting with a single ML which is MIPv6. Responses are welcome. Otherwise please subscribe to the humanresolvers ML, it is free as in free beer :-) ------------------------- "IP Pairing" for personal mobile IPv6 devices Mailing list info: https://www1.ietf.org/mailman/listinfo/humanresolvers This mailing list is intended for discussions around the "IP pairing" problem for personal mobile IPv6 devices e.g. cellular phones. IP pairing is an abstract IP-layer device pairing protocol. It can work over any technology and over long distances (i.e. through the Internet). IP pairing will allow two Mobile IPv6 devices to: 1. exchange their home addresses and 2. create an IPsec security association (using IKEv2) _if accepted_ by the user. That is, some user intervention is introduced to help the user control (i.e. accept or deny) a pairing request coming another user's mobile device. For example, the target device may display a message: Device pairing initiated by John Hoffman. Accept? [Yes/No] A home address will be returned and IKEv2 initiation will be accepted if approved by the user (pushing on the YES button of his phone). Consequently, the user can distribute a Mobile IPv6 home address (and possibly other private information e.g. SIP URI) to trusted parties; under his/her control and in real-time. By the same procedure, the user can also control who is establishing IPsec security associations with his/her mobile device. This approach is radically different from the client/server model which assumes obtaining the target devices's home address from DNS (without target user's authorization) and creating an IPsec security association (without target user's authorization). NOTICE: To give some additional ideas, an alternate take of this problem statement (from phone number or SIP URI and home address perspective) was made in: http://www.ietf.org/internet-drafts/draft-mutaf-piqproblem-01.txt ------=_Part_9895_27044392.1183056107578 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline  
Dear all,
 
This is an invitation to the "humanresolvers" mailing list created for
investigating the "IP pairing" problem for personal mobile devices.
Our goal is to understand and formally describe the problem, identify the
engineering problems and if there is interest, go for a BoF when ready.

If you have any ideas for better shaping the problem please don't
hesitate.
 
Regards,
 
pars

ps: I'll also invite other folks from other WGs but I prefered
starting with a single ML which is MIPv6. Responses are welcome.
Otherwise please subscribe to the humanresolvers ML, it is free
as in free beer :-)

 
-------------------------
 
              "IP Pairing" for personal mobile IPv6 devices
 
 Mailing list info:  
   https://www1.ietf.org/mailman/listinfo/humanresolvers
 
 This mailing list is intended for discussions around the "IP pairing"
 problem for personal mobile IPv6 devices e.g. cellular phones.
 IP pairing is an abstract IP-layer device pairing protocol. It can work
 over any technology and over long distances (i.e. through the Internet).
 IP pairing will allow two Mobile IPv6 devices to:  
 
      1. exchange their home addresses and
      2. create an IPsec security association (using IKEv2)
 
  _if accepted_ by the user.  
 
  That is, some user intervention is introduced to help the user control
  (i.e. accept or deny) a pairing request coming another user's mobile
  device. For example, the target device may display a message:
 
          Device pairing initiated by John Hoffman.  
           Accept? [Yes/No]
 
  A home address will be returned and IKEv2 initiation will be accepted
  if approved by the user (pushing on the YES button of his phone).
  Consequently, the user can distribute a Mobile IPv6 home address (and
  possibly other private information e.g. SIP URI) to trusted parties;  
  under his/her control and in real-time. By the same procedure, the user
  can also control who is establishing IPsec security associations with
  his/her mobile device.
 
  This approach is radically different from the client/server model which
  assumes obtaining the target devices's home address from DNS (without
  target user's authorization) and creating an IPsec security association
  (without target user's authorization).
 
  NOTICE: To give some additional ideas, an alternate take of this problem
               statement (from phone number or SIP URI and home address
               perspective) was made in:
 
  http://www.ietf.org/internet-drafts/draft-mutaf-piqproblem-01.txt

    
 
 

------=_Part_9895_27044392.1183056107578-- --===============0218507163== 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 --===============0218507163==-- From mip6-bounces@ietf.org Thu Jun 28 20: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 1I44jo-00011j-Fl; Thu, 28 Jun 2007 20:53:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I44jm-0000xK-Ti for mip6@ietf.org; Thu, 28 Jun 2007 20:53:26 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I44jm-0000sZ-8S for mip6@ietf.org; Thu, 28 Jun 2007 20:53:26 -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 l5T0pw9t001377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Jun 2007 17:51:58 -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 l5T0ps2K023980; Thu, 28 Jun 2007 17:51:57 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 17:51:56 -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] bootstrapping-splitanycast/ikev2 ha selection feature Date: Thu, 28 Jun 2007 17:52:07 -0700 Message-ID: In-Reply-To: <0ee501c7b9b2$52622730$576115ac@dcml.docomolabsusa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Mip6] bootstrapping-splitanycast/ikev2 ha selection feature Thread-Index: Ace5s+YOMFg+p08QTICT98mmPmnNVAAMUhow References: <4680D95F.10403@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de><0a8e01c7b811$f95b8d30$576115ac@dcml.docomolabsusa.com><4681590C.6010904@azairenet.com><0b0301c7b821$f1cec540$576115ac@dcml.docomolabsusa.com><46816254.1020306@azairenet.com><0b1801c7b828$4fb40930$576115ac@dcml.docomolabsusa.com><46816A07.50903@azairenet.com><0b3601c7b82b$43257020$576115ac@dcml.docomolabsusa.com><1FEB9B9F2EC38343955D02B2AE86AACB2E9A9B@lan-ex-02.panasonic.de><46821CFA.5050106@piuha.net><1FEB9B9F2EC38343955D02B2AE86AACB2E9AB7@lan-ex-02.panasonic.de><0c6f01c7b8dc$b5850ca0$576115ac@dcml.docomolabsusa.com><1FEB9B9F2EC38343955D02B2AE86AACB2E9B96@lan-ex-02.panasonic.de> <0ee501c7b9b2$52622730$576115ac@dcml.docomolabsusa.com> From: "Narayanan, Vidya" To: "James Kempf" , "Kilian Weniger" , "Jari Arkko" X-OriginalArrivalTime: 29 Jun 2007 00:51:56.0059 (UTC) FILETIME=[B0F21EB0:01C7B9E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org, Mobile IPv6 Mailing List , Sam Hartman , Brian E Carpenter 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 just catching up with this thread. I do support the notion of separating out the anycast aspect to make it more generically an IKEv2 capability change, rather than in a specific MIP6 document. I don't think this is quite along the same lines of introducing new IKEv2 attributes to carry the home prefix, for instance. =20 However, I do share Jean-Michel's concern about the actual possibility of the work getting done independent of the MIP6 document. Note that I'm not as concerned about timeline in this particular case - as James pointed out, most SDOs have gone the way of the integrated scenario for HA discovery, as far as I know. The use of IKEv2 for obtaining home IP addresses is still being adopted, but, HA discovery via IKEv2 seems unlikely for immediate adoption.=20 That said, I'll also note that HA discovery using anycast in IKEv2 is a good way of doing it, in my view. So, I really believe we should support it - if there is commitment to doing a more generalized anycast-based discovery in IKEv2 as a separate activity, I'll support that. =20 Thanks, Vidya > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 > Sent: Thursday, June 28, 2007 11:30 AM > To: Kilian Weniger; Jari Arkko > Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org;=20 > Mobile IPv6 Mailing List; Sam Hartman; Brian E Carpenter > Subject: Re: *** Possibly SPAM *** Re: [Mip6]=20 > bootstrapping-splitanycast/ikev2 ha selection feature >=20 > Why is it specific to MIPv6? I guess stateless address=20 > autoconfiguration of a remote address is something that could=20 > also be useful for other applications and scenarios, e.g.,=20 > using CGAs or privacy addresses in a VPN scenario, right? >=20 > jak>> Because the network operator of a VPN gateway in a typical VPN > deployment wants the gateway, not the host, to control the=20 > address allocation. For a VPN application, why would the=20 > gateway want to allow the host to autogenerate the address?=20 > VPN gateways are not deployed on networks where hosts can=20 > connect, they are deployed in the middle of a corporate=20 > network on a subnet with no end hosts, so there is no=20 > question of wanting hosts on the "home" network as in MIP6 to=20 > autoconfigure an address that can be defended using CGA. So=20 > autoconfiguration is not a general feature that would appeal=20 > to all IKEv2 users, it is specific to MIP6. >=20 > > we talked with someone in SAAG about this at the time we were=20 > > considering putting it into a separate draft, and we were told to=20 > > include it in the bootstrapping draft rather than separate it out.=20 > > Other authors please >=20 > What was the reason? >=20 > jak>> See above. >=20 > > correct me if my memory is faulty here. Also, as I mentioned in a=20 > > previous post, anycast/IKEv2 is a change in key agreement,=20 > which is a=20 > > much more serious and deep change in the security protocol than=20 > > MIP6_HOME_PREFIX. > > Therefore, it makes perfect sense to me to spend more time=20 > on making=20 > > sure it is right. >=20 > As I said, fact is that the authors of the draft and the WG=20 > already spent quite some time (almost 2 years) on this,=20 > talked to IKE/Ipsec experts, and appearently all of them felt=20 > that the protocol is right. > Otherwise the draft would not have passed WGLC and AD review. >=20 > jak>> Killian, this feature was added in the last 6 months of=20 > the draft > after you and Francis raised the issue, in fact, I think it=20 > was raised during WGLC if I recall. At that point, everybody=20 > (including me) just wanted to get the thing done. I don't=20 > think anyone can really say that there has been extensive=20 > review of this feature. Most people in the WG had checked out=20 > by that time. >=20 > Anyway, I have problems to understand your concerns, since=20 > you haven't described a specific security issue. If you have=20 > a specific issue in mind, can you please describe the=20 > specific threat and issue and how it can occur in the current=20 > protocol? >=20 > jak>> I've made these concerns abundently clear in my previous posts.=20 > jak>> I'll > reiterate them here: >=20 > jak>> 1) The feature involves modifying the key provisioning=20 > protocol,=20 > jak>> which > is a fundamental security feature that, if compromised, can=20 > result in compromise of all future security transactions. In=20 > order to avoid a possible WEP Catastrophe, it makes sense to=20 > seperate out the feature into a standalone document and=20 > subject that to extensive review over a longer period of time. >=20 > jak>> 2) The feature is one that is not specific to MIP6, and would be > widely useful for many IKEv2 uses. Therefore, it makes sense=20 > to standardize it as a separate extension to IKE, rather than=20 > burying it at the end of an obscure MIP6 enhancement document. >=20 > jak>> I really wish Sam and Jari had been more clear about the IESG's > objections, and would argue them for themselves. I don't=20 > particularly like doing IESG's dirty work, but I do think=20 > they have a point here. >=20 > Please note that > - due to the mandated cookie exchange, there are two=20 > subsequent IKE_SA_INIT request/reply exchanges. Only the=20 > IKE_SA_INIT request message of the initial IKE_SA_INIT=20 > exchange is anycasted and any following IKEv2 message=20 > (IKE_SA_INIT reply, request, reply, IKE_AUTH > etc) is sent by unicast. > - hence, a full RFC 4306 IKEv2 key exchange is done, which=20 > only comprise unicast messages and two parties only. > - the anycasted initial IKE_SA_INIT msg is forwarded between=20 > two HAs *located on the same link*, i.e., the route taken by=20 > the IKE_SA_INIT msg is the same in case of unicast and=20 > anycast (MN->home link) and no new potential locations for=20 > on-path attackers are introduced. > - Since an IKE_SA_INIT request is not a protected message, it=20 > can be spoofed/eavesdropped/replayed/modified/forwarded/etc=20 > by anyone anyway, no matter if sent by unicast or anycast. >=20 > jak>> Right, we discussed this. I still think it make sense=20 > to have more > people look at this over a longer period of time. Experience=20 > with security protocols has shown that the more people that=20 > look at it, the more bugs are found. >=20 > Jean-Michel raised already some concerns. Another concern is=20 > that I'm not sure if there are enough people willing to spent=20 > time and energy in standardizing this generalized version. I=20 > myself probably won't. What is the motivation for the MIP6=20 > people to again spent time and energy on this? They already=20 > have developed a solution, which was agreed by the WG to be=20 > standardized. So ideally this should be driven by people from the > IKEv2 community. But are there enough people from this=20 > community that want to spent time and energy on this?=20 > Appearently they have not had a need for such a solution so far... >=20 > jak>> Well, what about you? Personally, if I had something like this=20 > jak>> that I > really cared about, I'd much rather see it standardized as a=20 > general feature available to all IKEv2 users rather than=20 > buried at the end of an obscure enhancement to another=20 > protocol. And I would also want to know that it was reviewed=20 > by enough people to have some confidence that it is right.=20 > The ADs should be ready to help, since they are the ones=20 > insisting that it be removed. As for what WG to be=20 > standardized, that should be discussed with the ADs, but=20 > maybe it could be done through SAAG, like TLS over UDP was.=20 > It only takes one person who really cares about the protocol=20 > and is willing to do the work to make it happen. >=20 > jak >=20 >=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 From mip6-bounces@ietf.org Fri Jun 29 04:50: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 1I4CBS-0000XM-Sf; Fri, 29 Jun 2007 04:50:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4CBR-0000XH-Ol for mip6@ietf.org; Fri, 29 Jun 2007 04:50:29 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4CBM-0001Fj-R4 for mip6@ietf.org; Fri, 29 Jun 2007 04:50:29 -0400 Received: from rly25b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly25b.srv.mailcontrol.com (MailControl) with ESMTP id l5T8oKAs002949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 29 Jun 2007 09:50:20 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly25b.srv.mailcontrol.com (MailControl) id l5T8neZI001176 for mip6@ietf.org; Fri, 29 Jun 2007 09:49:40 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly25b-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l5T8nbRr000942; Fri, 29 Jun 2007 09:49:40 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 30ad_0d557756_261c_11dc_94bb_0030482aac25; Fri, 29 Jun 2007 10:38:03 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007062910492889-188957 ; Fri, 29 Jun 2007 10:49:28 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.139,BAYES_00: -1.665,TOTAL_SCORE: -1.526 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Fri, 29 Jun 2007 10:47:29 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: *** Possibly SPAM *** Re: *** Possibly SPAM *** Re: [Mip6] bootstrapping-splitanycast/ikev2 ha selection feature In-Reply-To: <0ee501c7b9b2$52622730$576115ac@dcml.docomolabsusa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: *** Possibly SPAM *** Re: *** Possibly SPAM *** Re: [Mip6] bootstrapping-splitanycast/ikev2 ha selection feature Thread-Index: Ace5sntlCu2voDMKTAGmeARng3rLYQAbh65g References: <4680D95F.10403@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de><0a8e01c7b811$f95b8d30$576115ac@dcml.docomolabsusa.com><4681590C.6010904@azairenet.com><0b0301c7b821$f1cec540$576115ac@dcml.docomolabsusa.com><46816254.1020306@azairenet.com><0b1801c7b828$4fb40930$576115ac@dcml.docomolabsusa.com><46816A07.50903@azairenet.com><0b3601c7b82b$43257020$576115ac@dcml.docomolabsusa.com><1FEB9B9F2EC38343955D02B2AE86AACB2E9A9B@lan-ex-02.panasonic.de><46821CFA.5050106@piuha.net><1FEB9B9F2EC38343955D02B2AE86AACB2E9AB7@lan-ex-02.panasonic.de><0c6f01c7b8dc$b5850ca0$576115ac@dcml.docomolabsusa.com><1FEB9B9F2EC38343955D02B2AE86AACB2E9B96@lan-ex-02.panasonic.de> <0ee501c7b9b2$52622730$576115ac@dcml.docomolabsusa.com> To: "James Kempf" , "Kilian Weniger" , "Jari Arkko" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB2E9C9C@lan-ex-02.panasonic.de> Date: Fri, 29 Jun 2007 10:49:07 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-07-07-10 (www.mailcontrol.com) on 10.66.1.135 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org, Mobile IPv6 Mailing List , Sam Hartman , Brian E Carpenter 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 James,=20 I guess we have both made our opinions clear enough now to close this thread. I'm still in favour of the compromise (keep feature in split scenario draft and in parallel pursue a generalized version) because otherwise the standardization of the anycast feature for MIPv6 HA assignment may be significantly delayed or even aborted due to the various reasons Jean-Michel and I mentioned. And this discussion as well as the WG decisions in the past have clearly shown that there is consensus that this feature is a desirable feature. Let's see what the ADs decide.... Please see some more comments below. Thanks, Kilian > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 > Sent: Donnerstag, 28. Juni 2007 20:30 > To: Kilian Weniger; Jari Arkko > Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org;=20 > Mobile IPv6 Mailing List; Sam Hartman; Brian E Carpenter > Subject: *** Possibly SPAM *** Re: *** Possibly SPAM *** Re:=20 > [Mip6] bootstrapping-splitanycast/ikev2 ha selection feature >=20 > Why is it specific to MIPv6? I guess stateless address=20 > autoconfiguration > of a remote address is something that could also be useful for other > applications and scenarios, e.g., using CGAs or privacy addresses in a > VPN scenario, right? >=20 > jak>> Because the network operator of a VPN gateway in a typical VPN=20 > deployment wants the gateway, not the host, to control the address=20 > allocation. For a VPN application, why would the gateway want=20 > to allow the=20 > host to autogenerate the address? VPN gateways are not=20 > deployed on networks=20 > where hosts can connect, they are deployed in the middle of a=20 > corporate=20 > network on a subnet with no end hosts, so there is no=20 > question of wanting=20 > hosts on the "home" network as in MIP6 to autoconfigure an=20 > address that can=20 > be defended using CGA. So autoconfiguration is not a general=20 > feature that=20 > would appeal to all IKEv2 users, it is specific to MIP6. I think what you describe is one possible VPN scenario (you said "typical"), but there may be others. As you know, VPN is a quite generic term (according to Cisco "A VPN is a generic term that describes any combination of technologies that can be used to secure a connection through an otherwise unsecured or untrusted network", http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/vpn.htm). > > we talked with someone in SAAG about this at the time we were > > considering > > putting it into a separate draft, and we were told to include > > it in the > > bootstrapping draft rather than separate it out. Other=20 > authors please >=20 > What was the reason? >=20 > jak>> See above. >=20 > > correct me if my memory is faulty here. Also, as I mentioned > > in a previous > > post, anycast/IKEv2 is a change in key agreement, which is a > > much more > > serious and deep change in the security protocol than > > MIP6_HOME_PREFIX. > > Therefore, it makes perfect sense to me to spend more time on > > making sure it > > is right. >=20 > As I said, fact is that the authors of the draft and the WG already > spent quite some time (almost 2 years) on this, talked to IKE/Ipsec > experts, and appearently all of them felt that the protocol is right. > Otherwise the draft would not have passed WGLC and AD review. >=20 > jak>> Killian, this feature was added in the last 6 months of=20 > the draft=20 > after you and Francis raised the issue, in fact, I think it=20 > was raised=20 > during WGLC if I recall. At that point, everybody (including=20 > me) just wanted=20 > to get the thing done. I don't think anyone can really say=20 > that there has=20 > been extensive review of this feature. Most people in the WG=20 > had checked out=20 > by that time. Well, the discussion of this idea started on the MIP6 mailing list in October 2005. Francis wrote up the draft (draft-dupont-ikev2-haassign-00.txt) in November 2005. It was presented and discussed at IETF#64 in November 2005 and IETF#65 in March 2006. It was discussed on the MIP6 mailing list multiple times (e.g., in April 06, July 06), on the Ipsec mailing list (Nov 2005), and offline with IKE/IPsec experts. Later it was added to draft-ietf-mip6-bootstrapping-split-03.txt, which came out in October 2006. Then there was the WGLC of this draft.... So I would say there were quite some discussions. >=20 > Anyway, I have problems to understand your concerns, since you haven't > described a specific security issue. If you have a specific issue in > mind, can you please describe the specific threat and issue and how it > can occur in the current protocol? >=20 > jak>> I've made these concerns abundently clear in my=20 > previous posts. I'll=20 > reiterate them here: >=20 > jak>> 1) The feature involves modifying the key provisioning=20 > protocol, which=20 > is a fundamental security feature that, if compromised, can result in=20 > compromise of all future security transactions. In order to=20 > avoid a possible=20 > WEP Catastrophe, it makes sense to seperate out the feature into a=20 > standalone document and subject that to extensive review over=20 > a longer=20 > period of time. Of course I agree to your general statement that a buggy key exchange protocol can result in severe security issues. My question is how specifically the anycast IKE extension with the properties described in the list below (only initial IKE_SA_INIT request is anycasted etc) can result in a severe security issues. Nobody has brought up a specific security issue during all the discussions so far... >=20 > jak>> 2) The feature is one that is not specific to MIP6, and=20 > would be=20 > widely useful for many IKEv2 uses. Therefore, it makes sense=20 > to standardize=20 > it as a separate extension to IKE, rather than burying it at=20 > the end of an=20 > obscure MIP6 enhancement document. Hmm, why is the split scenario document obscure? Note that there is a normative reference from draft-ietf-mip6-bootstrapping-integrated to the split scenario document. >=20 > jak>> I really wish Sam and Jari had been more clear about the IESG's=20 > objections, and would argue them for themselves. I don't=20 > particularly like=20 > doing IESG's dirty work, but I do think they have a point here. >=20 > Please note that > - due to the mandated cookie exchange, there are two subsequent > IKE_SA_INIT request/reply exchanges. Only the IKE_SA_INIT request > message of the initial IKE_SA_INIT exchange is anycasted and any > following IKEv2 message (IKE_SA_INIT reply, request, reply, IKE_AUTH > etc) is sent by unicast. > - hence, a full RFC 4306 IKEv2 key exchange is done, which=20 > only comprise > unicast messages and two parties only. > - the anycasted initial IKE_SA_INIT msg is forwarded between two HAs > *located on the same link*, i.e., the route taken by the=20 > IKE_SA_INIT msg > is the same in case of unicast and anycast (MN->home link) and no new > potential locations for on-path attackers are introduced. > - Since an IKE_SA_INIT request is not a protected message, it can be > spoofed/eavesdropped/replayed/modified/forwarded/etc by anyone anyway, > no matter if sent by unicast or anycast. >=20 > jak>> Right, we discussed this. I still think it make sense=20 > to have more=20 > people look at this over a longer period of time. Experience=20 > with security=20 > protocols has shown that the more people that look at it, the=20 > more bugs are=20 > found. right, but the problem is that you can always spent more time on a specification.... BTW, you said that this feature is currently not needed in the split scenario draft since there is currently no deployment need. Then why do you have problem with my compromise proposal? There cannot be a WEP catastrophe if the mechanism is not deployed, right? ;) >=20 > Jean-Michel raised already some concerns. Another concern is that I'm > not sure if there are enough people willing to spent time and=20 > energy in > standardizing this generalized version. I myself probably=20 > won't. What is > the motivation for the MIP6 people to again spent time and energy on > this? They already have developed a solution, which was=20 > agreed by the WG > to be standardized. So ideally this should be driven by=20 > people from the > IKEv2 community. But are there enough people from this community that > want to spent time and energy on this? Appearently they have not had a > need for such a solution so far... >=20 > jak>> Well, what about you? Personally, if I had something=20 > like this that I=20 > really cared about, I'd much rather see it standardized as a=20 > general feature=20 > available to all IKEv2 users rather than buried at the end of=20 > an obscure=20 > enhancement to another protocol. And I would also want to=20 > know that it was=20 > reviewed by enough people to have some confidence that it is=20 > right. The ADs=20 > should be ready to help, since they are the ones insisting that it be=20 > removed. As for what WG to be standardized, that should be=20 > discussed with=20 > the ADs, but maybe it could be done through SAAG, like TLS=20 > over UDP was. It=20 > only takes one person who really cares about the protocol and=20 > is willing to=20 > do the work to make it happen. >=20 > jak >=20 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=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 Fri Jun 29 06:03: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 1I4DJi-0005MI-LX; Fri, 29 Jun 2007 06:03:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4DJh-0005Ls-Kr for mip6@ietf.org; Fri, 29 Jun 2007 06:03:05 -0400 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4DJT-0007pe-W7 for mip6@ietf.org; Fri, 29 Jun 2007 06:03:05 -0400 Received: by wx-out-0506.google.com with SMTP id h27so705672wxd for ; Fri, 29 Jun 2007 03:02:51 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TN0x0KANNcWj62h4sJYbgJO12ZPu+8b5kNRJR7LlZJCyoKHJb6HBWBKCH8vKY8ZtAeojaAaINIl5SIybI48YlozoWyJxOrqLOq1+QzojduC4kCtnDjSDCFPpFrYuA6P92zyTxhNkd+pwNGEsD0R7kOUasZ/u+fYPNEEehwwYXss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KB5vvxYrU6OOl+48P9k/CG3fe0Ix5ZmQXd7vqYd55dq5B2Xw5V1GY6x6TU6/otQyxZTQjd1aMkQOvLERTA+g+XPYBsqstuQD0WmikdotA0gYgVbKIp/sw7/hEB8L+76NhZGZPqQ5+aBIUR/oKmGK9B/NjRYnETBaMM+MY+N1sZU= Received: by 10.70.91.16 with SMTP id o16mr4532658wxb.1183111368044; Fri, 29 Jun 2007 03:02:48 -0700 (PDT) Received: by 10.70.78.12 with HTTP; Fri, 29 Jun 2007 03:02:47 -0700 (PDT) Message-ID: <5e2406980706290302m6aa2ef8bi80de87a2a1b6b79e@mail.gmail.com> Date: Fri, 29 Jun 2007 12:02:47 +0200 From: "Julien Bournelle" To: "Narayanan, Vidya" Subject: Re: [Mip6] bootstrapping-splitanycast/ikev2 ha selection feature In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4680D95F.10403@piuha.net> <46816A07.50903@azairenet.com> <0b3601c7b82b$43257020$576115ac@dcml.docomolabsusa.com> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A9B@lan-ex-02.panasonic.de> <46821CFA.5050106@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9AB7@lan-ex-02.panasonic.de> <0c6f01c7b8dc$b5850ca0$576115ac@dcml.docomolabsusa.com> <1FEB9B9F2EC38343955D02B2AE86AACB2E9B96@lan-ex-02.panasonic.de> <0ee501c7b9b2$52622730$576115ac@dcml.docomolabsusa.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: James Kempf , draft-ietf-mip6-bootstrapping-split@tools.ietf.org, Mobile IPv6 Mailing List , Kilian Weniger , Sam Hartman , Brian E Carpenter 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, On 6/29/07, Narayanan, Vidya wrote: > I'm just catching up with this thread. I do support the notion of > separating out the anycast aspect to make it more generically an IKEv2 > capability change, rather than in a specific MIP6 document. I don't > think this is quite along the same lines of introducing new IKEv2 > attributes to carry the home prefix, for instance. > > However, I do share Jean-Michel's concern about the actual possibility > of the work getting done independent of the MIP6 document. Note that > I'm not as concerned about timeline in this particular case - as James > pointed out, most SDOs have gone the way of the integrated scenario for > HA discovery, as far as I know. The use of IKEv2 for obtaining home IP > addresses is still being adopted, but, HA discovery via IKEv2 seems > unlikely for immediate adoption. We could provide an HA anycast address to the MN even in the integrated scenario. Am I missing something ? Julien > > That said, I'll also note that HA discovery using anycast in IKEv2 is a > good way of doing it, in my view. So, I really believe we should > support it - if there is commitment to doing a more generalized > anycast-based discovery in IKEv2 as a separate activity, I'll support > that. > > Thanks, > Vidya > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Thursday, June 28, 2007 11:30 AM > > To: Kilian Weniger; Jari Arkko > > Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org; > > Mobile IPv6 Mailing List; Sam Hartman; Brian E Carpenter > > Subject: Re: *** Possibly SPAM *** Re: [Mip6] > > bootstrapping-splitanycast/ikev2 ha selection feature > > > > Why is it specific to MIPv6? I guess stateless address > > autoconfiguration of a remote address is something that could > > also be useful for other applications and scenarios, e.g., > > using CGAs or privacy addresses in a VPN scenario, right? > > > > jak>> Because the network operator of a VPN gateway in a typical VPN > > deployment wants the gateway, not the host, to control the > > address allocation. For a VPN application, why would the > > gateway want to allow the host to autogenerate the address? > > VPN gateways are not deployed on networks where hosts can > > connect, they are deployed in the middle of a corporate > > network on a subnet with no end hosts, so there is no > > question of wanting hosts on the "home" network as in MIP6 to > > autoconfigure an address that can be defended using CGA. So > > autoconfiguration is not a general feature that would appeal > > to all IKEv2 users, it is specific to MIP6. > > > > > we talked with someone in SAAG about this at the time we were > > > considering putting it into a separate draft, and we were told to > > > include it in the bootstrapping draft rather than separate it out. > > > Other authors please > > > > What was the reason? > > > > jak>> See above. > > > > > correct me if my memory is faulty here. Also, as I mentioned in a > > > previous post, anycast/IKEv2 is a change in key agreement, > > which is a > > > much more serious and deep change in the security protocol than > > > MIP6_HOME_PREFIX. > > > Therefore, it makes perfect sense to me to spend more time > > on making > > > sure it is right. > > > > As I said, fact is that the authors of the draft and the WG > > already spent quite some time (almost 2 years) on this, > > talked to IKE/Ipsec experts, and appearently all of them felt > > that the protocol is right. > > Otherwise the draft would not have passed WGLC and AD review. > > > > jak>> Killian, this feature was added in the last 6 months of > > the draft > > after you and Francis raised the issue, in fact, I think it > > was raised during WGLC if I recall. At that point, everybody > > (including me) just wanted to get the thing done. I don't > > think anyone can really say that there has been extensive > > review of this feature. Most people in the WG had checked out > > by that time. > > > > Anyway, I have problems to understand your concerns, since > > you haven't described a specific security issue. If you have > > a specific issue in mind, can you please describe the > > specific threat and issue and how it can occur in the current > > protocol? > > > > jak>> I've made these concerns abundently clear in my previous posts. > > jak>> I'll > > reiterate them here: > > > > jak>> 1) The feature involves modifying the key provisioning > > protocol, > > jak>> which > > is a fundamental security feature that, if compromised, can > > result in compromise of all future security transactions. In > > order to avoid a possible WEP Catastrophe, it makes sense to > > seperate out the feature into a standalone document and > > subject that to extensive review over a longer period of time. > > > > jak>> 2) The feature is one that is not specific to MIP6, and would be > > widely useful for many IKEv2 uses. Therefore, it makes sense > > to standardize it as a separate extension to IKE, rather than > > burying it at the end of an obscure MIP6 enhancement document. > > > > jak>> I really wish Sam and Jari had been more clear about the IESG's > > objections, and would argue them for themselves. I don't > > particularly like doing IESG's dirty work, but I do think > > they have a point here. > > > > Please note that > > - due to the mandated cookie exchange, there are two > > subsequent IKE_SA_INIT request/reply exchanges. Only the > > IKE_SA_INIT request message of the initial IKE_SA_INIT > > exchange is anycasted and any following IKEv2 message > > (IKE_SA_INIT reply, request, reply, IKE_AUTH > > etc) is sent by unicast. > > - hence, a full RFC 4306 IKEv2 key exchange is done, which > > only comprise unicast messages and two parties only. > > - the anycasted initial IKE_SA_INIT msg is forwarded between > > two HAs *located on the same link*, i.e., the route taken by > > the IKE_SA_INIT msg is the same in case of unicast and > > anycast (MN->home link) and no new potential locations for > > on-path attackers are introduced. > > - Since an IKE_SA_INIT request is not a protected message, it > > can be spoofed/eavesdropped/replayed/modified/forwarded/etc > > by anyone anyway, no matter if sent by unicast or anycast. > > > > jak>> Right, we discussed this. I still think it make sense > > to have more > > people look at this over a longer period of time. Experience > > with security protocols has shown that the more people that > > look at it, the more bugs are found. > > > > Jean-Michel raised already some concerns. Another concern is > > that I'm not sure if there are enough people willing to spent > > time and energy in standardizing this generalized version. I > > myself probably won't. What is the motivation for the MIP6 > > people to again spent time and energy on this? They already > > have developed a solution, which was agreed by the WG to be > > standardized. So ideally this should be driven by people from the > > IKEv2 community. But are there enough people from this > > community that want to spent time and energy on this? > > Appearently they have not had a need for such a solution so far... > > > > jak>> Well, what about you? Personally, if I had something like this > > jak>> that I > > really cared about, I'd much rather see it standardized as a > > general feature available to all IKEv2 users rather than > > buried at the end of an obscure enhancement to another > > protocol. And I would also want to know that it was reviewed > > by enough people to have some confidence that it is right. > > The ADs should be ready to help, since they are the ones > > insisting that it be removed. As for what WG to be > > standardized, that should be discussed with the ADs, but > > maybe it could be done through SAAG, like TLS over UDP was. > > It only takes one person who really cares about the protocol > > and is willing to do the work to make it happen. > > > > jak > > > > > > > > > > _______________________________________________ > > 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 Jun 29 07:05: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 1I4EIH-0006Mf-6p; Fri, 29 Jun 2007 07:05:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4EIF-0006MZ-P7 for mip6@ietf.org; Fri, 29 Jun 2007 07:05:39 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4EIB-0007zB-AG for mip6@ietf.org; Fri, 29 Jun 2007 07:05:39 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D70F11986B4; Fri, 29 Jun 2007 14:05:33 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5E63119866D; Fri, 29 Jun 2007 14:05:33 +0300 (EEST) Message-ID: <4684E77E.3070801@piuha.net> Date: Fri, 29 Jun 2007 14:05:34 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: James Kempf , draft-ietf-mip6-bootstrapping-split@tools.ietf.org Subject: Re: *** Possibly SPAM *** Re: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature References: <4680D95F.10403@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de><0a8e01c7b811$f95b8d30$576115ac@dcml.docomolabsusa.com><4681590C.6010904@azairenet.com><0b0301c7b821$f1cec540$576115ac@dcml.docomolabsusa.com><46816254.1020306@azairenet.com><0b1801c7b828$4fb40930$576115ac@dcml.docomolabsusa.com><46816A07.50903@azairenet.com> <0b3601c7b82b$43257020$576115ac@dcml.docomolabsusa.com> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A9B@lan-ex-02.panasonic.de> <46821CFA.5050106@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9AB7@lan-ex-02.panasonic.de> <0c6f01c7b8dc$b5850ca0$576115ac@dcml.docomolabsusa.com> <1FEB9B9F2EC38343955D02B2AE86AACB2E9B96@lan-ex-02.panasonic.de> <0ee501c7b9b2$52622730$576115ac@dcml.docomolabsusa.com> In-Reply-To: <0ee501c7b9b2$52622730$576115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Mobile IPv6 Mailing List , Sam Hartman 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 > jak>> I really wish Sam and Jari had been more clear about the IESG's > objections, and would argue them for themselves. I don't particularly > like doing IESG's dirty work, but I do think they have a point here. Sorry, this is not the only issue on our table :-) so I'm just getting to it now. Anyway, I talked to Sam last night and his main issues are sufficient review in the IPsec community and creating protocols that have generic applicability when it makes sense to do so, which he thinks is the case here. I also think a generic service for anycasting session setup for IPsec nodes is a great idea. Now, I realize that the WG has been on this track for some time. It would have good to realize we had an issue earlier, but here we are. I am sensitive to pushing back on ideas at a late stage, but we also need to resolve the Discusses somehow so that we can ship the document. My suggestion to move one part of the functionality to another document is primarily a management concern: if your product has a feature that has problems, do you delay the entire release or push the feature to another release? Based on my discussion with Sam, I think our options are the following: 1. Ensure a wider review of the anycast feature in the IPsec community. This could be done in various ways, from posting to the list to running a 2nd Last Call. The review itself will not take too much time (few weeks), but I'm concerned that there will be significant discussion. At least Sam felt that as a member of community he would rather see a generic mechanism. 2. Separate the anycast part to a 2nd draft and approve the current one in the next couple of days. The 2nd draft contents would be revised based on this discussion. It would be reviewed and discussed both on this list and in the IPsec community. I'm positive for AD sponsoring this document, so I don't expect a lot of process delay with regards to the document -- time needed depends on how long it takes to revise it to make it more general, and about the review results. My personal guess is that this time is close to what it would take to get an agreement in approach 1... I realize that the question of willingness to pursue this outside the original document has come up. I would urge the authors to pursue this functionality no matter what the document packaging is. It is also not the case that having the functionality in this document implies no work and the separation involves a lot of work. In both cases you have get Sam's and the IPsec community's buy-in. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mext-bounces@ietf.org Fri Jun 29 17:29:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4O1e-0004n0-Vo; Fri, 29 Jun 2007 17:29:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4O1d-0004hb-Ee for mext@ietf.org; Fri, 29 Jun 2007 17:29:09 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4O0j-0004Xn-Uq for mext@ietf.org; Fri, 29 Jun 2007 17:29:09 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l5TLVjTL026544; Fri, 29 Jun 2007 16:31:45 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 16:28:12 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 16:28:12 -0500 Message-ID: <46857923.3080302@ericsson.com> Date: Fri, 29 Jun 2007 17:26:59 -0400 From: Suresh Krishnan User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [MEXT] new charter version References: <467FB99E.3000105@piuha.net> In-Reply-To: <467FB99E.3000105@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jun 2007 21:28:12.0270 (UTC) FILETIME=[6569B0E0:01C7BA94] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Jari, The items A.2 and A.3 are reversed in the following descriptive text "Deployment considerations call for (A.1) solutions to enable dual-stack operation, (A.2) allowing the use of multiple interfaces in mobile nodes, (A.3) mechanisms to support high-availability home agents,..." whereas in the following bulleted list A.2 talks about HA reliability and A.3 talks about multiple interfaces in MNs. Cheers Suresh Jari Arkko wrote: > Testing the new list... this list should have all the subscribers > of the existing three lists. For now, please continue your > technical discussions in the existing lists, except for charter > discussion which we can move here. In general, you do not > need to take any action with regards to list changes, once > we are ready to move complete away from the old lists we > can deal with the from the secretariat. Here's a pointer > to the list page: > > https://www1.ietf.org/mailman/listinfo/mext > > Here's the new charter, revised according to comments > from many of you (thanks!) and the rest of the IESG. > > The charter will go out soon for public IETF review. > > ------ > > Mobility EXTensions for IPv6 (MEXT) > > Chair(s): > TBD > > Internet Area Director(s): > Jari Arkko > Mark Townsley > > Internet Area Advisor: > Jari Arkko > > Mailing Lists: > https://www1.ietf.org/mailman/listinfo/mext > http://www1.ietf.org/mail-archive/web/mext/current/index.html > > > Description of Working Group: > > Mobile IPv6 specifies routing support which permits an IPv6 host to > continue using its home address as it moves around the Internet, > enabling continuity of sessions. Mobile IPv6 supports transparency > above the IP layer, including maintenance of active transport level > sessions. In addition, NEMO network mobility mechanisms built on top > of Mobile IPv6 allow managing the mobility of an entire network, as it > changes its point of attachment to the Internet. The base > specifications consist of: > > o RFC 3775 > o RFC 3963 > o RFC 4877 > > The MEXT Working Group continues the work of the MIP6, NEMO, and > MONAMI6 Working Groups. > > The primary goal of MEXT will be to (A) enhance base IPv6 mobility by > continuing work on developments that are required for wide-scale > deployments and specific deployment scenarios. Additionally, (B) the > working group will ensure that any issues identified by implementation > and interoperability experience are addressed, and that the base > specifications are maintained. (C) The group will also produce > informational documentation, such as design rationale documents or > description of specific issues within the protocol. > > Deployment considerations call for (A.1) solutions to enable > dual-stack operation, (A.2) allowing the use of multiple interfaces in > mobile nodes, (A.3) mechanisms to support high-availability home > agents, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, > (A.5) address the specific needs of automotive and aviation > communities for route optimisation in network mobility, and (A.6) > support for AAA is needed as a continuation of earlier work on > bootstrapping. > > Work items related to large scale deployment include: > > (A.1) A Solution for MIP6 session continuity for dual stack hosts which > attach to IPv4 access networks. Additionally provide a mechanism > for carrying IPv4 packets via the Home agent for MIP6 capable > dual-stack hosts. > > (A.2) A protocol based solution for enhancing the reliability of home > agents and a method to force a host to switch home agents. > > A mechanism to force an MN to switch the HA that is currently > serving it. This is required in deployments where the HA needs to > be taken offline for maintenance. > > (A.3) Use of multiple interfaces. > > Today, the protocols do not provide suppport for simultaneous > differentiated use of multiple access technologies. Several > proposals exist for such support, and some of them have been > implemented and tested. > > When a mobile host/router uses multiple network interfaces > simultaneously, or when multiple prefixes are available on a > single network interface, the mobile host/router would end up > with multiple Care-of Addresses (CoAs). In addition, the Home > Agent might be attached to multiple network interfaces, or to a > single network interface with multiple prefixes, hence resulting > in the option to use multiple IP addresses for the Home > Agent. This could result in the possibility of using a multitude > of bi-directional tunnels between pairs of {Home Agent address, > CoA} and a number of associated issues: establishment, selection > and modification of multiple simultaneous tunnels. > > The objective of the WG is to produce a clear problem statement > and to produce standard track specifications to the problems > associated with the simultaneous use of multiple addresses for > either mobile hosts using Mobile IPv6 or mobile routers using > NEMO Basic Support and their variants (FMIPv6, HMIPv6, > etc). Where the effects of having multiple prefixes on a single > interface is identical to the effects of having multiple > interfaces each with a single prefix, the WG will consider a > generalized approach to cater for multiple prefixes available to > a mobile host/router. > > The WG uses existing tunneling mechanisms defined for Mobile > IPv6. The involved nodes need to select which tunnel instance > to use when multiple ones are available due to multiple > addresses on either end. But the WG does not plan to define a > new mechanism for this, but rather document how to use existing > mechanisms based upon preferences or policies. In particular, > the WG will consider that a tunnel is alive as long as packets > can be exchanged with the corresponding peer. In addition, local > information, such as interface up/down events, or other failure > detection mechanisms can be used to quickly detect failure of > tunnel(s). > > Deliverables related to this include > > - A document explaining the motivations for a node using multiple > interfaces and the scenarios where it may end up with multiple > global addresses on its interfaces [Informational] > > - An analysis document explaining what are the limitations for > mobile hosts using multiple simultaneous Care-of Addresses and Home > Agent addresses using Mobile IPv6, whether issues are specific to > Mobile IPv6 or not [Informational]. > > - A protocol extension to support the registration of multiple > Care-of Addresses at a given Home Agent address [Standard > Track]. > > - A "Flow/binding policies exchange" solution for an exchange of > policies from the mobile host/router to the Home Agent and from the > Home Agent to the mobile host/router influencing the choice of the > Care-of Address and Home Agent address. The solution involves two > specifications, one for the policy format and another for its > transport [both Standard Track]. > > (A.4) Work on solutions to deal with firewalls and the problems that > firewalls cause as identified in RFC 4487. > > (A.5) Route optimization of network mobility. > > Three use cases have been identified for this. These are called > the Aviation case, the Automotive case, and the Personal Mobile > Router (consumer electronics) case, though the actual technical > problems are characterized by the type of movements and > environments more than by the specific industry using the > technology. The group will explore these cases to gather > requirements and proceed with solving the open issues. > > (1) Airline and spacecraft community, who are deploying NEMO for > control systems, as well as Internet connectivity and > entertainment systems. This use case is characterized by fast (~ > 1000 km/h) moving objects over large distances (across > continents). The main technical problem is that tunneling-based > solutions imply a roundtrip to another continent and that BGP > based solutions imply significant churn in the global Internet > routing table. > > (2) Automotive industry who are deploying NEMO for in-car > communication, entertainment, and data gathering, possible > control systems use, and communication to roadside devices. This > use case is characterized by moderately fast (~ 100-300 km/h) > moving objects that employ local or cellular networks for > connectivity. > > (3) Personal Mobile Routers, which are consumer devices that > allow the user to bring a NEMO network with the user while > mobile, and communicate with peer NEMO Basic Support nodes > and nodes served by them. > > After gathering the requirements for these types of deployments, > the working group will evaluate what type of route optimization > needs to be performed (if any), and formulate a solution to > those problems. > > If no requirements for those scenarios can be collected by the > deadline, it will be assumed that the work is premature, and > that type of deployment will be dropped from the WG. > > The group will only consider airline and spacecraft solutions > that combine tunneling solutions for small movements with either > federated tunnel servers or slowly changing end host prefixes. > The group will only consider personal mobile router requirements > about optimized routes to another mobile router belonging to the > same operator. The group will only consider automotive industry > requirements to allow MR-attached hosts to directly access the > network where MR has attached to. Work on automotive and > personal mobile router solutions requires rechartering. > > The WG will not consider extensions to routing protocols. The > group will not consider general multi-homing problems that are > not related to the deployment and maintenance of Mobile IPv6 or > NEMO Basic Support protocols. The group will also not consider > general route optimization, or other problems that are not > related to the deployment and maintenance of NEMO Basic Support > protocols. Similarly, the group will not consider or rely on the > results of general routing architecture, Internet architecture, > or identifier-locator split issues that are discussed in > separate, long term efforts elsewhere in the IETF. Finally, the > group will not consider solutions that require changes from > correspondent nodes in the general Internet > > (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG > require AAA support for Mobile IPv6. Part of this work is > already being done in the DIME WG, but the MEXT WG is chartered > to complete a design for RADIUS. > > > Work items related to base specification maintenance include: > > (B.1) Create and maintain issue lists that are generated on the basis > of implementation and interoperability experience. Address > specific issues with specific updates or revisions of the base > specification. One specific area of concern that should be > analyzed and addressed relates to multilink subnets. > > This work item relates only to corrections and > clarifications. The working group shall not revisit design > decisions or change the protocol. > > (B.2) Update the IANA considerations of RFC 3775 to allow extensions for > experimental purposes as well passing of optional vendor-specific > information. > > (B.3) Finish working group documents that are currently in process, and > submit for RFC. This includes prefix delegation protocol mechanism > for network mobility, and a MIB for NEMO Basic Support. > > > Work items related to informational documentation include: > > (C.1) Produce a design rationale that documents the historical > thinking behind the introduction of an alternative security > mechanism, the Authentication Protocol (RFC 4285). > > > Goals and Milestones: > > Aug 2007 Submit -00 draft on Route Optimization Needs for Aircraft > and Spacecraft Deployments > Aug 2007 Submit -00 draft on Route Optimization Needs for Automobile > and Highway Deployments > Aug 2007 Submit Multiple CoA Registration to IESG > > Sep 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for > publication as Informational. > Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for > publication as a Proposed Standard. > > Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for > publication as a Proposed Standard > Oct 2007 Submit -00 draft on Route Optimization needs for Personal > Mobile Router > > Nov 2007 Submit final doc on Route Optimization Needs for Aircraft > and Spacecraft Deployments, for Informational > Nov 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for > publication as Informational. > > Dec 2007 Submit -00 draft for solution to aircraft/spacecraft problem > Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG > for publication as a Proposed Standard. > Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the > IESG, for Proposed Standard > > Jan 2007 Submit final doc on Route Optimization Needs for Automobile > and Highway Deployments, for Informational > Jan 2007 Submit final doc on Route Optimization needs for Personal > Mobile Router, for Informational > > Feb 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for > publication as a proposed standard. > Feb 2008 Determine how to proceed with remaining automotive/Personal > Mobile Router solutions > > Mar 2008 Submit the final doc on MIB for NEMO Basic Support to the > IESG, for Proposed Standard > Mar 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG > for publication as Informational. > > Apr 2008 Submit Flow/binding policy format to IESG, for Proposed Standard > Apr 2008 Submit Flow/binding policy transport to IESG, for Proposed > Standard > Apr 2007 Submit I-D 'Mobility Header Home Agent Switch Message' to > IESG for publication as a Proposed Standard. > > May 2008 Submit final doc for solution to aircraft/spacecraft problem > to the IESG, for Proposed Standard > May 2008 Recharter to work on the remaining automotive/Personal > Mobile Router solutions > > Jul 2007 Submit Multiple Interfaces Motivations and Scenario to IESG, > for Informational > Jul 2007 Submit Analysis of the use of Multiple Simultaneous Care-of > Addresses and Home Agent addresses, for Informational > > Aug 2008 Submit I-D(s) related to specific updates and corrections of > RFC 3775 to IESG for publication as Proposed Standard. > Aug 2008 Submit I-D 'Home agent reliability' to IESG for publication > as a Proposed Standard. > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mip6-bounces@ietf.org Fri Jun 29 17:54: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 1I4OPq-0007Cb-Uf; Fri, 29 Jun 2007 17:54:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4OPo-00076f-VV for mip6@ietf.org; Fri, 29 Jun 2007 17:54:08 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4OP4-0004Vt-AH for mip6@ietf.org; Fri, 29 Jun 2007 17:54:07 -0400 MIME-Version: 1.0 Subject: RE: *** Possibly SPAM *** Re: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature Date: Fri, 29 Jun 2007 14:52:21 -0700 Message-ID: <2FD61F37AFF16D4DB46149330E4273C7095A55@dcl-ex.dcml.docomolabs-usa.com> References: <4680D95F.10403@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de><0a8e01c7b811$f95b8d30$576115ac@dcml.docomolabsusa.com><4681590C.6010904@azairenet.com><0b0301c7b821$f1cec540$576115ac@dcml.docomolabsusa.com><46816254.1020306@azairenet.com><0b1801c7b828$4fb40930$576115ac@dcml.docomolabsusa.com><46816A07.50903@azairenet.com> <0b3601c7b82b$43257020$576115ac@dcml.docomolabsusa.com> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A9B@lan-ex-02.panasonic.de> <46821CFA.5050106@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9AB7@lan-ex-02.panasonic.de> <0c6f01c7b8dc$b5850ca0$576115ac@dcml.docomolabsusa.com> <1FEB9B9F2EC38343955D02B2AE86AACB2E9B96@lan-ex-02.panasonic.de> <0ee501c7b9b2$52622730$576115ac@dcml.docomolabsusa.com> <4684E77E.3070801@piuha.net> From: "James Kempf" To: "Jari Arkko" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: Mobile IPv6 Mailing List , Sam Hartman 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="===============1753875168==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1753875168== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BA97.E88BB83A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7BA97.E88BB83A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm certainly in favor or 2). I agree that the amount of time required = is probably about the same in both cases.=20 =20 jak ________________________________ From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Fri 6/29/2007 4:05 AM To: James Kempf; draft-ietf-mip6-bootstrapping-split@tools.ietf.org Cc: Mobile IPv6 Mailing List; Sam Hartman Subject: Re: *** Possibly SPAM *** Re: [Mip6] bootstrapping-split = anycast/ikev2 ha selection feature > jak>> I really wish Sam and Jari had been more clear about the IESG's > objections, and would argue them for themselves. I don't particularly > like doing IESG's dirty work, but I do think they have a point here. Sorry, this is not the only issue on our table :-) so I'm just getting to it now. Anyway, I talked to Sam last night and his main issues are sufficient review in the IPsec community and creating protocols that have generic applicability when it makes sense to do so, which he thinks is the case here. I also think a generic service for anycasting session setup for IPsec nodes is a great idea. Now, I realize that the WG has been on this track for some time. It would have good to realize we had an issue earlier, but here we are. I am sensitive to pushing back on ideas at a late stage, but we also need to resolve the Discusses somehow so that we can ship the document. My suggestion to move one part of the functionality to another document is primarily a management concern: if your product has a feature that has problems, do you delay the entire release or push the feature to another release? Based on my discussion with Sam, I think our options are the following: 1. Ensure a wider review of the anycast feature in the IPsec community. This could be done in various ways, from posting to the list to running a 2nd Last Call. The review itself will not take too much time (few weeks), but I'm concerned that there will be significant discussion. At least Sam felt that as a member of community he would rather see a generic mechanism. 2. Separate the anycast part to a 2nd draft and approve the current one in the next couple of days. The 2nd draft contents would be revised based on this discussion. It would be reviewed and discussed both on this list and in the IPsec community. I'm positive for AD sponsoring this document, so I don't expect a lot of process delay with regards to the document -- time needed depends on how long it takes to revise it to make it more general, and about the review results. My personal guess is that this time is close to what it would take to get an agreement in approach 1... I realize that the question of willingness to pursue this outside the original document has come up. I would urge the authors to pursue this functionality no matter what the document packaging is. It is also not the case that having the functionality in this document implies no work and the separation involves a lot of work. In both cases you have get Sam's and the IPsec community's buy-in. Jari ------_=_NextPart_001_01C7BA97.E88BB83A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: *** Possibly SPAM *** Re: [Mip6] = bootstrapping-split anycast/ikev2 ha selection feature=0A= =0A= =0A= =0A=
=0A=
I'm certainly = in favor or 2). I agree that the amount of time required  is = probably  about the same in both cases.
=0A=
 
=0A=
       jak
=0A=

=0A=
=0A= From: Jari Arkko = [mailto:jari.arkko@piuha.net]
Sent: Fri 6/29/2007 4:05 = AM
To: James Kempf; = draft-ietf-mip6-bootstrapping-split@tools.ietf.org
Cc: Mobile = IPv6 Mailing List; Sam Hartman
Subject: Re: *** Possibly SPAM = *** Re: [Mip6] bootstrapping-split anycast/ikev2 ha selection = feature

=0A=

=0A=

> jak>> I really wish Sam and Jari had been = more clear about the IESG's
> objections, and would argue them for = themselves. I don't particularly
> like doing IESG's dirty = work,  but I do think they have a point here.

Sorry, this is = not the only issue on our table :-) so I'm
just getting to it = now.

Anyway, I talked to Sam last night and his main issues = are
sufficient review in the IPsec community and = creating
protocols that have generic applicability when it = makes
sense to do so, which he thinks is the case here. I = also
think a generic service for anycasting session setup
for = IPsec nodes is a great idea.

Now, I realize that the WG has been = on this track for
some time. It would have good to realize we had = an
issue earlier, but here we are. I am sensitive to pushing
back = on ideas at a late stage, but we also need to
resolve the Discusses = somehow so that we can ship
the document. My suggestion to move one = part of
the functionality to another document is primarily
a = management concern: if your product has a feature
that has problems, = do you delay the entire release or
push the feature to another = release?

Based on my discussion with Sam, I think our = options
are the following:

1. Ensure a wider review of the = anycast feature in
    the IPsec community. This could = be done in various
    ways, from posting to the list = to running a 2nd
    Last = Call.

    The review itself will not take too much = time (few
    weeks), but I'm concerned that there = will be
    significant discussion. At least Sam felt = that
    as a member of community he would rather = see
    a generic mechanism.

2. Separate the = anycast part to a 2nd draft and
    approve the = current one in the next couple of
    = days.

    The 2nd draft contents would be revised = based
    on this discussion. It would be reviewed = and
    discussed both on this list and in the = IPsec
    community. I'm positive for AD = sponsoring
    this document, so I don't expect a lot = of
    process delay with regards to the document = --
    time needed depends on how long it takes = to
    revise it to make it more general, and = about
    the review results. My personal guess is = that
    this time is close to what it would take to = get
    an agreement in approach = 1...

    I realize that the question of = willingness to
    pursue this outside the original = document has
    come up. I would urge the authors to = pursue
    this functionality no matter what the = document
    packaging is. It is also not the case = that
    having the functionality in this document = implies
    no work and the separation involves a lot = of work.
    In both cases you have get Sam's and the = IPsec
    community's = buy-in.

Jari

------_=_NextPart_001_01C7BA97.E88BB83A-- --===============1753875168== 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 --===============1753875168==-- From mip6-bounces@ietf.org Fri Jun 29 17:57: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 1I4OSf-00077O-Kc; Fri, 29 Jun 2007 17:57:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4OSc-00077D-K4 for mip6@ietf.org; Fri, 29 Jun 2007 17:57:02 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4OSb-0001Mu-BK for mip6@ietf.org; Fri, 29 Jun 2007 17:57:02 -0400 MIME-Version: 1.0 Subject: Re: [Mip6] bootstrapping-splitanycast/ikev2 ha selection feature Date: Fri, 29 Jun 2007 14:55:07 -0700 Message-ID: <2FD61F37AFF16D4DB46149330E4273C7095A56@dcl-ex.dcml.docomolabs-usa.com> References: <4680D95F.10403@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A47@lan-ex-02.panasonic.de><0a8e01c7b811$f95b8d30$576115ac@dcml.docomolabsusa.com><4681590C.6010904@azairenet.com><0b0301c7b821$f1cec540$576115ac@dcml.docomolabsusa.com><46816254.1020306@azairenet.com><0b1801c7b828$4fb40930$576115ac@dcml.docomolabsusa.com><46816A07.50903@azairenet.com><0b3601c7b82b$43257020$576115ac@dcml.docomolabsusa.com><1FEB9B9F2EC38343955D02B2AE86AACB2E9A9B@lan-ex-02.panasonic.de><46821CFA.5050106@piuha.net><1FEB9B9F2EC38343955D02B2AE86AACB2E9AB7@lan-ex-02.panasonic.de><0c6f01c7b8dc$b5850ca0$576115ac@dcml.docomolabsusa.com><1FEB9B9F2EC38343955D02B2AE86AACB2E9B96@lan-ex-02.panasonic.de> <0ee501c7b9b2$52622730$576115ac@dcml.docomolabsusa.com> <1FEB9B9F2EC38343955D02B2AE86AACB2E9C9C@lan-ex-02.panasonic.de> From: "James Kempf" To: "Kilian Weniger" , "Jari Arkko" X-Spam-Score: 0.3 (/) X-Scan-Signature: 6a817af60e4281a101681ecb646dffff Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org, Mobile IPv6 Mailing List , Sam Hartman , Brian E Carpenter 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="===============0850664310==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0850664310== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BA98.448616D6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7BA98.448616D6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Killian, =20 Like you said, you have your mind made up on this, so I don't see much = point in continuing the discussion. My position is, I believe, also = clear. =20 jak ________________________________ From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] Sent: Fri 6/29/2007 1:49 AM To: James Kempf; Kilian Weniger; Jari Arkko Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org; Mobile IPv6 = Mailing List; Sam Hartman; Brian E Carpenter Subject: RE: *** Possibly SPAM *** Re: *** Possibly SPAM *** Re: [Mip6] = bootstrapping-splitanycast/ikev2 ha selection feature Hi James, I guess we have both made our opinions clear enough now to close this thread. I'm still in favour of the compromise (keep feature in split scenario draft and in parallel pursue a generalized version) because otherwise the standardization of the anycast feature for MIPv6 HA assignment may be significantly delayed or even aborted due to the various reasons Jean-Michel and I mentioned. And this discussion as well as the WG decisions in the past have clearly shown that there is consensus that this feature is a desirable feature. Let's see what the ADs decide.... Please see some more comments below. Thanks, Kilian > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Donnerstag, 28. Juni 2007 20:30 > To: Kilian Weniger; Jari Arkko > Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org; > Mobile IPv6 Mailing List; Sam Hartman; Brian E Carpenter > Subject: *** Possibly SPAM *** Re: *** Possibly SPAM *** Re: > [Mip6] bootstrapping-splitanycast/ikev2 ha selection feature > > Why is it specific to MIPv6? I guess stateless address > autoconfiguration > of a remote address is something that could also be useful for other > applications and scenarios, e.g., using CGAs or privacy addresses in a > VPN scenario, right? > > jak>> Because the network operator of a VPN gateway in a typical VPN > deployment wants the gateway, not the host, to control the address > allocation. For a VPN application, why would the gateway want > to allow the > host to autogenerate the address? VPN gateways are not > deployed on networks > where hosts can connect, they are deployed in the middle of a > corporate > network on a subnet with no end hosts, so there is no > question of wanting > hosts on the "home" network as in MIP6 to autoconfigure an > address that can > be defended using CGA. So autoconfiguration is not a general > feature that > would appeal to all IKEv2 users, it is specific to MIP6. I think what you describe is one possible VPN scenario (you said "typical"), but there may be others. As you know, VPN is a quite generic term (according to Cisco "A VPN is a generic term that describes any combination of technologies that can be used to secure a connection through an otherwise unsecured or untrusted network", https://portal02.jwebcity.net/http://www.cisco.com/univercd/cc/td/doc/cis= intwk/ito_doc/vpn.htm). > > we talked with someone in SAAG about this at the time we were > > considering > > putting it into a separate draft, and we were told to include > > it in the > > bootstrapping draft rather than separate it out. Other > authors please > > What was the reason? > > jak>> See above. > > > correct me if my memory is faulty here. Also, as I mentioned > > in a previous > > post, anycast/IKEv2 is a change in key agreement, which is a > > much more > > serious and deep change in the security protocol than > > MIP6_HOME_PREFIX. > > Therefore, it makes perfect sense to me to spend more time on > > making sure it > > is right. > > As I said, fact is that the authors of the draft and the WG already > spent quite some time (almost 2 years) on this, talked to IKE/Ipsec > experts, and appearently all of them felt that the protocol is right. > Otherwise the draft would not have passed WGLC and AD review. > > jak>> Killian, this feature was added in the last 6 months of > the draft > after you and Francis raised the issue, in fact, I think it > was raised > during WGLC if I recall. At that point, everybody (including > me) just wanted > to get the thing done. I don't think anyone can really say > that there has > been extensive review of this feature. Most people in the WG > had checked out > by that time. Well, the discussion of this idea started on the MIP6 mailing list in October 2005. Francis wrote up the draft (draft-dupont-ikev2-haassign-00.txt) in November 2005. It was presented and discussed at IETF#64 in November 2005 and IETF#65 in March 2006. It was discussed on the MIP6 mailing list multiple times (e.g., in April 06, July 06), on the Ipsec mailing list (Nov 2005), and offline with IKE/IPsec experts. Later it was added to draft-ietf-mip6-bootstrapping-split-03.txt, which came out in October 2006. Then there was the WGLC of this draft.... So I would say there were quite some discussions. > > Anyway, I have problems to understand your concerns, since you haven't > described a specific security issue. If you have a specific issue in > mind, can you please describe the specific threat and issue and how it > can occur in the current protocol? > > jak>> I've made these concerns abundently clear in my > previous posts. I'll > reiterate them here: > > jak>> 1) The feature involves modifying the key provisioning > protocol, which > is a fundamental security feature that, if compromised, can result in > compromise of all future security transactions. In order to > avoid a possible > WEP Catastrophe, it makes sense to seperate out the feature into a > standalone document and subject that to extensive review over > a longer > period of time. Of course I agree to your general statement that a buggy key exchange protocol can result in severe security issues. My question is how specifically the anycast IKE extension with the properties described in the list below (only initial IKE_SA_INIT request is anycasted etc) can result in a severe security issues. Nobody has brought up a specific security issue during all the discussions so far... > > jak>> 2) The feature is one that is not specific to MIP6, and > would be > widely useful for many IKEv2 uses. Therefore, it makes sense > to standardize > it as a separate extension to IKE, rather than burying it at > the end of an > obscure MIP6 enhancement document. Hmm, why is the split scenario document obscure? Note that there is a normative reference from draft-ietf-mip6-bootstrapping-integrated to the split scenario document. > > jak>> I really wish Sam and Jari had been more clear about the IESG's > objections, and would argue them for themselves. I don't > particularly like > doing IESG's dirty work, but I do think they have a point here. > > Please note that > - due to the mandated cookie exchange, there are two subsequent > IKE_SA_INIT request/reply exchanges. Only the IKE_SA_INIT request > message of the initial IKE_SA_INIT exchange is anycasted and any > following IKEv2 message (IKE_SA_INIT reply, request, reply, IKE_AUTH > etc) is sent by unicast. > - hence, a full RFC 4306 IKEv2 key exchange is done, which > only comprise > unicast messages and two parties only. > - the anycasted initial IKE_SA_INIT msg is forwarded between two HAs > *located on the same link*, i.e., the route taken by the > IKE_SA_INIT msg > is the same in case of unicast and anycast (MN->home link) and no new > potential locations for on-path attackers are introduced. > - Since an IKE_SA_INIT request is not a protected message, it can be > spoofed/eavesdropped/replayed/modified/forwarded/etc by anyone anyway, > no matter if sent by unicast or anycast. > > jak>> Right, we discussed this. I still think it make sense > to have more > people look at this over a longer period of time. Experience > with security > protocols has shown that the more people that look at it, the > more bugs are > found. right, but the problem is that you can always spent more time on a specification.... BTW, you said that this feature is currently not needed in the split scenario draft since there is currently no deployment need. Then why do you have problem with my compromise proposal? There cannot be a WEP catastrophe if the mechanism is not deployed, right? ;) > > Jean-Michel raised already some concerns. Another concern is that I'm > not sure if there are enough people willing to spent time and > energy in > standardizing this generalized version. I myself probably > won't. What is > the motivation for the MIP6 people to again spent time and energy on > this? They already have developed a solution, which was > agreed by the WG > to be standardized. So ideally this should be driven by > people from the > IKEv2 community. But are there enough people from this community that > want to spent time and energy on this? Appearently they have not had a > need for such a solution so far... > > jak>> Well, what about you? Personally, if I had something > like this that I > really cared about, I'd much rather see it standardized as a > general feature > available to all IKEv2 users rather than buried at the end of > an obscure > enhancement to another protocol. And I would also want to > know that it was > reviewed by enough people to have some confidence that it is > right. The ADs > should be ready to help, since they are the ones insisting that it be > removed. As for what WG to be standardized, that should be > discussed with > the ADs, but maybe it could be done through SAAG, like TLS > over UDP was. It > only takes one person who really cares about the protocol and > is willing to > do the work to make it happen. > > jak > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke ------_=_NextPart_001_01C7BA98.448616D6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: *** Possibly SPAM *** Re: *** Possibly = SPAM *** Re: [Mip6] bootstrapping-splitanycast/ikev2 ha selection = feature=0A= =0A= =0A= =0A=
=0A=
Killian,
=0A=
 
=0A=
Like you said, you have your = mind made up on this, so I don't see much point in continuing the = discussion. My position is, I believe, also clear.
=0A=
 
=0A=
          = jak
=0A=

=0A=
=0A= From: Kilian Weniger = [mailto:Kilian.Weniger@eu.panasonic.com]
Sent: Fri 6/29/2007 = 1:49 AM
To: James Kempf; Kilian Weniger; Jari = Arkko
Cc: draft-ietf-mip6-bootstrapping-split@tools.ietf.org; = Mobile IPv6 Mailing List; Sam Hartman; Brian E = Carpenter
Subject: RE: *** Possibly SPAM *** Re: *** Possibly = SPAM *** Re: [Mip6] bootstrapping-splitanycast/ikev2 ha selection = feature

=0A=
=0A=

Hi James,

I guess we have both made our = opinions clear enough now to close this
thread. I'm still in favour = of the compromise (keep feature in split
scenario draft and in = parallel pursue a generalized version) because
otherwise the = standardization of the anycast feature for MIPv6 HA
assignment may be = significantly delayed or even aborted due to the
various reasons = Jean-Michel and I mentioned. And this discussion as well
as the WG = decisions in the past have clearly shown that there is
consensus that = this feature is a desirable feature.

Let's see what the ADs = decide....

Please see some more comments = below.

Thanks,

Kilian

> -----Original = Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com<= /A>]
> Sent: Donnerstag, 28. Juni 2007 20:30
> To: Kilian = Weniger; Jari Arkko
> Cc: = draft-ietf-mip6-bootstrapping-split@tools.ietf.org;
> Mobile IPv6 = Mailing List; Sam Hartman; Brian E Carpenter
> Subject: *** = Possibly SPAM *** Re: *** Possibly SPAM *** Re:
> [Mip6] = bootstrapping-splitanycast/ikev2 ha selection feature
>
> = Why is it specific to MIPv6? I guess stateless address
> = autoconfiguration
> of a remote address is something that could = also be useful for other
> applications and scenarios, e.g., using = CGAs or privacy addresses in a
> VPN scenario, = right?
>
> jak>> Because the network operator of a VPN = gateway  in a typical VPN
> deployment wants the gateway, not = the host, to control the address
> allocation. For a VPN = application, why would the gateway want
> to allow the
> = host to autogenerate the address? VPN gateways are not
> deployed = on networks
> where hosts can connect, they are deployed in the = middle of a
> corporate
> network on a subnet with no end = hosts, so there is no
> question of wanting
> hosts on the = "home" network as in MIP6 to autoconfigure an
> address that = can
> be defended using CGA. So autoconfiguration is not a = general
> feature that
> would appeal to all IKEv2 users, it = is specific to MIP6.

I think what you describe is one possible = VPN scenario (you said
"typical"), but there may be others. As you = know, VPN is a quite generic
term (according to Cisco "A VPN is a = generic term that describes any
combination of technologies that can = be used to secure a connection
through an otherwise unsecured or = untrusted network",
https://portal02.jwebcity.net/http://www.c= isco.com/univercd/cc/td/doc/cisintwk/ito_doc/vpn.htm).


>= ; > we talked with someone in SAAG about this at the time we = were
> > considering
> > putting it into a separate = draft, and we were told to include
> > it in the
> > = bootstrapping draft rather than separate it out. Other
> authors = please
>
> What was the reason?
>
> jak>> = See above.
>
> > correct me if my memory is faulty here. = Also, as I mentioned
> > in a previous
> > post, = anycast/IKEv2 is a change in key agreement, which is a
> > much = more
> > serious and deep change in the security protocol = than
> > MIP6_HOME_PREFIX.
> > Therefore, it makes = perfect sense to me to spend more time on
> > making sure = it
> > is right.
>
> As I said, fact is that the = authors of the draft and the WG already
> spent quite some time = (almost 2 years) on this, talked to IKE/Ipsec
> experts, and = appearently all of them felt that the protocol is right.
> = Otherwise the draft would not have passed WGLC and AD = review.
>
> jak>> Killian, this feature was added in = the last 6 months of
> the draft
> after you and Francis = raised the issue, in fact, I think it
> was raised
> during = WGLC if I recall. At that point, everybody (including
> me) just = wanted
> to get the thing done. I don't think anyone can really = say
> that there has
> been extensive review of this = feature. Most people in the WG
> had checked out
> by that = time.

Well, the discussion of this idea started on the MIP6 = mailing list in
October 2005. Francis wrote up the = draft
(draft-dupont-ikev2-haassign-00.txt) in November 2005. It was = presented
and discussed at IETF#64 in November 2005 and IETF#65 in = March 2006. It
was discussed on the MIP6 mailing list multiple times = (e.g., in April
06, July 06), on the Ipsec mailing list (Nov 2005), = and offline with
IKE/IPsec experts. Later it was added = to
draft-ietf-mip6-bootstrapping-split-03.txt, which came out in = October
2006. Then there was the WGLC of this draft....

So I = would say there were quite some discussions.

>
> Anyway, = I have problems to understand your concerns, since you haven't
> = described a specific security issue. If you have a specific issue = in
> mind, can you please describe the specific threat and issue = and how it
> can occur in the current protocol?
>
> = jak>> I've made these concerns abundently clear in my
> = previous posts. I'll
> reiterate them here:
>
> = jak>> 1) The feature involves modifying the key = provisioning
> protocol, which
> is a fundamental security = feature that, if compromised, can result in
> compromise of all = future security transactions. In order to
> avoid a = possible
> WEP Catastrophe, it makes sense to seperate out the = feature into a
> standalone document and subject that to extensive = review over
> a longer
> period of time.

Of course I = agree to your general statement that a buggy key exchange
protocol = can result in severe security issues. My question is how
specifically = the anycast IKE extension with the properties described in
the list = below (only initial IKE_SA_INIT request is anycasted etc) can
result = in a severe security issues. Nobody has brought up a = specific
security issue during all the discussions so = far...

>
> jak>> 2) The feature is one that is not = specific to MIP6, and
> would be
> widely useful for many = IKEv2 uses. Therefore, it makes sense
> to standardize
> it = as a separate extension to IKE, rather than burying it at
> the = end of an
> obscure MIP6 enhancement document.

Hmm, why is = the split scenario document obscure? Note that there is a
normative = reference from draft-ietf-mip6-bootstrapping-integrated to the
split = scenario document.

>
> jak>> I really wish Sam and = Jari had been more clear about the IESG's
> objections, and would = argue them for themselves. I don't
> particularly like
> = doing IESG's dirty work,  but I do think they have a point = here.
>
> Please note that
> - due to the mandated = cookie exchange, there are two subsequent
> IKE_SA_INIT = request/reply exchanges. Only the IKE_SA_INIT request
> message of = the initial IKE_SA_INIT exchange is anycasted and any
> following = IKEv2 message (IKE_SA_INIT reply, request, reply, IKE_AUTH
> etc) = is sent by unicast.
> - hence, a full RFC 4306 IKEv2 key exchange = is done, which
> only comprise
> unicast messages and two = parties only.
> - the anycasted initial IKE_SA_INIT msg is = forwarded between two HAs
> *located on the same link*, i.e., the = route taken by the
> IKE_SA_INIT msg
> is the same in case = of unicast and anycast (MN->home link) and no new
> potential = locations for on-path attackers are introduced.
> - Since an = IKE_SA_INIT request is not a protected message, it can be
> = spoofed/eavesdropped/replayed/modified/forwarded/etc by anyone = anyway,
> no matter if sent by unicast or anycast.
>
> = jak>> Right, we discussed this. I still think it make = sense
> to have more
> people look at this over a longer = period of time. Experience
> with security
> protocols has = shown that the more people that look at it, the
> more bugs = are
> found.

right, but the problem is that you can always = spent more time on a
specification....

BTW, you said that this = feature is currently not needed in the split
scenario draft since = there is currently no deployment need. Then why do
you have problem = with my compromise proposal? There cannot be a WEP
catastrophe if the = mechanism is not deployed, right? ;)

>
> Jean-Michel = raised already some concerns. Another concern is that I'm
> not = sure if there are enough people willing to spent time and
> energy = in
> standardizing this generalized version. I myself = probably
> won't. What is
> the motivation for the MIP6 = people to again spent time and energy on
> this? They already have = developed a solution, which was
> agreed by the WG
> to be = standardized. So ideally this should be driven by
> people from = the
> IKEv2 community. But are there enough people from this = community that
> want to spent time and energy on this? = Appearently they have not had a
> need for such a solution so = far...
>
> jak>> Well, what about you? Personally, if = I had something
> like this that I
> really cared about, I'd = much rather see it standardized as a
> general feature
> = available to all IKEv2 users rather than buried at the end of
> an = obscure
> enhancement to another protocol. And I would also want = to
> know that it was
> reviewed by enough people to have = some confidence that it is
> right. The ADs
> should be = ready to help, since they are the ones insisting that it be
> = removed. As for what WG to be standardized, that should be
> = discussed with
> the ADs, but maybe it could be done through SAAG, = like TLS
> over UDP was. It
> only takes one person who = really cares about the protocol and
> is willing to
> do the = work to make it = happen.
>
>        &n= bsp;    jak
>
>
>
>
> = _______________________________________________
> Mip6 mailing = list
> Mip6@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/mip6
>
>


Panasonic R&D = Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG = Offenbach (Hessen) HRB 33974
Managing Director: Thomas = Micke


------_=_NextPart_001_01C7BA98.448616D6-- --===============0850664310== 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 --===============0850664310==-- From mext-bounces@ietf.org Fri Jun 29 18:34: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 1I4P31-0005Y7-TT; Fri, 29 Jun 2007 18:34:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4P30-0005Xc-IL for mext@ietf.org; Fri, 29 Jun 2007 18:34:38 -0400 Received: from web84106.mail.mud.yahoo.com ([68.142.206.193]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4P2u-0004To-Kx for mext@ietf.org; Fri, 29 Jun 2007 18:34:38 -0400 Received: (qmail 44804 invoked by uid 60001); 29 Jun 2007 22:34:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=ymMdslFbjk2WgYIVQpqTM2wvozSG9Oa1E+vWdFSCsPaimUjJBvTx/IwkjtLZQU3UzZd1vtpnJKEmlDiQum14CuoQTo3ODRTsUklbsrZ463zgGtr+hN3D6neLH4k9pT3S6455mw8120U8Nnm2XxfAN5zQQTZSF7ILa00pfibCgck=; X-YMail-OSG: DZWOWDEVM1m1TSRnjz.7zH0hyQPweR_nrJzLGQBjkXD997R7boesSbJtUBP.UK9S5Y_Tsy_Ce9WOFqYh.D1vi89YLDPv34mXrgsrZenAxLVp61TXUew- Received: from [206.16.17.212] by web84106.mail.mud.yahoo.com via HTTP; Fri, 29 Jun 2007 15:34:32 PDT X-Mailer: YahooMailRC/651.38 YahooMailWebService/0.7.41.16 Date: Fri, 29 Jun 2007 15:34:32 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [MEXT] new charter version To: Jari Arkko MIME-Version: 1.0 Message-ID: <84929.44768.qm@web84106.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: cd000eda3d43531d5b01b5d305410e3c Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0222891421==" Errors-To: mext-bounces@ietf.org --===============0222891421== Content-Type: multipart/alternative; boundary="0-1884647686-1183156472=:44768" --0-1884647686-1183156472=:44768 Content-Type: text/plain; charset=ascii Hi Jari, In fact HA reliability work is almost over. I think the current draft is expected to go for WGLC soon and the subteam is almost closed. I don't think it would take Aug 08 to complete this work. HA reliability could be completely removed from this charter. Kind regards, Behcet ----- Original Message ---- From: Suresh Krishnan To: Jari Arkko Cc: mext@ietf.org Sent: Friday, June 29, 2007 4:26:59 PM Subject: Re: [MEXT] new charter version Hi Jari, The items A.2 and A.3 are reversed in the following descriptive text "Deployment considerations call for (A.1) solutions to enable dual-stack operation, (A.2) allowing the use of multiple interfaces in mobile nodes, (A.3) mechanisms to support high-availability home agents,..." whereas in the following bulleted list A.2 talks about HA reliability and A.3 talks about multiple interfaces in MNs. Cheers Suresh Jari Arkko wrote: > Testing the new list... this list should have all the subscribers > of the existing three lists. For now, please continue your > technical discussions in the existing lists, except for charter > discussion which we can move here. In general, you do not > need to take any action with regards to list changes, once > we are ready to move complete away from the old lists we > can deal with the from the secretariat. Here's a pointer > to the list page: > > https://www1.ietf.org/mailman/listinfo/mext > > Here's the new charter, revised according to comments > from many of you (thanks!) and the rest of the IESG. > > The charter will go out soon for public IETF review. > > ------ > > Mobility EXTensions for IPv6 (MEXT) > > Chair(s): > TBD > > Internet Area Director(s): > Jari Arkko > Mark Townsley > > Internet Area Advisor: > Jari Arkko > > Mailing Lists: > https://www1.ietf.org/mailman/listinfo/mext > http://www1.ietf.org/mail-archive/web/mext/current/index.html > > > Description of Working Group: > > Mobile IPv6 specifies routing support which permits an IPv6 host to > continue using its home address as it moves around the Internet, > enabling continuity of sessions. Mobile IPv6 supports transparency > above the IP layer, including maintenance of active transport level > sessions. In addition, NEMO network mobility mechanisms built on top > of Mobile IPv6 allow managing the mobility of an entire network, as it > changes its point of attachment to the Internet. The base > specifications consist of: > > o RFC 3775 > o RFC 3963 > o RFC 4877 > > The MEXT Working Group continues the work of the MIP6, NEMO, and > MONAMI6 Working Groups. > > The primary goal of MEXT will be to (A) enhance base IPv6 mobility by > continuing work on developments that are required for wide-scale > deployments and specific deployment scenarios. Additionally, (B) the > working group will ensure that any issues identified by implementation > and interoperability experience are addressed, and that the base > specifications are maintained. (C) The group will also produce > informational documentation, such as design rationale documents or > description of specific issues within the protocol. > > Deployment considerations call for (A.1) solutions to enable > dual-stack operation, (A.2) allowing the use of multiple interfaces in > mobile nodes, (A.3) mechanisms to support high-availability home > agents, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, > (A.5) address the specific needs of automotive and aviation > communities for route optimisation in network mobility, and (A.6) > support for AAA is needed as a continuation of earlier work on > bootstrapping. > > Work items related to large scale deployment include: > > (A.1) A Solution for MIP6 session continuity for dual stack hosts which > attach to IPv4 access networks. Additionally provide a mechanism > for carrying IPv4 packets via the Home agent for MIP6 capable > dual-stack hosts. > > (A.2) A protocol based solution for enhancing the reliability of home > agents and a method to force a host to switch home agents. > > A mechanism to force an MN to switch the HA that is currently > serving it. This is required in deployments where the HA needs to > be taken offline for maintenance. > > (A.3) Use of multiple interfaces. > > Today, the protocols do not provide suppport for simultaneous > differentiated use of multiple access technologies. Several > proposals exist for such support, and some of them have been > implemented and tested. > > When a mobile host/router uses multiple network interfaces > simultaneously, or when multiple prefixes are available on a > single network interface, the mobile host/router would end up > with multiple Care-of Addresses (CoAs). In addition, the Home > Agent might be attached to multiple network interfaces, or to a > single network interface with multiple prefixes, hence resulting > in the option to use multiple IP addresses for the Home > Agent. This could result in the possibility of using a multitude > of bi-directional tunnels between pairs of {Home Agent address, > CoA} and a number of associated issues: establishment, selection > and modification of multiple simultaneous tunnels. > > The objective of the WG is to produce a clear problem statement > and to produce standard track specifications to the problems > associated with the simultaneous use of multiple addresses for > either mobile hosts using Mobile IPv6 or mobile routers using > NEMO Basic Support and their variants (FMIPv6, HMIPv6, > etc). Where the effects of having multiple prefixes on a single > interface is identical to the effects of having multiple > interfaces each with a single prefix, the WG will consider a > generalized approach to cater for multiple prefixes available to > a mobile host/router. > > The WG uses existing tunneling mechanisms defined for Mobile > IPv6. The involved nodes need to select which tunnel instance > to use when multiple ones are available due to multiple > addresses on either end. But the WG does not plan to define a > new mechanism for this, but rather document how to use existing > mechanisms based upon preferences or policies. In particular, > the WG will consider that a tunnel is alive as long as packets > can be exchanged with the corresponding peer. In addition, local > information, such as interface up/down events, or other failure > detection mechanisms can be used to quickly detect failure of > tunnel(s). > > Deliverables related to this include > > - A document explaining the motivations for a node using multiple > interfaces and the scenarios where it may end up with multiple > global addresses on its interfaces [Informational] > > - An analysis document explaining what are the limitations for > mobile hosts using multiple simultaneous Care-of Addresses and Home > Agent addresses using Mobile IPv6, whether issues are specific to > Mobile IPv6 or not [Informational]. > > - A protocol extension to support the registration of multiple > Care-of Addresses at a given Home Agent address [Standard > Track]. > > - A "Flow/binding policies exchange" solution for an exchange of > policies from the mobile host/router to the Home Agent and from the > Home Agent to the mobile host/router influencing the choice of the > Care-of Address and Home Agent address. The solution involves two > specifications, one for the policy format and another for its > transport [both Standard Track]. > > (A.4) Work on solutions to deal with firewalls and the problems that > firewalls cause as identified in RFC 4487. > > (A.5) Route optimization of network mobility. > > Three use cases have been identified for this. These are called > the Aviation case, the Automotive case, and the Personal Mobile > Router (consumer electronics) case, though the actual technical > problems are characterized by the type of movements and > environments more than by the specific industry using the > technology. The group will explore these cases to gather > requirements and proceed with solving the open issues. > > (1) Airline and spacecraft community, who are deploying NEMO for > control systems, as well as Internet connectivity and > entertainment systems. This use case is characterized by fast (~ > 1000 km/h) moving objects over large distances (across > continents). The main technical problem is that tunneling-based > solutions imply a roundtrip to another continent and that BGP > based solutions imply significant churn in the global Internet > routing table. > > (2) Automotive industry who are deploying NEMO for in-car > communication, entertainment, and data gathering, possible > control systems use, and communication to roadside devices. This > use case is characterized by moderately fast (~ 100-300 km/h) > moving objects that employ local or cellular networks for > connectivity. > > (3) Personal Mobile Routers, which are consumer devices that > allow the user to bring a NEMO network with the user while > mobile, and communicate with peer NEMO Basic Support nodes > and nodes served by them. > > After gathering the requirements for these types of deployments, > the working group will evaluate what type of route optimization > needs to be performed (if any), and formulate a solution to > those problems. > > If no requirements for those scenarios can be collected by the > deadline, it will be assumed that the work is premature, and > that type of deployment will be dropped from the WG. > > The group will only consider airline and spacecraft solutions > that combine tunneling solutions for small movements with either > federated tunnel servers or slowly changing end host prefixes. > The group will only consider personal mobile router requirements > about optimized routes to another mobile router belonging to the > same operator. The group will only consider automotive industry > requirements to allow MR-attached hosts to directly access the > network where MR has attached to. Work on automotive and > personal mobile router solutions requires rechartering. > > The WG will not consider extensions to routing protocols. The > group will not consider general multi-homing problems that are > not related to the deployment and maintenance of Mobile IPv6 or > NEMO Basic Support protocols. The group will also not consider > general route optimization, or other problems that are not > related to the deployment and maintenance of NEMO Basic Support > protocols. Similarly, the group will not consider or rely on the > results of general routing architecture, Internet architecture, > or identifier-locator split issues that are discussed in > separate, long term efforts elsewhere in the IETF. Finally, the > group will not consider solutions that require changes from > correspondent nodes in the general Internet > > (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG > require AAA support for Mobile IPv6. Part of this work is > already being done in the DIME WG, but the MEXT WG is chartered > to complete a design for RADIUS. > > > Work items related to base specification maintenance include: > > (B.1) Create and maintain issue lists that are generated on the basis > of implementation and interoperability experience. Address > specific issues with specific updates or revisions of the base > specification. One specific area of concern that should be > analyzed and addressed relates to multilink subnets. > > This work item relates only to corrections and > clarifications. The working group shall not revisit design > decisions or change the protocol. > > (B.2) Update the IANA considerations of RFC 3775 to allow extensions for > experimental purposes as well passing of optional vendor-specific > information. > > (B.3) Finish working group documents that are currently in process, and > submit for RFC. This includes prefix delegation protocol mechanism > for network mobility, and a MIB for NEMO Basic Support. > > > Work items related to informational documentation include: > > (C.1) Produce a design rationale that documents the historical > thinking behind the introduction of an alternative security > mechanism, the Authentication Protocol (RFC 4285). > > > Goals and Milestones: > > Aug 2007 Submit -00 draft on Route Optimization Needs for Aircraft > and Spacecraft Deployments > Aug 2007 Submit -00 draft on Route Optimization Needs for Automobile > and Highway Deployments > Aug 2007 Submit Multiple CoA Registration to IESG > > Sep 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for > publication as Informational. > Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for > publication as a Proposed Standard. > > Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for > publication as a Proposed Standard > Oct 2007 Submit -00 draft on Route Optimization needs for Personal > Mobile Router > > Nov 2007 Submit final doc on Route Optimization Needs for Aircraft > and Spacecraft Deployments, for Informational > Nov 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for > publication as Informational. > > Dec 2007 Submit -00 draft for solution to aircraft/spacecraft problem > Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG > for publication as a Proposed Standard. > Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the > IESG, for Proposed Standard > > Jan 2007 Submit final doc on Route Optimization Needs for Automobile > and Highway Deployments, for Informational > Jan 2007 Submit final doc on Route Optimization needs for Personal > Mobile Router, for Informational > > Feb 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for > publication as a proposed standard. > Feb 2008 Determine how to proceed with remaining automotive/Personal > Mobile Router solutions > > Mar 2008 Submit the final doc on MIB for NEMO Basic Support to the > IESG, for Proposed Standard > Mar 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG > for publication as Informational. > > Apr 2008 Submit Flow/binding policy format to IESG, for Proposed Standard > Apr 2008 Submit Flow/binding policy transport to IESG, for Proposed > Standard > Apr 2007 Submit I-D 'Mobility Header Home Agent Switch Message' to > IESG for publication as a Proposed Standard. > > May 2008 Submit final doc for solution to aircraft/spacecraft problem > to the IESG, for Proposed Standard > May 2008 Recharter to work on the remaining automotive/Personal > Mobile Router solutions > > Jul 2007 Submit Multiple Interfaces Motivations and Scenario to IESG, > for Informational > Jul 2007 Submit Analysis of the use of Multiple Simultaneous Care-of > Addresses and Home Agent addresses, for Informational > > Aug 2008 Submit I-D(s) related to specific updates and corrections of > RFC 3775 to IESG for publication as Proposed Standard. > Aug 2008 Submit I-D 'Home agent reliability' to IESG for publication > as a Proposed Standard. > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --0-1884647686-1183156472=:44768 Content-Type: text/html; charset=ascii
Hi Jari,
  In fact HA reliability work is almost over. I think the current draft is expected to go for WGLC soon and the subteam is almost closed. I don't think it would take Aug 08 to complete this work. HA reliability could be completely removed from this charter.

Kind regards,

Behcet



----- Original Message ----
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: Jari Arkko <jari.arkko@piuha.net>
Cc: mext@ietf.org
Sent: Friday, June 29, 2007 4:26:59 PM
Subject: Re: [MEXT] new charter version

Hi Jari,
   The items A.2 and A.3 are reversed in the following descriptive text

"Deployment considerations call for (A.1) solutions to enable
dual-stack operation, (A.2) allowing the use of multiple interfaces in
mobile nodes, (A.3) mechanisms to support high-availability home
agents,..."

whereas in the following bulleted list A.2 talks about HA reliability
and A.3 talks about multiple interfaces in MNs.

Cheers
Suresh

Jari Arkko wrote:
> Testing the new list... this list should have all the subscribers
> of the existing three lists. For now, please continue your
> technical discussions in the existing lists, except for charter
> discussion which we can move here. In general, you do not
> need to take any action with regards to list changes, once
> we are ready to move complete away from the old lists we
> can deal with the from the secretariat. Here's a pointer
> to the list page:
>
>    https://www1.ietf.org/mailman/listinfo/mext
>
> Here's the new charter, revised according to comments
> from many of you (thanks!) and the rest of the IESG.
>
> The charter will go out soon for public IETF review.
>
> ------
>
> Mobility EXTensions for IPv6 (MEXT)
>
> Chair(s):
> TBD
>
> Internet Area Director(s):
> Jari Arkko <jari.arkko@piuha.net>
> Mark Townsley <townsley@cisco.com>
>
> Internet Area Advisor:
> Jari Arkko <jari.arkko@piuha.net>
>
> Mailing Lists:
> https://www1.ietf.org/mailman/listinfo/mext
> http://www1.ietf.org/mail-archive/web/mext/current/index.html
>
>
> Description of Working Group:
>
> Mobile IPv6 specifies routing support which permits an IPv6 host to
> continue using its home address as it moves around the Internet,
> enabling continuity of sessions. Mobile IPv6 supports transparency
> above the IP layer, including maintenance of active transport level
> sessions. In addition, NEMO network mobility mechanisms built on top
> of Mobile IPv6 allow managing the mobility of an entire network, as it
> changes its point of attachment to the Internet. The base
> specifications consist of:
>
> o RFC 3775
> o RFC 3963
> o RFC 4877
>
> The MEXT Working Group continues the work of the MIP6, NEMO, and
> MONAMI6 Working Groups.
>
> The primary goal of MEXT will be to (A) enhance base IPv6 mobility by
> continuing work on developments that are required for wide-scale
> deployments and specific deployment scenarios.  Additionally, (B) the
> working group will ensure that any issues identified by implementation
> and interoperability experience are addressed, and that the base
> specifications are maintained. (C) The group will also produce
> informational documentation, such as design rationale documents or
> description of specific issues within the protocol.
>
> Deployment considerations call for (A.1) solutions to enable
> dual-stack operation, (A.2) allowing the use of multiple interfaces in
> mobile nodes, (A.3) mechanisms to support high-availability home
> agents, (A.4) ways to employ Mobile IPv6 in the presence of firewalls,
> (A.5) address the specific needs of automotive and aviation
> communities for route optimisation in network mobility, and (A.6)
> support for AAA is needed as a continuation of earlier work on
> bootstrapping.
>
> Work items related to large scale deployment include:
>
> (A.1) A Solution for MIP6 session continuity for dual stack hosts which
>       attach to IPv4 access networks. Additionally provide a mechanism
>       for carrying IPv4 packets via the Home agent for MIP6 capable
>       dual-stack hosts.
>
> (A.2) A protocol based solution for enhancing the reliability of home
>       agents and a method to force a host to switch home agents.
>
>       A mechanism to force an MN to switch the HA that is currently
>       serving it. This is required in deployments where the HA needs to
>       be taken offline for maintenance.
>
> (A.3) Use of multiple interfaces.
>
>       Today, the protocols do not provide suppport for simultaneous
>       differentiated use of multiple access technologies. Several
>       proposals exist for such support, and some of them have been
>       implemented and tested.
>    
>       When a mobile host/router uses multiple network interfaces
>       simultaneously, or when multiple prefixes are available on a
>       single network interface, the mobile host/router would end up
>       with multiple Care-of Addresses (CoAs). In addition, the Home
>       Agent might be attached to multiple network interfaces, or to a
>       single network interface with multiple prefixes, hence resulting
>       in the option to use multiple IP addresses for the Home
>       Agent. This could result in the possibility of using a multitude
>       of bi-directional tunnels between pairs of {Home Agent address,
>       CoA} and a number of associated issues: establishment, selection
>       and modification of multiple simultaneous tunnels.
>    
>       The objective of the WG is to produce a clear problem statement
>       and to produce standard track specifications to the problems
>       associated with the simultaneous use of multiple addresses for
>       either mobile hosts using Mobile IPv6 or mobile routers using
>       NEMO Basic Support and their variants (FMIPv6, HMIPv6,
>       etc). Where the effects of having multiple prefixes on a single
>       interface is identical to the effects of having multiple
>       interfaces each with a single prefix, the WG will consider a
>       generalized approach to cater for multiple prefixes available to
>       a mobile host/router.
>
>       The WG uses existing tunneling mechanisms defined for Mobile
>       IPv6. The involved nodes need to select which tunnel instance
>       to use when multiple ones are available due to multiple
>       addresses on either end. But the WG does not plan to define a
>       new mechanism for this, but rather document how to use existing
>       mechanisms based upon preferences or policies. In particular,
>       the WG will consider that a tunnel is alive as long as packets
>       can be exchanged with the corresponding peer. In addition, local
>       information, such as interface up/down events, or other failure
>       detection mechanisms can be used to quickly detect failure of
>       tunnel(s).
>    
>       Deliverables related to this include
>    
>       - A document explaining the motivations for a node using multiple
>         interfaces and the scenarios where it may end up with multiple
>         global addresses on its interfaces [Informational]
>    
>       - An analysis document explaining what are the limitations for
>         mobile hosts using multiple simultaneous Care-of Addresses and Home
>         Agent addresses using Mobile IPv6, whether issues are specific to
>         Mobile IPv6 or not [Informational].
>    
>       - A protocol extension to support the registration of multiple
>         Care-of Addresses at a given Home Agent address [Standard
>         Track].
>    
>       - A "Flow/binding policies exchange" solution for an exchange of
>         policies from the mobile host/router to the Home Agent and from the
>         Home Agent to the mobile host/router influencing the choice of the
>         Care-of Address and Home Agent address. The solution involves two
>         specifications, one for the policy format and another for its
>         transport [both Standard Track].
>      
> (A.4) Work on solutions to deal with firewalls and the problems that
>       firewalls cause as identified in RFC 4487.
>
> (A.5) Route optimization of network mobility.
>
>       Three use cases have been identified for this. These are called
>       the Aviation case, the Automotive case, and the Personal Mobile
>       Router (consumer electronics) case, though the actual technical
>       problems are characterized by the type of movements and
>       environments more than by the specific industry using the
>       technology. The group will explore these cases to gather
>       requirements and proceed with solving the open issues.
>    
>       (1) Airline and spacecraft community, who are deploying NEMO for
>       control systems, as well as Internet connectivity and
>       entertainment systems. This use case is characterized by fast (~
>       1000 km/h) moving objects over large distances (across
>       continents). The main technical problem is that tunneling-based
>       solutions imply a roundtrip to another continent and that BGP
>       based solutions imply significant churn in the global Internet
>       routing table.
>    
>       (2) Automotive industry who are deploying NEMO for in-car
>       communication, entertainment, and data gathering, possible
>       control systems use, and communication to roadside devices. This
>       use case is characterized by moderately fast (~ 100-300 km/h)
>       moving objects that employ local or cellular networks for
>       connectivity.
>    
>       (3) Personal Mobile Routers, which are consumer devices that
>       allow the user to bring a NEMO network with the user while
>       mobile, and communicate with peer NEMO Basic Support nodes
>       and nodes served by them.
>    
>       After gathering the requirements for these types of deployments,
>       the working group will evaluate what type of route optimization
>       needs to be performed (if any), and formulate a solution to
>       those problems.
>    
>       If no requirements for those scenarios can be collected by the
>       deadline, it will be assumed that the work is premature, and
>       that type of deployment will be dropped from the WG.
>    
>       The group will only consider airline and spacecraft solutions
>       that combine tunneling solutions for small movements with either
>       federated tunnel servers or slowly changing end host prefixes.
>       The group will only consider personal mobile router requirements
>       about optimized routes to another mobile router belonging to the
>       same operator. The group will only consider automotive industry
>       requirements to allow MR-attached hosts to directly access the
>       network where MR has attached to. Work on automotive and
>       personal mobile router solutions requires rechartering.
>
>       The WG will not consider extensions to routing protocols. The
>       group will not consider general multi-homing problems that are
>       not related to the deployment and maintenance of Mobile IPv6 or
>       NEMO Basic Support protocols. The group will also not consider
>       general route optimization, or other problems that are not
>       related to the deployment and maintenance of NEMO Basic Support
>       protocols. Similarly, the group will not consider or rely on the
>       results of general routing architecture, Internet architecture,
>       or identifier-locator split issues that are discussed in
>       separate, long term efforts elsewhere in the IETF. Finally, the
>       group will not consider solutions that require changes from
>       correspondent nodes in the general Internet
>
> (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG
>       require AAA support for Mobile IPv6. Part of this work is
>       already being done in the DIME WG, but the MEXT WG is chartered
>       to complete a design for RADIUS.
>
>
> Work items related to base specification maintenance include:
>
> (B.1) Create and maintain issue lists that are generated on the basis
>       of implementation and interoperability experience. Address
>       specific issues with specific updates or revisions of the base
>       specification. One specific area of concern that should be
>       analyzed and addressed relates to multilink subnets.
>
>       This work item relates only to corrections and
>       clarifications. The working group shall not revisit design
>       decisions or change the protocol.
>
> (B.2) Update the IANA considerations of RFC 3775 to allow extensions for
>       experimental purposes as well passing of optional vendor-specific
>       information.
>
> (B.3) Finish working group documents that are currently in process, and
>       submit for RFC. This includes prefix delegation protocol mechanism
>       for network mobility, and a MIB for NEMO Basic Support.
>
>
> Work items related to informational documentation include:
>
> (C.1) Produce a design rationale that documents the historical
>       thinking behind the introduction of an alternative security
>       mechanism, the Authentication Protocol (RFC 4285).
>
>
> Goals and Milestones:
>
> Aug 2007    Submit -00 draft on Route Optimization Needs for Aircraft
> and Spacecraft Deployments
> Aug 2007    Submit -00 draft on Route Optimization Needs for Automobile
> and Highway Deployments
> Aug 2007    Submit Multiple CoA Registration to IESG
>
> Sep 2007    Submit I-D 'Motivation for Authentication I-D' to IESG for
> publication as Informational.
> Sep 2007    Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for
> publication as a Proposed Standard.
>
> Oct 2007    Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for
> publication as a Proposed Standard
> Oct 2007    Submit -00 draft on Route Optimization needs for Personal
> Mobile Router
>
> Nov 2007    Submit final doc on Route Optimization Needs for Aircraft
> and Spacecraft Deployments, for Informational
> Nov 2007    Submit I-D 'Goals for AAA HA Interface' to IESG for
> publication as Informational.
>
> Dec 2007    Submit -00 draft for solution to aircraft/spacecraft problem
> Dec 2007    Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG
> for publication as a Proposed Standard.
> Dec 2007    Submit the final doc on Prefix Delegation for NEMO to the
> IESG, for Proposed Standard
>
> Jan 2007    Submit final doc on Route Optimization Needs for Automobile
> and Highway Deployments, for Informational
> Jan 2007    Submit final doc on Route Optimization needs for Personal
> Mobile Router, for Informational
>
> Feb 2008    Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for
> publication as a proposed standard.
> Feb 2008    Determine how to proceed with remaining automotive/Personal
> Mobile Router solutions
>
> Mar 2008    Submit the final doc on MIB for NEMO Basic Support to the
> IESG, for Proposed Standard
> Mar 2008    Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG
> for publication as Informational.
>
> Apr 2008    Submit Flow/binding policy format to IESG, for Proposed Standard
> Apr 2008    Submit Flow/binding policy transport to IESG, for Proposed
> Standard
> Apr 2007    Submit I-D 'Mobility Header Home Agent Switch Message' to
> IESG for publication as a Proposed Standard.
>
> May 2008    Submit final doc for solution to aircraft/spacecraft problem
> to the IESG, for Proposed Standard
> May 2008    Recharter to work on the remaining automotive/Personal
> Mobile Router solutions
>
> Jul 2007    Submit Multiple Interfaces Motivations and Scenario to IESG,
> for Informational
> Jul 2007    Submit Analysis of the use of Multiple Simultaneous Care-of
> Addresses and Home Agent addresses, for Informational
>
> Aug 2008    Submit I-D(s) related to specific updates and corrections of
> RFC 3775 to IESG for publication as Proposed Standard.
> Aug 2008    Submit I-D 'Home agent reliability' to IESG for publication
> as a Proposed Standard.
>
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www1.ietf.org/mailman/listinfo/mext


_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www1.ietf.org/mailman/listinfo/mext

--0-1884647686-1183156472=:44768-- --===============0222891421== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============0222891421==-- From mip6-bounces@ietf.org Fri Jun 29 21:43: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 1I4Rzi-0006fe-W4; Fri, 29 Jun 2007 21:43:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Rzh-0006bd-F9 for mip6@ietf.org; Fri, 29 Jun 2007 21:43:25 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Rzc-0005ha-Jx for mip6@ietf.org; Fri, 29 Jun 2007 21:43:25 -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 l5U1h6Fj030415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 29 Jun 2007 18:43:07 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l5U1h5DR024152; Fri, 29 Jun 2007 18:43:05 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 18:43:05 -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] bootstrapping-splitanycast/ikev2 ha selection feature Date: Fri, 29 Jun 2007 18:43:09 -0700 Message-ID: In-Reply-To: <5e2406980706290302m6aa2ef8bi80de87a2a1b6b79e@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] bootstrapping-splitanycast/ikev2 ha selection feature Thread-Index: Ace6NYufidnrX5wdTjSb7EIValwL+gAZujbA References: <4680D95F.10403@piuha.net> <46816A07.50903@azairenet.com> <0b3601c7b82b$43257020$576115ac@dcml.docomolabsusa.com> <1FEB9B9F2EC38343955D02B2AE86AACB2E9A9B@lan-ex-02.panasonic.de> <46821CFA.5050106@piuha.net> <1FEB9B9F2EC38343955D02B2AE86AACB2E9AB7@lan-ex-02.panasonic.de> <0c6f01c7b8dc$b5850ca0$576115ac@dcml.docomolabsusa.com> <1FEB9B9F2EC38343955D02B2AE86AACB2E9B96@lan-ex-02.panasonic.de> <0ee501c7b9b2$52622730$576115ac@dcml.docomolabsusa.com> <5e2406980706290302m6aa2ef8bi80de87a2a1b6b79e@mail.gmail.com> From: "Narayanan, Vidya" To: "Julien Bournelle" X-OriginalArrivalTime: 30 Jun 2007 01:43:05.0420 (UTC) FILETIME=[00D730C0:01C7BAB8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: James Kempf , draft-ietf-mip6-bootstrapping-split@tools.ietf.org, Mobile IPv6 Mailing List , Kilian Weniger , Sam Hartman , Brian E Carpenter 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 > We could provide an HA anycast address to the MN even in the=20 > integrated scenario. >=20 Yes, but, this particular thread is more about using anycast in IKEv2 and whether that should be more generic a capability than specifically for the HA discovery mechanism.=20 Vidya _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mext-bounces@ietf.org Sat Jun 30 13: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 1I4gSh-0008GV-Ma; Sat, 30 Jun 2007 13:10:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4gSg-0008GN-S7 for mext@ietf.org; Sat, 30 Jun 2007 13:10:18 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4gSZ-0001Wn-Vf for mext@ietf.org; Sat, 30 Jun 2007 13:10:18 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 61E561986A7 for ; Sat, 30 Jun 2007 20:10:11 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1E6D119866D for ; Sat, 30 Jun 2007 20:10:11 +0300 (EEST) Message-ID: <46868E73.3080705@piuha.net> Date: Sat, 30 Jun 2007 20:10:11 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: mext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [MEXT] test X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Testing a list problem, please ignore. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext