From mip6-bounces@ietf.org Sun Jul 01 00:28: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 1I4r34-0006zm-5y; Sun, 01 Jul 2007 00:28:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4r31-0006vM-R2; Sun, 01 Jul 2007 00:28:32 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4r31-00066z-CQ; Sun, 01 Jul 2007 00:28:31 -0400 Received: from oaamta04sl.mx.bigpond.com ([124.190.105.118]) by omta04sl.mx.bigpond.com with ESMTP id <20070701042723.MUIF2916.omta04sl.mx.bigpond.com@oaamta04sl.mx.bigpond.com>; Sun, 1 Jul 2007 04:27:23 +0000 Received: from PC20005 ([124.190.105.118]) by oaamta04sl.mx.bigpond.com with ESMTP id <20070701042722.EZGX22522.oaamta04sl.mx.bigpond.com@PC20005>; Sun, 1 Jul 2007 04:27:22 +0000 From: "Hesham Soliman" To: , Date: Sun, 1 Jul 2007 14:27: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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 thread-index: Ace7mBtfZ3/6qerdQv62CoSb8S1s9w== Message-Id: <20070701042722.EZGX22522.oaamta04sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Subject: [Mip6] Issue 93 - way forward X-BeenThere: mip6@ietf.org X-Mailman-Version: 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, Some of the people involved in the recent discussions on issue 93, the NETLMM chairs and the AD had a teleconference a few days ago to discuss how to address the lack of concensus on this issue. The aim of the meeting was to find a way of accomodating both sides with one solution that avoids the technical inefficiency/lack of flexibility concerns of both sides. The following is a summary of what we agreed on in the meeting. The agreement was to define a way of handling both cases (presence of TLV or not). To do that two different mechanisms were proposed, I'll list a summary of each one below. 1. Implicit signalling The idea is to use the first byte after the UDP header to switch on whether the following header is IP (v4 or v6) or a TLV header. Effectively, the first byte is the version field of the IP header. versions 4 or 6 have the obvious meaning, for the TLV header we can use one of the version numbers that are not used today like 0 or 1. So for instance, 0 means TLV, 4 means IPv4, and 6 means IPv6. Jari mentioned that this is used by other protocols like MPLS and it is considered a hack by some people on the IESG but in our case we use a specific port number for DSMIP therefore no one who does not implement the DSMIP spec should receive this. So, when using this alternative, the TLV would look something like this: Format (1byte) Type (1byte) Length (2 bytes) Format is just a bad name I use in this email to indicate that this byte is used to identify the format of the following information (IP header or TLV) Type is the message type length is the message length 2. Explicit signalling In this mechanism we define a new flag in the BU that, when set, indicates that the MN/MR wants to use the following format: IP UDP TLV ...etc when the flag is cleared, it indicates the the MN/MR wants to use the following format: IP UDP ...etc (i.e. no TLV). Obviously when using this mechanism there must be a default mechanism for sending the BU itself. I.e., we can always send the BU in the current UDP encapsulation format witohut the TLV but if the request is accepted then data packets are sent as agreed during the BU/BA exchange. In either solution we will have to mandate that both the HA and the MN support the negotiation mechanism and one default format. So, all implementations have to support the current format of UDP encapsulation as a base. This allows for interoperability. In this alternative there is no need for the Format field in alternative 1, we only need to define Type and Length fields with one byte reserved. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jul 01 00:32: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 1I4r6w-0002UV-9s; Sun, 01 Jul 2007 00:32:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4r6u-0002TI-Li; Sun, 01 Jul 2007 00:32:32 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4r6u-0006HG-6i; Sun, 01 Jul 2007 00:32:32 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.190.105.118]) by omta05sl.mx.bigpond.com with ESMTP id <20070701043132.RNZS1743.omta05sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Sun, 1 Jul 2007 04:31:32 +0000 Received: from PC20005 ([124.190.105.118]) by oaamta07sl.mx.bigpond.com with ESMTP id <20070701043131.IXPC23012.oaamta07sl.mx.bigpond.com@PC20005>; Sun, 1 Jul 2007 04:31:31 +0000 From: "Hesham Soliman" To: "'Hesham Soliman'" , , Subject: RE: [Mip6] Issue 93 - way forward Date: Sun, 1 Jul 2007 14:31: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: <20070701042722.EZGX22522.oaamta04sl.mx.bigpond.com@PC20005> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 thread-index: Ace7mBtfZ3/6qerdQv62CoSb8S1s9wAAIOuw Message-Id: <20070701043131.IXPC23012.oaamta07sl.mx.bigpond.com@PC20005> 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 Sorry, I forgot to mention the obvious, please send your comments ASAP so I can update the draft. Hesham > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Sunday, July 01, 2007 2:27 PM > To: mip6@ietf.org; nemo@ietf.org > Subject: [Mip6] Issue 93 - way forward > > Folks, > > Some of the people involved in the recent discussions on > issue 93, the > NETLMM chairs and the AD had a teleconference a few days ago > to discuss how > to address the lack of concensus on this issue. The aim of > the meeting was > to find a way of accomodating both sides with one solution > that avoids the > technical inefficiency/lack of flexibility concerns of both sides. > > The following is a summary of what we agreed on in the meeting. > > The agreement was to define a way of handling both cases > (presence of TLV or > not). To do that two different mechanisms were proposed, > I'll list a summary > of each one below. > > 1. Implicit signalling > > The idea is to use the first byte after the UDP header to > switch on whether > the following header is IP (v4 or v6) or a TLV header. > Effectively, the > first byte is the version field of the IP header. versions 4 > or 6 have the > obvious meaning, for the TLV header we can use one of the > version numbers > that are not used today like 0 or 1. So for instance, 0 > means TLV, 4 means > IPv4, and 6 means IPv6. > Jari mentioned that this is used by other protocols like > MPLS and it is > considered a hack by some people on the IESG but in our case we use a > specific port number for DSMIP therefore no one who does not > implement the > DSMIP spec should receive this. > > So, when using this alternative, the TLV would look > something like this: > > Format (1byte) Type (1byte) Length (2 bytes) > > Format is just a bad name I use in this email to indicate > that this byte is > used to identify the format of the following information (IP > header or TLV) > > Type is the message type > length is the message length > > 2. Explicit signalling > > In this mechanism we define a new flag in the BU that, when > set, indicates > that the MN/MR wants to use the following format: > IP > UDP > TLV > ...etc > when the flag is cleared, it indicates the the MN/MR wants to use the > following format: > IP > UDP > ...etc (i.e. no TLV). > > Obviously when using this mechanism there must be a default > mechanism for > sending the BU itself. I.e., we can always send the BU in > the current UDP > encapsulation format witohut the TLV but if the request is > accepted then > data packets are sent as agreed during the BU/BA exchange. > > In either solution we will have to mandate that both the HA > and the MN > support the negotiation mechanism and one default format. So, all > implementations have to support the current format of UDP > encapsulation as a > base. This allows for interoperability. > > In this alternative there is no need for the Format field in > alternative 1, > we only need to define Type and Length fields with one byte reserved. > > > 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 Mon Jul 02 05:59: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 1I5Igo-0004Cn-MO; Mon, 02 Jul 2007 05:59:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Ign-0004CH-9e; Mon, 02 Jul 2007 05:59:25 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5Igm-0002yb-QP; Mon, 02 Jul 2007 05:59:25 -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 l629wbSn026939; Mon, 2 Jul 2007 12:58:43 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 12:58:18 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 12:58:18 +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, 2 Jul 2007 12:58:17 +0300 Message-ID: <58357EDC7884E24BAD684C1B2D91F96D05C361C6@trebe101.NOE.Nokia.com> In-Reply-To: <20070701042722.EZGX22522.oaamta04sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Issue 93 - way forward Thread-Index: Ace7mBtfZ3/6qerdQv62CoSb8S1s9wA8zQQA References: <20070701042722.EZGX22522.oaamta04sl.mx.bigpond.com@PC20005> From: To: , , X-OriginalArrivalTime: 02 Jul 2007 09:58:18.0692 (UTC) FILETIME=[84283040:01C7BC8F] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Subject: [Mip6] RE: [nemo] Issue 93 - way forward X-BeenThere: mip6@ietf.org X-Mailman-Version: 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, Nice to see this issue finally moving forward.=20 So in mechanism 1, how would the MN signal the HA when to use TLV? Would the MN just start using the TLV option and the HA enables it as well when the first TLV tunneled packet is received from the MN? How does the MN even know the HA supports the TLV unless the support in mandated? ICMP error? Error code in BACK? I'm leaning towards the explicit signalling. IMHO, having the new flags in BU/BACK is much cleaner approach. Cheers, Markku >-----Original Message----- >From: ext Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 >Sent: 01 July, 2007 07:27 >To: mip6@ietf.org; nemo@ietf.org >Subject: [nemo] Issue 93 - way forward > >Folks,=20 > >Some of the people involved in the recent discussions on issue=20 >93, the NETLMM chairs and the AD had a teleconference a few=20 >days ago to discuss how to address the lack of concensus on=20 >this issue. The aim of the meeting was to find a way of=20 >accomodating both sides with one solution that avoids the=20 >technical inefficiency/lack of flexibility concerns of both sides. > >The following is a summary of what we agreed on in the meeting.=20 > >The agreement was to define a way of handling both cases=20 >(presence of TLV or not). To do that two different mechanisms=20 >were proposed, I'll list a summary of each one below.=20 > >1. Implicit signalling > >The idea is to use the first byte after the UDP header to=20 >switch on whether the following header is IP (v4 or v6) or a=20 >TLV header. Effectively, the first byte is the version field=20 >of the IP header. versions 4 or 6 have the obvious meaning,=20 >for the TLV header we can use one of the version numbers that=20 >are not used today like 0 or 1. So for instance, 0 means TLV,=20 >4 means IPv4, and 6 means IPv6.=20 >Jari mentioned that this is used by other protocols like MPLS=20 >and it is considered a hack by some people on the IESG but in=20 >our case we use a specific port number for DSMIP therefore no=20 >one who does not implement the DSMIP spec should receive this.=20 > >So, when using this alternative, the TLV would look something=20 >like this: > >Format (1byte) Type (1byte) Length (2 bytes) > >Format is just a bad name I use in this email to indicate that=20 >this byte is used to identify the format of the following=20 >information (IP header or TLV) > >Type is the message type >length is the message length > >2. Explicit signalling > >In this mechanism we define a new flag in the BU that, when=20 >set, indicates that the MN/MR wants to use the following format: > IP > UDP > TLV > ...etc >when the flag is cleared, it indicates the the MN/MR wants to=20 >use the following format: > IP > UDP > ...etc (i.e. no TLV).=20 > >Obviously when using this mechanism there must be a default=20 >mechanism for sending the BU itself. I.e., we can always send=20 >the BU in the current UDP encapsulation format witohut the TLV=20 >but if the request is accepted then data packets are sent as=20 >agreed during the BU/BA exchange.=20 > >In either solution we will have to mandate that both the HA=20 >and the MN support the negotiation mechanism and one default=20 >format. So, all implementations have to support the current=20 >format of UDP encapsulation as a base. This allows for=20 >interoperability.=20 > >In this alternative there is no need for the Format field in=20 >alternative 1, we only need to define Type and Length fields=20 >with one byte reserved. > > >Hesham > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 02 07:54: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 1I5KUJ-0003nk-Iu; Mon, 02 Jul 2007 07:54:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5KUI-0003nH-77; Mon, 02 Jul 2007 07:54:38 -0400 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5KUB-0003qT-6N; Mon, 02 Jul 2007 07:54:38 -0400 Received: from oaamta02sl.mx.bigpond.com ([124.190.105.118]) by omta02sl.mx.bigpond.com with ESMTP id <20070702115427.GGLT1821.omta02sl.mx.bigpond.com@oaamta02sl.mx.bigpond.com>; Mon, 2 Jul 2007 11:54:27 +0000 Received: from PC20005 ([124.190.105.118]) by oaamta02sl.mx.bigpond.com with ESMTP id <20070702115427.CSVS338.oaamta02sl.mx.bigpond.com@PC20005>; Mon, 2 Jul 2007 11:54:27 +0000 From: "Hesham Soliman" To: , , Date: Mon, 2 Jul 2007 21:54: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 Thread-Index: Ace7mBtfZ3/6qerdQv62CoSb8S1s9wA8zQQAAAUDPiA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <58357EDC7884E24BAD684C1B2D91F96D05C361C6@trebe101.NOE.Nokia.com> Message-Id: <20070702115427.CSVS338.oaamta02sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Subject: [Mip6] RE: [nemo] Issue 93 - way forward X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > Nice to see this issue finally moving forward. > So in mechanism 1, how would the MN signal the HA when to > use TLV? Would > the MN just start using the TLV > option and the HA enables it as well when the first TLV > tunneled packet > is received from the MN? How does the MN even > know the HA supports the TLV unless the support in mandated? > ICMP error? > Error code in BACK? => There is no signalling in this option, the packet is just parsed based on the first byte. If the HA doesn't support the TLV then it would have to send an ICMP error. You can't send an error in the BA because the error is in the data flow, which happens after the BU/BA. > > I'm leaning towards the explicit signalling. IMHO, having > the new flags > in BU/BACK is much cleaner approach. => I think it's cleaner too. Hesham > > Cheers, > Markku > > >-----Original Message----- > >From: ext Hesham Soliman [mailto:Hesham@elevatemobile.com] > >Sent: 01 July, 2007 07:27 > >To: mip6@ietf.org; nemo@ietf.org > >Subject: [nemo] Issue 93 - way forward > > > >Folks, > > > >Some of the people involved in the recent discussions on issue > >93, the NETLMM chairs and the AD had a teleconference a few > >days ago to discuss how to address the lack of concensus on > >this issue. The aim of the meeting was to find a way of > >accomodating both sides with one solution that avoids the > >technical inefficiency/lack of flexibility concerns of both sides. > > > >The following is a summary of what we agreed on in the meeting. > > > >The agreement was to define a way of handling both cases > >(presence of TLV or not). To do that two different mechanisms > >were proposed, I'll list a summary of each one below. > > > >1. Implicit signalling > > > >The idea is to use the first byte after the UDP header to > >switch on whether the following header is IP (v4 or v6) or a > >TLV header. Effectively, the first byte is the version field > >of the IP header. versions 4 or 6 have the obvious meaning, > >for the TLV header we can use one of the version numbers that > >are not used today like 0 or 1. So for instance, 0 means TLV, > >4 means IPv4, and 6 means IPv6. > >Jari mentioned that this is used by other protocols like MPLS > >and it is considered a hack by some people on the IESG but in > >our case we use a specific port number for DSMIP therefore no > >one who does not implement the DSMIP spec should receive this. > > > >So, when using this alternative, the TLV would look something > >like this: > > > >Format (1byte) Type (1byte) Length (2 bytes) > > > >Format is just a bad name I use in this email to indicate that > >this byte is used to identify the format of the following > >information (IP header or TLV) > > > >Type is the message type > >length is the message length > > > >2. Explicit signalling > > > >In this mechanism we define a new flag in the BU that, when > >set, indicates that the MN/MR wants to use the following format: > > IP > > UDP > > TLV > > ...etc > >when the flag is cleared, it indicates the the MN/MR wants to > >use the following format: > > IP > > UDP > > ...etc (i.e. no TLV). > > > >Obviously when using this mechanism there must be a default > >mechanism for sending the BU itself. I.e., we can always send > >the BU in the current UDP encapsulation format witohut the TLV > >but if the request is accepted then data packets are sent as > >agreed during the BU/BA exchange. > > > >In either solution we will have to mandate that both the HA > >and the MN support the negotiation mechanism and one default > >format. So, all implementations have to support the current > >format of UDP encapsulation as a base. This allows for > >interoperability. > > > >In this alternative there is no need for the Format field in > >alternative 1, we only need to define Type and Length fields > >with one byte reserved. > > > > > >Hesham > > > > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mext-bounces@ietf.org Mon Jul 02 08:46: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 1I5LIl-0006EL-Ah; Mon, 02 Jul 2007 08:46:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5LIk-00065F-8A for mext@ietf.org; Mon, 02 Jul 2007 08:46:46 -0400 Received: from an-out-0708.google.com ([209.85.132.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5LIG-0000Ag-4R for mext@ietf.org; Mon, 02 Jul 2007 08:46:46 -0400 Received: by an-out-0708.google.com with SMTP id c17so331629anc for ; Mon, 02 Jul 2007 05:46:15 -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=WeROWQjk5kY4XB4bBWbvSShZy8dZskX04/RdJj4ZNOc5ByeU3R+rVR4Z59pKRb/uyETz1EHZ9Qcf31k1WKFw4sWCbQ+TXsUlHBDMHSaa3daT1lLO2tZDnb09Z1cGfQ32F5+ULe+Q9aSaZQkaXCjNm/m557el4oC8bGR3fncxxlw= 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=sskmz/7Z0KmBXEstZry7d7qfNrG/H29KoSV9CHOgQImG0zc5ml+RyBTYzjLsTJAXNuSVzPxJb8tJVdaN6ENUDSxWgOQ484y6iwJWlkOrR80ISO3X285GLSOrSGM5/hbpG2ewKjoW53++KOSIv/QxkpGBLNw3IG8a0EKy5TZxgtk= Received: by 10.100.126.2 with SMTP id y2mr3607942anc.1183380375834; Mon, 02 Jul 2007 05:46:15 -0700 (PDT) Received: by 10.100.135.16 with HTTP; Mon, 2 Jul 2007 05:46:15 -0700 (PDT) Message-ID: <729b68be0707020546i27e6f377s2f60b9ec1032582f@mail.gmail.com> Date: Mon, 2 Jul 2007 14:46:15 +0200 From: "Jean-Michel Combes" To: "Behcet Sarikaya" Subject: Re: [MEXT] new charter version In-Reply-To: <84929.44768.qm@web84106.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <84929.44768.qm@web84106.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Behcet, 2007/6/30, Behcet Sarikaya : > > 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. IMHO, I am not so sure. That depends whether you want, concerning the IPsec failover, a MIP6 WG based solution or a general one (i.e. IFare work) included the draft. > > Kind regards, > > Behcet > [snip] Best regards. JMC. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 02 09:10: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 1I5Lfo-0000Bs-5K; Mon, 02 Jul 2007 09:10:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Lfm-0000Bn-U0 for mext@ietf.org; Mon, 02 Jul 2007 09:10:34 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5Lf3-0006Bu-NV for mext@ietf.org; Mon, 02 Jul 2007 09:10:34 -0400 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 66233C260 for ; Mon, 2 Jul 2007 09:09:48 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l62D9l4B029463; Mon, 2 Jul 2007 09:09:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l62D9lBS005638; Mon, 2 Jul 2007 09:09:47 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 8UJEXmWtiGbc; Mon, 2 Jul 2007 09:09:47 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l62D9gcp005617;Mon, 2 Jul 2007 09:09:42 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 7B9E94FDE7; Mon, 2 Jul 2007 09:06:27 -0400 (EDT) Date: Mon, 2 Jul 2007 09:06:27 -0400 From: Wesley Eddy To: Jean-Michel Combes Subject: Re: [MEXT] new charter version Message-ID: <20070702130627.GD6234@grc.nasa.gov> References: <84929.44768.qm@web84106.mail.mud.yahoo.com> <729b68be0707020546i27e6f377s2f60b9ec1032582f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <729b68be0707020546i27e6f377s2f60b9ec1032582f@mail.gmail.com> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org On Mon, Jul 02, 2007 at 02:46:15PM +0200, Jean-Michel Combes wrote: > Hi Behcet, > > 2007/6/30, Behcet Sarikaya : > > > >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. > > IMHO, I am not so sure. That depends whether you want, concerning the > IPsec failover, a MIP6 WG based solution or a general one (i.e. IFare > work) included the draft. > I agree. When I read it last, it seemed like to meet all of its stated capabilities, the HA reliability work would need to block on the IFARE work, but perhaps it was just unclear and my understanding was wrong. Other than this part, it did seem mostly complete to me. Specifically, there didn't seem to be detailed enough information on the IPsec state synchronization mechanism within the hareliability draft itself to implement both interoperable, and fully-functional solutions. -- Wesley M. Eddy Verizon Federal Network Systems _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mip6-bounces@ietf.org Tue Jul 03 05:13: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 1I5eRk-0000da-Ph; Tue, 03 Jul 2007 05:13:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5eRk-0000dS-3j; Tue, 03 Jul 2007 05:13:20 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5eRg-0006R0-40; Tue, 03 Jul 2007 05:13:20 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2007 11:13:13 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAPuviUaQ/uCLh2dsb2JhbACPIwIJDiw X-IronPort-AV: i="4.16,491,1175464800"; d="scan'208"; a="147086636:sNHT156576160" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l639DDnZ007652; Tue, 3 Jul 2007 11:13:13 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l639D3TC024135; Tue, 3 Jul 2007 09:13:08 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 11:13:03 +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 - way forward Date: Tue, 3 Jul 2007 11:12:50 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC042D27F8@xmb-ams-337.emea.cisco.com> In-Reply-To: <20070701043131.IXPC23012.oaamta07sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Issue 93 - way forward Thread-Index: Ace7mBtfZ3/6qerdQv62CoSb8S1s9wAAIOuwAG38rCA= References: <20070701042722.EZGX22522.oaamta04sl.mx.bigpond.com@PC20005> <20070701043131.IXPC23012.oaamta07sl.mx.bigpond.com@PC20005> From: "Pascal Thubert \(pthubert\)" To: "Hesham Soliman" , , X-OriginalArrivalTime: 03 Jul 2007 09:13:03.0344 (UTC) FILETIME=[5C18B700:01C7BD52] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4427; t=1183453993; x=1184317993; c=relaxed/simple; s=amsdkim2001; 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]=20Issue=2093=20-=20way=20forward |Sender:=20; bh=s8i1+lc3yp9O2arAlcGJzQFwH6mt+UogucfYS5k8RtE=; b=v9SIWiRHnpphyogYwcz9V0PPN9Zyw1GNG6J2NPDcMyMcknwEaRjHhHNc/RRUYpa4+kECefKT Qtvv8JAYGQNKfp3Y2a4Zx3dLTUNo60D6OtHKnKbBiXXQ7V28oepxLtaL; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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,=20 Speaking of obvious, I guess we need to make sure we word this 'the first nibble' as opposed to the first byte, since we are talking about the version which is only the first 4 bits of the payload within UDP :) > > that the MN/MR wants to use the following format: > > IP > > UDP > > TLV Does the tunnel IP mean IPv4 only or do you plan to specify it for both families? I'm just concerned that we might not be symmetrical, which was a strong point of your original draft. Pascal >-----Original Message----- >From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >Sent: Saturday, June 30, 2007 9:31 PM >To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org >Subject: RE: [Mip6] Issue 93 - way forward > >Sorry, I forgot to mention the obvious, please send your comments ASAP so I >can update the draft. > >Hesham > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Sunday, July 01, 2007 2:27 PM > > To: mip6@ietf.org; nemo@ietf.org > > Subject: [Mip6] Issue 93 - way forward > > > > Folks, > > > > Some of the people involved in the recent discussions on > > issue 93, the > > NETLMM chairs and the AD had a teleconference a few days ago > > to discuss how > > to address the lack of concensus on this issue. The aim of > > the meeting was > > to find a way of accomodating both sides with one solution > > that avoids the > > technical inefficiency/lack of flexibility concerns of both sides. > > > > The following is a summary of what we agreed on in the meeting. > > > > The agreement was to define a way of handling both cases > > (presence of TLV or > > not). To do that two different mechanisms were proposed, > > I'll list a summary > > of each one below. > > > > 1. Implicit signalling > > > > The idea is to use the first byte after the UDP header to > > switch on whether > > the following header is IP (v4 or v6) or a TLV header. > > Effectively, the > > first byte is the version field of the IP header. versions 4 > > or 6 have the > > obvious meaning, for the TLV header we can use one of the > > version numbers > > that are not used today like 0 or 1. So for instance, 0 > > means TLV, 4 means > > IPv4, and 6 means IPv6. > > Jari mentioned that this is used by other protocols like > > MPLS and it is > > considered a hack by some people on the IESG but in our case we use a > > specific port number for DSMIP therefore no one who does not > > implement the > > DSMIP spec should receive this. > > > > So, when using this alternative, the TLV would look > > something like this: > > > > Format (1byte) Type (1byte) Length (2 bytes) > > > > Format is just a bad name I use in this email to indicate > > that this byte is > > used to identify the format of the following information (IP > > header or TLV) > > > > Type is the message type > > length is the message length > > > > 2. Explicit signalling > > > > In this mechanism we define a new flag in the BU that, when > > set, indicates > > that the MN/MR wants to use the following format: > > IP > > UDP > > TLV > > ...etc > > when the flag is cleared, it indicates the the MN/MR wants to use the > > following format: > > IP > > UDP > > ...etc (i.e. no TLV). > > > > Obviously when using this mechanism there must be a default > > mechanism for > > sending the BU itself. I.e., we can always send the BU in > > the current UDP > > encapsulation format witohut the TLV but if the request is > > accepted then > > data packets are sent as agreed during the BU/BA exchange. > > > > In either solution we will have to mandate that both the HA > > and the MN > > support the negotiation mechanism and one default format. So, all > > implementations have to support the current format of UDP > > encapsulation as a > > base. This allows for interoperability. > > > > In this alternative there is no need for the Format field in > > alternative 1, > > we only need to define Type and Length fields with one byte reserved. > > > > > > 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 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jul 03 05:45: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 1I5exA-000730-Jh; Tue, 03 Jul 2007 05:45:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5exA-00072p-4y; Tue, 03 Jul 2007 05:45:48 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5ex6-0007Sa-A0; Tue, 03 Jul 2007 05:45:48 -0400 Received: from oaamta08sl.mx.bigpond.com ([124.190.105.118]) by omta04sl.mx.bigpond.com with ESMTP id <20070703094541.TOUS2916.omta04sl.mx.bigpond.com@oaamta08sl.mx.bigpond.com>; Tue, 3 Jul 2007 09:45:41 +0000 Received: from PC20005 ([124.190.105.118]) by oaamta08sl.mx.bigpond.com with ESMTP id <20070703094540.EGBB17816.oaamta08sl.mx.bigpond.com@PC20005>; Tue, 3 Jul 2007 09:45:40 +0000 From: "Hesham Soliman" To: "'Pascal Thubert \(pthubert\)'" , , Subject: RE: [Mip6] Issue 93 - way forward Date: Tue, 3 Jul 2007 19:45:35 +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: <7892795E1A87F04CADFCCF41FADD00FC042D27F8@xmb-ams-337.emea.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace7mBtfZ3/6qerdQv62CoSb8S1s9wAAIOuwAG38rCAAAXl9gA== Message-Id: <20070703094540.EGBB17816.oaamta08sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 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 > Speaking of obvious, I guess we need to make sure we word this 'the > first nibble' as opposed to the first byte, since we are > talking about > the version which is only the first 4 bits of the payload > within UDP :) => Right, once I get a clear idea of which option we're going for we can name things accordingly. So far there was one preference mentioned for option 2. Can you say which one you prefer? > > > > > that the MN/MR wants to use the following format: > > > IP > > > UDP > > > TLV > > Does the tunnel IP mean IPv4 only or do you plan to specify > it for both > families? => To avoid confusion, the text you quoted above was listing the order of headers not the different tunnel types. But to answer your question, the tunnel IP would cover both the same way we have it today. So IP/UDP/IP works regardless of the IP version. I think the same can be done for the TLV but I suspect people would want to define different types for the Type field. Hesham I'm just concerned that we might not be > symmetrical, which was > a strong point of your original draft. > > Pascal > > >-----Original Message----- > >From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > >Sent: Saturday, June 30, 2007 9:31 PM > >To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > >Subject: RE: [Mip6] Issue 93 - way forward > > > >Sorry, I forgot to mention the obvious, please send your > comments ASAP > so I > >can update the draft. > > > >Hesham > > > > > -----Original Message----- > > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > > Sent: Sunday, July 01, 2007 2:27 PM > > > To: mip6@ietf.org; nemo@ietf.org > > > Subject: [Mip6] Issue 93 - way forward > > > > > > Folks, > > > > > > Some of the people involved in the recent discussions on > > > issue 93, the > > > NETLMM chairs and the AD had a teleconference a few days ago > > > to discuss how > > > to address the lack of concensus on this issue. The aim of > > > the meeting was > > > to find a way of accomodating both sides with one solution > > > that avoids the > > > technical inefficiency/lack of flexibility concerns of > both sides. > > > > > > The following is a summary of what we agreed on in the meeting. > > > > > > The agreement was to define a way of handling both cases > > > (presence of TLV or > > > not). To do that two different mechanisms were proposed, > > > I'll list a summary > > > of each one below. > > > > > > 1. Implicit signalling > > > > > > The idea is to use the first byte after the UDP header to > > > switch on whether > > > the following header is IP (v4 or v6) or a TLV header. > > > Effectively, the > > > first byte is the version field of the IP header. versions 4 > > > or 6 have the > > > obvious meaning, for the TLV header we can use one of the > > > version numbers > > > that are not used today like 0 or 1. So for instance, 0 > > > means TLV, 4 means > > > IPv4, and 6 means IPv6. > > > Jari mentioned that this is used by other protocols like > > > MPLS and it is > > > considered a hack by some people on the IESG but in our > case we use > a > > > specific port number for DSMIP therefore no one who does not > > > implement the > > > DSMIP spec should receive this. > > > > > > So, when using this alternative, the TLV would look > > > something like this: > > > > > > Format (1byte) Type (1byte) Length (2 bytes) > > > > > > Format is just a bad name I use in this email to indicate > > > that this byte is > > > used to identify the format of the following information (IP > > > header or TLV) > > > > > > Type is the message type > > > length is the message length > > > > > > 2. Explicit signalling > > > > > > In this mechanism we define a new flag in the BU that, when > > > set, indicates > > > that the MN/MR wants to use the following format: > > > IP > > > UDP > > > TLV > > > ...etc > > > when the flag is cleared, it indicates the the MN/MR wants to use > the > > > following format: > > > IP > > > UDP > > > ...etc (i.e. no TLV). > > > > > > Obviously when using this mechanism there must be a default > > > mechanism for > > > sending the BU itself. I.e., we can always send the BU in > > > the current UDP > > > encapsulation format witohut the TLV but if the request is > > > accepted then > > > data packets are sent as agreed during the BU/BA exchange. > > > > > > In either solution we will have to mandate that both the HA > > > and the MN > > > support the negotiation mechanism and one default format. So, all > > > implementations have to support the current format of UDP > > > encapsulation as a > > > base. This allows for interoperability. > > > > > > In this alternative there is no need for the Format field in > > > alternative 1, > > > we only need to define Type and Length fields with one byte > reserved. > > > > > > > > > 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 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jul 03 05:56: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 1I5f7v-0000WD-Bf; Tue, 03 Jul 2007 05:56:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5f7t-0000W4-OP; Tue, 03 Jul 2007 05:56:53 -0400 Received: from omta03sl.mx.bigpond.com ([144.140.92.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5f7t-00036i-8c; Tue, 03 Jul 2007 05:56:53 -0400 Received: from oaamta03sl.mx.bigpond.com ([124.190.105.118]) by omta03sl.mx.bigpond.com with ESMTP id <20070703095545.MEJU1824.omta03sl.mx.bigpond.com@oaamta03sl.mx.bigpond.com>; Tue, 3 Jul 2007 09:55:45 +0000 Received: from PC20005 ([124.190.105.118]) by oaamta03sl.mx.bigpond.com with ESMTP id <20070703095544.HHAH24129.oaamta03sl.mx.bigpond.com@PC20005>; Tue, 3 Jul 2007 09:55:44 +0000 From: "Hesham Soliman" To: , Subject: RE: [Mip6] Issue 93 - concensus call Date: Tue, 3 Jul 2007 19:55:41 +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: <20070701042722.EZGX22522.oaamta04sl.mx.bigpond.com@PC20005> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace7mBtfZ3/6qerdQv62CoSb8S1s9wBwAf5Q Message-Id: <20070703095544.HHAH24129.oaamta03sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Folks, Please express a choice, preferrably with reasons for one of the two options below. I'd really like to get this in the draft before the deadline. Thanks, Hesham > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Sunday, July 01, 2007 2:27 PM > To: mip6@ietf.org; nemo@ietf.org > Subject: [Mip6] Issue 93 - way forward > > Folks, > > Some of the people involved in the recent discussions on > issue 93, the > NETLMM chairs and the AD had a teleconference a few days ago > to discuss how > to address the lack of concensus on this issue. The aim of > the meeting was > to find a way of accomodating both sides with one solution > that avoids the > technical inefficiency/lack of flexibility concerns of both sides. > > The following is a summary of what we agreed on in the meeting. > > The agreement was to define a way of handling both cases > (presence of TLV or > not). To do that two different mechanisms were proposed, > I'll list a summary > of each one below. > > 1. Implicit signalling > > The idea is to use the first byte after the UDP header to > switch on whether > the following header is IP (v4 or v6) or a TLV header. > Effectively, the > first byte is the version field of the IP header. versions 4 > or 6 have the > obvious meaning, for the TLV header we can use one of the > version numbers > that are not used today like 0 or 1. So for instance, 0 > means TLV, 4 means > IPv4, and 6 means IPv6. > Jari mentioned that this is used by other protocols like > MPLS and it is > considered a hack by some people on the IESG but in our case we use a > specific port number for DSMIP therefore no one who does not > implement the > DSMIP spec should receive this. > > So, when using this alternative, the TLV would look > something like this: > > Format (1byte) Type (1byte) Length (2 bytes) > > Format is just a bad name I use in this email to indicate > that this byte is > used to identify the format of the following information (IP > header or TLV) > > Type is the message type > length is the message length > > 2. Explicit signalling > > In this mechanism we define a new flag in the BU that, when > set, indicates > that the MN/MR wants to use the following format: > IP > UDP > TLV > ...etc > when the flag is cleared, it indicates the the MN/MR wants to use the > following format: > IP > UDP > ...etc (i.e. no TLV). > > Obviously when using this mechanism there must be a default > mechanism for > sending the BU itself. I.e., we can always send the BU in > the current UDP > encapsulation format witohut the TLV but if the request is > accepted then > data packets are sent as agreed during the BU/BA exchange. > > In either solution we will have to mandate that both the HA > and the MN > support the negotiation mechanism and one default format. So, all > implementations have to support the current format of UDP > encapsulation as a > base. This allows for interoperability. > > In this alternative there is no need for the Format field in > alternative 1, > we only need to define Type and Length fields with one byte reserved. > > > 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 Tue Jul 03 07:03: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 1I5gAP-0005s0-8c; Tue, 03 Jul 2007 07:03:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5gAN-0005pG-TC; Tue, 03 Jul 2007 07:03:31 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5gA4-0003qa-BT; Tue, 03 Jul 2007 07:03:31 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2007 13:03:12 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAMPJiUaQ/uCLh2dsb2JhbACPJAIJDiw X-IronPort-AV: i="4.16,492,1175464800"; d="scan'208"; a="147101310:sNHT91580802" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l63B3BV4012105; Tue, 3 Jul 2007 13:03:11 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l63B36TG001612; Tue, 3 Jul 2007 11:03:10 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 13:03:04 +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 - concensus call Date: Tue, 3 Jul 2007 13:03:00 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC042D28DE@xmb-ams-337.emea.cisco.com> In-Reply-To: <20070703095544.HHAH24129.oaamta03sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] Issue 93 - concensus call Thread-Index: Ace7mBtfZ3/6qerdQv62CoSb8S1s9wBwAf5QAAIJtoA= References: <20070701042722.EZGX22522.oaamta04sl.mx.bigpond.com@PC20005> <20070703095544.HHAH24129.oaamta03sl.mx.bigpond.com@PC20005> From: "Pascal Thubert \(pthubert\)" To: "Hesham Soliman" , , X-OriginalArrivalTime: 03 Jul 2007 11:03:04.0379 (UTC) FILETIME=[BA9EB8B0:01C7BD61] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4502; t=1183460591; x=1184324591; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:=20RE=3A=20[nemo]=20RE=3A=20[Mip6]=20Issue=2093=20-=20concensus= 20call |Sender:=20; bh=WUjsgl9gJEQXuSdAkrDV0lueSTaqnEdeFDaEZqPgj0A=; b=R4ceOXB5DZuXaZzjiIvm6LA4o3YYZPXO70zJgn7ItS9IMjBrbItnQ+vDvVUaTq3w6nSi9HiR NrjH76Q6HgIXeoC9Nsksi2T+iOUUNo+wEaUvKznzZcegrRiawOiclR18; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 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: Option 1 is fine with me. Note that we could collapse the format and the type by keeping the type less than x45 which leave ample space to define many TLVs. We have to define the error case when the HA does not support a TLV from the MN which is compatible with eth case when the HA supports only IPv4 and IPv6. OTOH, option 2 seems to demand that we define the interaction if one end supports one value of the flag and the other end does not, on top of the case where a given value for the TLV type is not supported by one party. Usually that ends up with requesting that the HA supports both and be more complex. Do I miss something? Pascal >-----Original Message----- >From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >Sent: Tuesday, July 03, 2007 11:56 AM >To: mip6@ietf.org; nemo@ietf.org >Subject: [nemo] RE: [Mip6] Issue 93 - concensus call > >Folks, > >Please express a choice, preferrably with reasons for one of the two options >below. I'd really like to get this in the draft before the deadline. > >Thanks, >Hesham > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Sunday, July 01, 2007 2:27 PM > > To: mip6@ietf.org; nemo@ietf.org > > Subject: [Mip6] Issue 93 - way forward > > > > Folks, > > > > Some of the people involved in the recent discussions on > > issue 93, the > > NETLMM chairs and the AD had a teleconference a few days ago > > to discuss how > > to address the lack of concensus on this issue. The aim of > > the meeting was > > to find a way of accomodating both sides with one solution > > that avoids the > > technical inefficiency/lack of flexibility concerns of both sides. > > > > The following is a summary of what we agreed on in the meeting. > > > > The agreement was to define a way of handling both cases > > (presence of TLV or > > not). To do that two different mechanisms were proposed, > > I'll list a summary > > of each one below. > > > > 1. Implicit signalling > > > > The idea is to use the first byte after the UDP header to > > switch on whether > > the following header is IP (v4 or v6) or a TLV header. > > Effectively, the > > first byte is the version field of the IP header. versions 4 > > or 6 have the > > obvious meaning, for the TLV header we can use one of the > > version numbers > > that are not used today like 0 or 1. So for instance, 0 > > means TLV, 4 means > > IPv4, and 6 means IPv6. > > Jari mentioned that this is used by other protocols like > > MPLS and it is > > considered a hack by some people on the IESG but in our case we use a > > specific port number for DSMIP therefore no one who does not > > implement the > > DSMIP spec should receive this. > > > > So, when using this alternative, the TLV would look > > something like this: > > > > Format (1byte) Type (1byte) Length (2 bytes) > > > > Format is just a bad name I use in this email to indicate > > that this byte is > > used to identify the format of the following information (IP > > header or TLV) > > > > Type is the message type > > length is the message length > > > > 2. Explicit signalling > > > > In this mechanism we define a new flag in the BU that, when > > set, indicates > > that the MN/MR wants to use the following format: > > IP > > UDP > > TLV > > ...etc > > when the flag is cleared, it indicates the the MN/MR wants to use the > > following format: > > IP > > UDP > > ...etc (i.e. no TLV). > > > > Obviously when using this mechanism there must be a default > > mechanism for > > sending the BU itself. I.e., we can always send the BU in > > the current UDP > > encapsulation format witohut the TLV but if the request is > > accepted then > > data packets are sent as agreed during the BU/BA exchange. > > > > In either solution we will have to mandate that both the HA > > and the MN > > support the negotiation mechanism and one default format. So, all > > implementations have to support the current format of UDP > > encapsulation as a > > base. This allows for interoperability. > > > > In this alternative there is no need for the Format field in > > alternative 1, > > we only need to define Type and Length fields with one byte reserved. > > > > > > 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 Tue Jul 03 07:20: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 1I5gQj-0004Qy-0e; Tue, 03 Jul 2007 07:20:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5gQi-0004Qk-7o; Tue, 03 Jul 2007 07:20:24 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5gQc-0008Dv-Ny; Tue, 03 Jul 2007 07:20:23 -0400 Received: from oaamta04sl.mx.bigpond.com ([124.190.105.118]) by omta04sl.mx.bigpond.com with ESMTP id <20070703112015.VKQW2916.omta04sl.mx.bigpond.com@oaamta04sl.mx.bigpond.com>; Tue, 3 Jul 2007 11:20:15 +0000 Received: from PC20005 ([124.190.105.118]) by oaamta04sl.mx.bigpond.com with ESMTP id <20070703112015.DUHG22522.oaamta04sl.mx.bigpond.com@PC20005>; Tue, 3 Jul 2007 11:20:15 +0000 From: "Hesham Soliman" To: "'Pascal Thubert \(pthubert\)'" , , Subject: RE: [nemo] RE: [Mip6] Issue 93 - concensus call Date: Tue, 3 Jul 2007 21:20:11 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC042D28DE@xmb-ams-337.emea.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace7mBtfZ3/6qerdQv62CoSb8S1s9wBwAf5QAAIJtoAAANrk4A== Message-Id: <20070703112015.DUHG22522.oaamta04sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) 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 > Option 1 is fine with me. Note that we could collapse the > format and the > type by keeping the type less than x45 which leave ample > space to define > many TLVs. We have to define the error case when the HA does > not support > a TLV from the MN which is compatible with eth case when the > HA supports > only IPv4 and IPv6. => Yes that goes back to the previous comment made about option 1. I think the error case would have to be an ICMP message because this is an error on the data path not the signalling path. > > OTOH, option 2 seems to demand that we define the > interaction if one end > supports one value of the flag and the other end does not, => No, it doesn't do that, our suggestion from the conference call was to have a base format that MUST always be supported, in addition to the negotiation mechanism. I'll record your preference for option 1 though unless you change it. Hesham > > >-----Original Message----- > >From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > >Sent: Tuesday, July 03, 2007 11:56 AM > >To: mip6@ietf.org; nemo@ietf.org > >Subject: [nemo] RE: [Mip6] Issue 93 - concensus call > > > >Folks, > > > >Please express a choice, preferrably with reasons for one of the two > options > >below. I'd really like to get this in the draft before the deadline. > > > >Thanks, > >Hesham > > > > > -----Original Message----- > > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > > Sent: Sunday, July 01, 2007 2:27 PM > > > To: mip6@ietf.org; nemo@ietf.org > > > Subject: [Mip6] Issue 93 - way forward > > > > > > Folks, > > > > > > Some of the people involved in the recent discussions on > > > issue 93, the > > > NETLMM chairs and the AD had a teleconference a few days ago > > > to discuss how > > > to address the lack of concensus on this issue. The aim of > > > the meeting was > > > to find a way of accomodating both sides with one solution > > > that avoids the > > > technical inefficiency/lack of flexibility concerns of > both sides. > > > > > > The following is a summary of what we agreed on in the meeting. > > > > > > The agreement was to define a way of handling both cases > > > (presence of TLV or > > > not). To do that two different mechanisms were proposed, > > > I'll list a summary > > > of each one below. > > > > > > 1. Implicit signalling > > > > > > The idea is to use the first byte after the UDP header to > > > switch on whether > > > the following header is IP (v4 or v6) or a TLV header. > > > Effectively, the > > > first byte is the version field of the IP header. versions 4 > > > or 6 have the > > > obvious meaning, for the TLV header we can use one of the > > > version numbers > > > that are not used today like 0 or 1. So for instance, 0 > > > means TLV, 4 means > > > IPv4, and 6 means IPv6. > > > Jari mentioned that this is used by other protocols like > > > MPLS and it is > > > considered a hack by some people on the IESG but in our > case we use > a > > > specific port number for DSMIP therefore no one who does not > > > implement the > > > DSMIP spec should receive this. > > > > > > So, when using this alternative, the TLV would look > > > something like this: > > > > > > Format (1byte) Type (1byte) Length (2 bytes) > > > > > > Format is just a bad name I use in this email to indicate > > > that this byte is > > > used to identify the format of the following information (IP > > > header or TLV) > > > > > > Type is the message type > > > length is the message length > > > > > > 2. Explicit signalling > > > > > > In this mechanism we define a new flag in the BU that, when > > > set, indicates > > > that the MN/MR wants to use the following format: > > > IP > > > UDP > > > TLV > > > ...etc > > > when the flag is cleared, it indicates the the MN/MR wants to use > the > > > following format: > > > IP > > > UDP > > > ...etc (i.e. no TLV). > > > > > > Obviously when using this mechanism there must be a default > > > mechanism for > > > sending the BU itself. I.e., we can always send the BU in > > > the current UDP > > > encapsulation format witohut the TLV but if the request is > > > accepted then > > > data packets are sent as agreed during the BU/BA exchange. > > > > > > In either solution we will have to mandate that both the HA > > > and the MN > > > support the negotiation mechanism and one default format. So, all > > > implementations have to support the current format of UDP > > > encapsulation as a > > > base. This allows for interoperability. > > > > > > In this alternative there is no need for the Format field in > > > alternative 1, > > > we only need to define Type and Length fields with one byte > reserved. > > > > > > > > > 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 Wed Jul 04 03:57: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 1I5zkE-0007Re-Ci; Wed, 04 Jul 2007 03:57:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5zkC-0007RQ-RV; Wed, 04 Jul 2007 03:57:48 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5zk7-0008L6-58; Wed, 04 Jul 2007 03:57:48 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 04 Jul 2007 09:57:39 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKrvikaQ/uCLh2dsb2JhbACPHwEBCQ4s X-IronPort-AV: i="4.16,495,1175464800"; d="scan'208"; a="147180390:sNHT407977912" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l647vcoX001851; Wed, 4 Jul 2007 09:57:38 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l647vPTG018820; Wed, 4 Jul 2007 07:57:38 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 09:57:27 +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] Summary and conclusion of: DS-MIP6 - Consensuscalltoclose issue 93 Date: Wed, 4 Jul 2007 09:57:22 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC042D2C02@xmb-ams-337.emea.cisco.com> In-Reply-To: <017801c7b7c3$a7900dd0$1220fea9@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensuscalltoclose issue 93 Thread-Index: Ace0rDWZxhwuwNAaS8CRy2KiWfMalwDEsshgAZRK1XA= 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> <017801c7b7c3$a7900dd0$1220fea9@amer.cisco.com> From: "Pascal Thubert \(pthubert\)" To: "Sri Gundavelli \(sgundave\)" , "Jari Arkko" X-OriginalArrivalTime: 04 Jul 2007 07:57:27.0429 (UTC) FILETIME=[F6E4C350:01C7BE10] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3676; t=1183535858; x=1184399858; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:=20RE=3A=20[nemo]=20RE=3A=20[Mip6]=20Summary=20and=20conclusion= 20of=3A=20DS-MIP6=20-=20Consensuscalltoclose=20issue=2093 |Sender:=20; bh=w3tzxviu6WROhkE+n/upa/rrcvdsWtwEuyaC/d+hLe8=; b=PGk2As+NcGRwJHvL6tAQAm3AE0ocY3zJPH3I7vS2eZlMV/l1+yRpeHqsm3qYVLW8j/n1RpZ0 J0tYlsQ1bzALkKuPndUPOiSMlyabnB9UnKCsyTu5rGnSZF9b8/y8dC+l; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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 Sri: We went through this KA discussion. Even discussed having an async message sent by the HA with a short TTL or something so that it would pass the NAT but not reach the MN, so the MN could be left sleeping and save battery. But at the end of the day, BU/BA seemed to do the job quite fine, bringing the value of revalidating the BCE when a simple ping would be total loss. Do you have an issue with that? On which side? Pascal >-----Original Message----- >From: Sri Gundavelli (sgundave) >Sent: Tuesday, June 26, 2007 9:29 AM >To: 'Jari Arkko' >Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List'; 'Henrik Levkowetz'; 'Basavaraj Patil' >Subject: [nemo] RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensuscalltoclose issue 93 > >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 Wed Jul 04 04:39: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 1I60OD-0000ze-0j; Wed, 04 Jul 2007 04:39:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I60OC-0000xt-44; Wed, 04 Jul 2007 04:39:08 -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 1I60O5-00072S-Qd; Wed, 04 Jul 2007 04:39:08 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 04 Jul 2007 01:39:01 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAEf5ikarR7PEh2dsb2JhbACPHwEBCQ4s X-IronPort-AV: i="4.16,496,1175497200"; d="scan'208"; a="383510551:sNHT37198286" 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 l648d0RF030781; Wed, 4 Jul 2007 01:39:00 -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 l648cpmo020076; Wed, 4 Jul 2007 08:38:53 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); Wed, 4 Jul 2007 01:38:51 -0700 Received: from sgundavewxp ([10.89.16.214]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 01:38:50 -0700 From: "Sri Gundavelli" To: "'Pascal Thubert \(pthubert\)'" , "'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> <017801c7b7c3$a7900dd0$1220fea9@amer.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC042D2C02@xmb-ams-337.emea.cisco.com> Subject: RE: [nemo] RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensuscalltoclose issue 93 Date: Wed, 4 Jul 2007 01:38:47 -0700 Message-ID: <021d01c7be16$bedbeaf0$ea5e150a@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: Ace0rDWZxhwuwNAaS8CRy2KiWfMalwDEsshgAZRK1XAAAOCSQA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC042D2C02@xmb-ams-337.emea.cisco.com> X-OriginalArrivalTime: 04 Jul 2007 08:38:50.0849 (UTC) FILETIME=[BF209510:01C7BE16] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1644; t=1183538340; x=1184402340; 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]=20Summary=20and=20conclusion= 20of=3A=20DS-MIP6=20-=20Consensuscalltoclose=20issue=2093 |Sender:=20; bh=mbd6zjC+++Rw05V+PIA3tEW1IEBo8CCVoSkFb/nZB3M=; b=V0g5kvlYwulwpTQgADMwsYB2olxw1Ngk22pldzKWrxw6TviWLZ9O/vyNZlHtrRHqOKALOFm3 JgiMowyuCkv8RJ+r+a/UDU7R8N7rmHtcoorOdRYw8Ej4uDy0Jv4HHxwS; 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: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Pascal, > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Wednesday, July 04, 2007 12:57 AM > To: Sri Gundavelli (sgundave); Jari Arkko > Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Henrik > Levkowetz; Basavaraj Patil > Subject: RE: [nemo] RE: [Mip6] Summary and conclusion of: > DS-MIP6 - Consensuscalltoclose issue 93 > > Hi Sri: > > We went through this KA discussion. Even discussed having an async > message sent by the HA with a short TTL or something so that it would > pass the NAT but not reach the MN, so the MN could be left > sleeping and > save battery. But at the end of the day, BU/BA seemed to do the job > quite fine, bringing the value of revalidating the BCE when a simple > ping would be total loss. My concern with the use of BU/BA message as a tunnel keep alive mechanism is the processing load on the HA. The amount of checks the BU message will go through is lot more than a normal keepalive message would go through, in most implementations, IMO. Each time a BU is processed, the home agent needs to search for the BCE in its table for that node and update the lifetime. For a simple keepalive, this entire search can be skipped, its just a echo back and further the message can be skipped when there is data traffic. If the home agent is hosting like 1 to 2 million bindings, we need to pay bit more attention to this. But, if you guys already thought about this issue and if you are convinced, the processing load on the HA for a BU vs a simple KA message is just the same, no issue from my side. Regards Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 05 01:33: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 1I6Jxj-0000Zn-5E; Thu, 05 Jul 2007 01:33:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Jxh-0000EF-3Z for mip6@ietf.org; Thu, 05 Jul 2007 01:33:05 -0400 Received: from otm-mgo00.iij.ad.jp ([210.138.20.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Jxc-00021c-I4 for mip6@ietf.org; Thu, 05 Jul 2007 01:33:05 -0400 Received: OTM-MO(otm-mgo00) id l655WwDk073817; Thu, 5 Jul 2007 14:32:58 +0900 (JST) Received: OTM-MIX(otm-mix01) id l655WwKm025614; Thu, 5 Jul 2007 14:32:58 +0900 (JST) Received: from [127.0.0.1] (jc-ssh00.iij.ad.jp [192.168.174.22]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp01) id l655WvgL034558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 5 Jul 2007 14:32:58 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2578B393-50E0-4D4F-B259-A460A42C845B@iijlab.net> Content-Transfer-Encoding: 7bit From: Keiichi SHIMA Date: Thu, 5 Jul 2007 14:32:56 +0900 To: Mobile IPv6 Mailing List X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ERNST Thierry Subject: [Mip6] Experimental home agent service is available X-BeenThere: mip6@ietf.org X-Mailman-Version: 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 all, The Nautilus6 Project launched the Mobile IPv6 home agent experimental operation service on 1st April 2007 to accelerate the deployment of the next generation IPv6 mobility technology based on Mobile IPv6 and to achieve operational experience. The service provides freely available home agent to those who are interested in using Mobile IPv6 mobile hosts. The following functions are provided at this moment. - User ID registration - To create personal account on the server - Mobile hosts registration - Add/Delete your mobile host information - Retrieve static IPsec key configuration parameters - Downloading mobile host Live CD - Ready to boot Linux CD with Mobile IPv6 function enabled Although the service is simple right now, we are planning to make continuous effort to enhance the service. The service is provided by the WIDE project (Japan) and ENST Bretagne (France) currently. University Louis Pasteur (France) is also planning to start the service soon. For more information, please refer the URLs listed at the end of this announcement. We also provide the web based interface 'HAiku', developed for the service. The software is published as open source software. Please check its availability at the URL listed below. This activity is supported by the WIDE project, University Louis Pasteur, ENST Bretagne and other Nautilus6 member organizations. We hope this service encourages the researchers and developers of IPv6 mobility technologies and help deployment of the technology. Best Regards, --- Thierry Ernst and Keiichi Shima, the chairs of the Nautilus6 project [Experimental home agent operation] https://op-ha.nautilus6.org/ (for all users, operated by the WIDE project) https://ha.labo4g.rennes.enst-bretagne.fr/ (for French academic organizations, operated by ENST Bretagne) http://op-ha.nautilus6.org/documentation/ [HAiku] http://software.nautilus6.org/HAiku/index.php [Mobile IPv6 for BSD/Linux] SHISA: http://www.mobileip.jp/ USAGI: http://www.linux-ipv6.org/ MIPL: http://www.mobile-ipv6.org/ [Organizations] Nautilus6 Project, http://www.nautilus6.org/ WIDE Project, http://www.wide.ad.jp/ University Louis Pasteur, http://www-ulp.u-strasbg.fr/ ENST Bretagne, http://www.enst-bretagne.fr/ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 05 08:47: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 1I6Qjh-00043Z-IY; Thu, 05 Jul 2007 08:47:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Qjd-0003xJ-SO; Thu, 05 Jul 2007 08:47:03 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6QjX-0005Fc-Ap; Thu, 05 Jul 2007 08:47:01 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Jul 2007 14:46:52 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAF6FjEaQ/uCKh2dsb2JhbACPLQEBAQgOLA X-IronPort-AV: i="4.16,503,1175464800"; d="scan'208"; a="147314657:sNHT32074766" 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 l65Ckqa5019658; Thu, 5 Jul 2007 14:46:52 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l65CkVTG009999; Thu, 5 Jul 2007 12:46:43 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 14:46:34 +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] Summary and conclusion of: DS-MIP6 - Consensuscalltoclose issue 93 Date: Thu, 5 Jul 2007 14:46:30 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC042D31BA@xmb-ams-337.emea.cisco.com> In-Reply-To: <021d01c7be16$bedbeaf0$ea5e150a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensuscalltoclose issue 93 Thread-Index: Ace0rDWZxhwuwNAaS8CRy2KiWfMalwDEsshgAZRK1XAAAOCSQAA7Lgcg 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> <017801c7b7c3$a7900dd0$1220fea9@amer.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC042D2C02@xmb-ams-337.emea.cisco.com> <021d01c7be16$bedbeaf0$ea5e150a@amer.cisco.com> From: "Pascal Thubert \(pthubert\)" To: "Sri Gundavelli \(sgundave\)" , "Jari Arkko" X-OriginalArrivalTime: 05 Jul 2007 12:46:34.0762 (UTC) FILETIME=[851F76A0:01C7BF02] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2968; t=1183639612; x=1184503612; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:=20RE=3A=20[nemo]=20RE=3A=20[Mip6]=20Summary=20and=20conclusion= 20of=3A=20DS-MIP6=20-=20Consensuscalltoclose=20issue=2093 |Sender:=20; bh=oiiwy1G6Q84Dv/ngxEEbU7l7DwOQhmvJ6x4pJ7HVWk4=; b=BpbXZ+T/Tqjd6XpaHvwqKbi+nm6Hn1n7yprg1c+ZlRK4dr3UryyyM6roZWUx2Vr2d00ro+4Z avCV7SUmhNJ3Vr5SMTQZmyYhUnBqVOPCKXtpYbAwxurB5KMHEvxi35CV; 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: 4b800b1eab964a31702fa68f1ff0e955 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 Sri: That's fine, then. I agree there is additional processing on a BU but then, this revalidates the cache so you get value for the relatively low CPU increment on the overall message processing from the device driver up.=20 How often should a BCE be refreshed? How long should a HA keep sending packets in the void because it does not know the MN is unreachable at this old CoA? If your deployment permits, that time should be kept short enough. If it is in the order of a minute, the BU exchange should ensure that the NAT state is maintained at no additional cost. That's the tradeoff we ended up agreeing upon. As a result, the draft does not specify a NAT maintenance mechanism and the whole thing ends up as a configuration issue; note also that nothing prevents a particular implementation to add its own secret sauce long as the processing involved (such as pinging) does not bother a standard endpoint. Pascal >-----Original Message----- >From: Sri Gundavelli (sgundave) >Sent: Wednesday, July 04, 2007 10:39 AM >To: Pascal Thubert (pthubert); 'Jari Arkko' >Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List'; 'Henrik Levkowetz'; 'Basavaraj Patil' >Subject: RE: [nemo] RE: [Mip6] Summary and conclusion of: DS-MIP6 - Consensuscalltoclose issue 93 > >Hi Pascal, > > >> -----Original Message----- >> From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] >> Sent: Wednesday, July 04, 2007 12:57 AM >> To: Sri Gundavelli (sgundave); Jari Arkko >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List; Henrik >> Levkowetz; Basavaraj Patil >> Subject: RE: [nemo] RE: [Mip6] Summary and conclusion of: >> DS-MIP6 - Consensuscalltoclose issue 93 >> >> Hi Sri: >> >> We went through this KA discussion. Even discussed having an async >> message sent by the HA with a short TTL or something so that it would >> pass the NAT but not reach the MN, so the MN could be left >> sleeping and >> save battery. But at the end of the day, BU/BA seemed to do the job >> quite fine, bringing the value of revalidating the BCE when a simple >> ping would be total loss. > >My concern with the use of BU/BA message as a tunnel keep alive >mechanism is the processing load on the HA. The amount of checks >the BU message will go through is lot more than a normal keepalive >message would go through, in most implementations, IMO. Each time >a BU is processed, the home agent needs to search for the BCE in its >table for that node and update the lifetime. For a simple keepalive, >this entire search can be skipped, its just a echo back and further >the message can be skipped when there is data traffic. If the home >agent is hosting like 1 to 2 million bindings, we need to pay bit >more attention to this. But, if you guys already thought about this >issue and if you are convinced, the processing load on the HA for a >BU vs a simple KA message is just the same, no issue from my side. > >Regards >Sri > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 05 08:47: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 1I6QjV-0003vL-EX; Thu, 05 Jul 2007 08:46:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6QjT-0003vD-3z; Thu, 05 Jul 2007 08:46:51 -0400 Received: from omta03sl.mx.bigpond.com ([144.140.92.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6QjP-0005BX-4Z; Thu, 05 Jul 2007 08:46:51 -0400 Received: from oaamta03sl.mx.bigpond.com ([124.190.105.118]) by omta03sl.mx.bigpond.com with ESMTP id <20070705124643.KRQA1824.omta03sl.mx.bigpond.com@oaamta03sl.mx.bigpond.com>; Thu, 5 Jul 2007 12:46:43 +0000 Received: from PC20005 ([124.190.105.118]) by oaamta03sl.mx.bigpond.com with ESMTP id <20070705124643.FKGN24129.oaamta03sl.mx.bigpond.com@PC20005>; Thu, 5 Jul 2007 12:46:43 +0000 From: "Hesham Soliman" To: "'Hesham Soliman'" , , Date: Thu, 5 Jul 2007 22:46:39 +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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace7mBtfZ3/6qerdQv62CoSb8S1s9wDaYH+w Message-Id: <20070705124643.FKGN24129.oaamta03sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Subject: [Mip6] RE: Issue 93 - way forward X-BeenThere: mip6@ietf.org X-Mailman-Version: 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, With the deadline fast approaching, I'd like to remind everyone to express a choice, or a "don't care" about this issue. Given the contrast between the amount of emails on this issue before Vs now, I'm inclined to assume that a lot of people who participated before don't care which alternative we go for. So just to be clear, the options are: Alternative 1 Alternative 2 Don't care So far we had one opinion for alt 1 and another for alt 2. Personally, I prefer 2 because it's clearer and doesn't allow for a seamless switch between the two packet formats on a per-packet basis. I think that makes things more predictable for tunnel setup at the HA. I'm also less comfortable with the generic ICMP error response from the HA when the MN sends a packet in a format that is not supported by the HA. I think using the BU to signal which format should be used is cleaner. My 2 cents. Hesham PS: If we get a lot of "don't care" then I'll ask the chairs/AD to make the decisions for us. > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Sunday, July 01, 2007 2:27 PM > To: 'mip6@ietf.org'; 'nemo@ietf.org' > Subject: Issue 93 - way forward > > Folks, > > Some of the people involved in the recent discussions on > issue 93, the NETLMM chairs and the AD had a teleconference > a few days ago to discuss how to address the lack of > concensus on this issue. The aim of the meeting was to find > a way of accomodating both sides with one solution that > avoids the technical inefficiency/lack of flexibility > concerns of both sides. > > The following is a summary of what we agreed on in the meeting. > > The agreement was to define a way of handling both cases > (presence of TLV or not). To do that two different > mechanisms were proposed, I'll list a summary of each one below. > > 1. Implicit signalling > > The idea is to use the first byte after the UDP header to > switch on whether the following header is IP (v4 or v6) or a > TLV header. Effectively, the first byte is the version field > of the IP header. versions 4 or 6 have the obvious meaning, > for the TLV header we can use one of the version numbers > that are not used today like 0 or 1. So for instance, 0 > means TLV, 4 means IPv4, and 6 means IPv6. > Jari mentioned that this is used by other protocols like > MPLS and it is considered a hack by some people on the IESG > but in our case we use a specific port number for DSMIP > therefore no one who does not implement the DSMIP spec > should receive this. > > So, when using this alternative, the TLV would look > something like this: > > Format (1byte) Type (1byte) Length (2 bytes) > > Format is just a bad name I use in this email to indicate > that this byte is used to identify the format of the > following information (IP header or TLV) > > Type is the message type > length is the message length > > 2. Explicit signalling > > In this mechanism we define a new flag in the BU that, when > set, indicates that the MN/MR wants to use the following format: > IP > UDP > TLV > ...etc > when the flag is cleared, it indicates the the MN/MR wants > to use the following format: > IP > UDP > ...etc (i.e. no TLV). > > Obviously when using this mechanism there must be a default > mechanism for sending the BU itself. I.e., we can always > send the BU in the current UDP encapsulation format witohut > the TLV but if the request is accepted then data packets are > sent as agreed during the BU/BA exchange. > > In either solution we will have to mandate that both the HA > and the MN support the negotiation mechanism and one default > format. So, all implementations have to support the current > format of UDP encapsulation as a base. This allows for > interoperability. > > In this alternative there is no need for the Format field in > alternative 1, we only need to define Type and Length fields > with one byte reserved. > > > Hesham > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 05 10:04: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 1I6RwS-0005iL-9y; Thu, 05 Jul 2007 10:04:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6RwP-0005f1-LN; Thu, 05 Jul 2007 10:04:18 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6RwG-00016I-EM; Thu, 05 Jul 2007 10:04:17 -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 l65E44OD007616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Jul 2007 07:04:04 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l65E431s026713; Thu, 5 Jul 2007 07:04:03 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 07:04:03 -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: Issue 93 - way forward Date: Thu, 5 Jul 2007 07:04:02 -0700 Message-ID: In-Reply-To: <20070705124643.FKGN24129.oaamta03sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: Issue 93 - way forward Thread-Index: Ace7mBtfZ3/6qerdQv62CoSb8S1s9wDaYH+wAALofWA= References: <20070705124643.FKGN24129.oaamta03sl.mx.bigpond.com@PC20005> From: "Narayanan, Vidya" To: "Hesham Soliman" , , X-OriginalArrivalTime: 05 Jul 2007 14:04:03.0546 (UTC) FILETIME=[58039BA0:01C7BF0D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I prefer to use an explicit signaling mechanism (Alt 2) as well. =20 Vidya > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Thursday, July 05, 2007 5:47 AM > To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > Subject: [Mip6] RE: Issue 93 - way forward >=20 > Folks,=20 >=20 > With the deadline fast approaching, I'd like to remind=20 > everyone to express a choice, or a "don't care" about this=20 > issue. Given the contrast between the amount of emails on=20 > this issue before Vs now, I'm inclined to assume that a lot=20 > of people who participated before don't care which=20 > alternative we go for.=20 >=20 > So just to be clear, the options are: > Alternative 1 > Alternative 2 > Don't care >=20 > So far we had one opinion for alt 1 and another for alt 2.=20 >=20 > Personally, I prefer 2 because it's clearer and doesn't allow=20 > for a seamless switch between the two packet formats on a=20 > per-packet basis. I think that makes things more predictable=20 > for tunnel setup at the HA. I'm also less comfortable with=20 > the generic ICMP error response from the HA when the MN sends=20 > a packet in a format that is not supported by the HA. I think=20 > using the BU to signal which format should be used is cleaner.=20 >=20 > My 2 cents. >=20 > Hesham >=20 > PS: If we get a lot of "don't care" then I'll ask the=20 > chairs/AD to make the decisions for us. =20 >=20 > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >=20 > Sent: Sunday, July 01, 2007 2:27 PM > To: 'mip6@ietf.org';=20 > 'nemo@ietf.org' > > Subject: Issue 93 - way forward > > > > Folks, > > > > Some of the people involved in the recent discussions on =20 > > issue 93, the NETLMM chairs and the AD had a teleconference=20 > > a few days ago to discuss how to address the lack of >=20 > concensus on this issue. The aim of the meeting was to find =20 > > a way of accomodating both sides with one solution that >=20 > avoids the technical inefficiency/lack of flexibility >=20 > concerns of both sides. > > > > The following is a summary of what we agreed on in the meeting.=20 > > > > The agreement was to define a way of handling both cases =20 > > (presence of TLV or not). To do that two different >=20 > mechanisms were proposed, I'll list a summary of each one below.=20 > > > > 1. Implicit signalling > > > > The idea is to use the first byte after the UDP header to =20 > > switch on whether the following header is IP (v4 or v6) or=20 > a > TLV header. Effectively, the first byte is the version=20 > field > of the IP header. versions 4 or 6 have the obvious=20 > meaning, > for the TLV header we can use one of the version=20 > numbers > that are not used today like 0 or 1. So for=20 > instance, 0 > means TLV, 4 means IPv4, and 6 means IPv6.=20 > > Jari mentioned that this is used by other protocols like =20 > > MPLS and it is considered a hack by some people on the IESG=20 > > but in our case we use a specific port number for DSMIP >=20 > therefore no one who does not implement the DSMIP spec >=20 > should receive this.=20 > > > > So, when using this alternative, the TLV would look >=20 > something like this: > > > > Format (1byte) Type (1byte) Length (2 bytes) > > Format=20 > is just a bad name I use in this email to indicate > that=20 > this byte is used to identify the format of the > following=20 > information (IP header or TLV) > > Type is the message type=20 > > length is the message length > > 2. Explicit signalling =20 > > > In this mechanism we define a new flag in the BU that,=20 > when > set, indicates that the MN/MR wants to use the=20 > following format: > > IP > > UDP > > TLV > > ...etc > > when the flag is cleared, it indicates the the MN/MR wants=20 > > to use the following format: > > IP > > UDP > > ...etc (i.e. no TLV).=20 > > > > Obviously when using this mechanism there must be a=20 > default > mechanism for sending the BU itself. I.e., we can=20 > always > send the BU in the current UDP encapsulation format=20 > witohut > the TLV but if the request is accepted then data=20 > packets are > sent as agreed during the BU/BA exchange.=20 > > > > In either solution we will have to mandate that both the=20 > HA > and the MN support the negotiation mechanism and one=20 > default > format. So, all implementations have to support=20 > the current > format of UDP encapsulation as a base. This=20 > allows for > interoperability.=20 > > > > In this alternative there is no need for the Format field=20 > in > alternative 1, we only need to define Type and Length=20 > fields > with one byte reserved. > > > > > > Hesham > >=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 Jul 05 11:12: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 1I6T0l-0006so-GW; Thu, 05 Jul 2007 11:12:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6T0j-0006sj-Qo for mip6@ietf.org; Thu, 05 Jul 2007 11:12:49 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6T0e-00069z-Re for mip6@ietf.org; Thu, 05 Jul 2007 11:12:49 -0400 X-AuditID: c10cb581-00001f180000150c-ba-468d0a657eab Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 17:12:37 +0200 Received: from mustang.eu.tieto.com ([192.176.143.21]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 17:12: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] RE: Issue 93 - way forward Date: Thu, 5 Jul 2007 17:12:41 +0200 Message-ID: <6C8E068C4D0248408FA49036CC384C8338AB6D@mustang.eu.tieto.com> In-Reply-To: <20070705124643.FKGN24129.oaamta03sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: Issue 93 - way forward Thread-Index: Ace7mBtfZ3/6qerdQv62CoSb8S1s9wDaYH+wAAVQgEA= References: <20070705124643.FKGN24129.oaamta03sl.mx.bigpond.com@PC20005> From: To: X-OriginalArrivalTime: 05 Jul 2007 15:12:43.0113 (UTC) FILETIME=[EF77A590:01C7BF16] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.2 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 X-BeenThere: mip6@ietf.org X-Mailman-Version: 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 prefer alternative 2. Karen=20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Thursday, July 05, 2007 2:47 PM > To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > Subject: [Mip6] RE: Issue 93 - way forward >=20 > Folks,=20 >=20 > With the deadline fast approaching, I'd like to remind=20 > everyone to express a choice, or a "don't care" about this=20 > issue. Given the contrast between the amount of emails on=20 > this issue before Vs now, I'm inclined to assume that a lot=20 > of people who participated before don't care which=20 > alternative we go for.=20 >=20 > So just to be clear, the options are: > Alternative 1 > Alternative 2 > Don't care >=20 > So far we had one opinion for alt 1 and another for alt 2.=20 >=20 > Personally, I prefer 2 because it's clearer and doesn't allow=20 > for a seamless switch between the two packet formats on a=20 > per-packet basis. I think that makes things more predictable=20 > for tunnel setup at the HA. I'm also less comfortable with=20 > the generic ICMP error response from the HA when the MN sends=20 > a packet in a format that is not supported by the HA. I think=20 > using the BU to signal which format should be used is cleaner.=20 >=20 > My 2 cents. >=20 > Hesham >=20 > PS: If we get a lot of "don't care" then I'll ask the=20 > chairs/AD to make the decisions for us. =20 >=20 > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >=20 > Sent: Sunday, July 01, 2007 2:27 PM > To: 'mip6@ietf.org';=20 > 'nemo@ietf.org' > > Subject: Issue 93 - way forward > > > > Folks, > > > > Some of the people involved in the recent discussions on =20 > > issue 93, the NETLMM chairs and the AD had a teleconference=20 > > a few days ago to discuss how to address the lack of >=20 > concensus on this issue. The aim of the meeting was to find =20 > > a way of accomodating both sides with one solution that >=20 > avoids the technical inefficiency/lack of flexibility >=20 > concerns of both sides. > > > > The following is a summary of what we agreed on in the meeting.=20 > > > > The agreement was to define a way of handling both cases =20 > > (presence of TLV or not). To do that two different >=20 > mechanisms were proposed, I'll list a summary of each one below.=20 > > > > 1. Implicit signalling > > > > The idea is to use the first byte after the UDP header to =20 > > switch on whether the following header is IP (v4 or v6) or=20 > a > TLV header. Effectively, the first byte is the version=20 > field > of the IP header. versions 4 or 6 have the obvious=20 > meaning, > for the TLV header we can use one of the version=20 > numbers > that are not used today like 0 or 1. So for=20 > instance, 0 > means TLV, 4 means IPv4, and 6 means IPv6.=20 > > Jari mentioned that this is used by other protocols like =20 > > MPLS and it is considered a hack by some people on the IESG=20 > > but in our case we use a specific port number for DSMIP >=20 > therefore no one who does not implement the DSMIP spec >=20 > should receive this.=20 > > > > So, when using this alternative, the TLV would look >=20 > something like this: > > > > Format (1byte) Type (1byte) Length (2 bytes) > > Format=20 > is just a bad name I use in this email to indicate > that=20 > this byte is used to identify the format of the > following=20 > information (IP header or TLV) > > Type is the message type=20 > > length is the message length > > 2. Explicit signalling =20 > > > In this mechanism we define a new flag in the BU that,=20 > when > set, indicates that the MN/MR wants to use the=20 > following format: > > IP > > UDP > > TLV > > ...etc > > when the flag is cleared, it indicates the the MN/MR wants=20 > > to use the following format: > > IP > > UDP > > ...etc (i.e. no TLV).=20 > > > > Obviously when using this mechanism there must be a=20 > default > mechanism for sending the BU itself. I.e., we can=20 > always > send the BU in the current UDP encapsulation format=20 > witohut > the TLV but if the request is accepted then data=20 > packets are > sent as agreed during the BU/BA exchange.=20 > > > > In either solution we will have to mandate that both the=20 > HA > and the MN support the negotiation mechanism and one=20 > default > format. So, all implementations have to support=20 > the current > format of UDP encapsulation as a base. This=20 > allows for > interoperability.=20 > > > > In this alternative there is no need for the Format field=20 > in > alternative 1, we only need to define Type and Length=20 > fields > with one byte reserved. > > > > > > Hesham > >=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 Jul 05 11:48: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 1I6TZR-0003wU-UJ; Thu, 05 Jul 2007 11:48:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6TPh-0006R7-Tz; Thu, 05 Jul 2007 11:38:37 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6TEI-0008WV-ND; Thu, 05 Jul 2007 11:27: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); Thu, 5 Jul 2007 08:26:49 -0700 Message-ID: <468D0DB4.4030106@azairenet.com> Date: Thu, 05 Jul 2007 08:26:44 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] RE: Issue 93 - way forward References: <20070705124643.FKGN24129.oaamta03sl.mx.bigpond.com@PC20005> In-Reply-To: <20070705124643.FKGN24129.oaamta03sl.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2007 15:26:49.0929 (UTC) FILETIME=[E8358390:01C7BF18] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 prefer alternative 2. Vijay Hesham Soliman wrote: > Folks, > > With the deadline fast approaching, I'd like to remind everyone to express a > choice, or a "don't care" about this issue. Given the contrast between the > amount of emails on this issue before Vs now, I'm inclined to assume that a > lot of people who participated before don't care which alternative we go > for. > > So just to be clear, the options are: > Alternative 1 > Alternative 2 > Don't care > > So far we had one opinion for alt 1 and another for alt 2. > > Personally, I prefer 2 because it's clearer and doesn't allow for a seamless > switch between the two packet formats on a per-packet basis. I think that > makes things more predictable for tunnel setup at the HA. I'm also less > comfortable with the generic ICMP error response from the HA when the MN > sends a packet in a format that is not supported by the HA. I think using > the BU to signal which format should be used is cleaner. > > My 2 cents. > > Hesham > > PS: If we get a lot of "don't care" then I'll ask the chairs/AD to make the > decisions for us. > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Sunday, July 01, 2007 2:27 PM > > To: 'mip6@ietf.org'; 'nemo@ietf.org' > > Subject: Issue 93 - way forward > > > > Folks, > > > > Some of the people involved in the recent discussions on > > issue 93, the NETLMM chairs and the AD had a teleconference > > a few days ago to discuss how to address the lack of > > concensus on this issue. The aim of the meeting was to find > > a way of accomodating both sides with one solution that > > avoids the technical inefficiency/lack of flexibility > > concerns of both sides. > > > > The following is a summary of what we agreed on in the meeting. > > > > The agreement was to define a way of handling both cases > > (presence of TLV or not). To do that two different > > mechanisms were proposed, I'll list a summary of each one below. > > > > 1. Implicit signalling > > > > The idea is to use the first byte after the UDP header to > > switch on whether the following header is IP (v4 or v6) or a > > TLV header. Effectively, the first byte is the version field > > of the IP header. versions 4 or 6 have the obvious meaning, > > for the TLV header we can use one of the version numbers > > that are not used today like 0 or 1. So for instance, 0 > > means TLV, 4 means IPv4, and 6 means IPv6. > > Jari mentioned that this is used by other protocols like > > MPLS and it is considered a hack by some people on the IESG > > but in our case we use a specific port number for DSMIP > > therefore no one who does not implement the DSMIP spec > > should receive this. > > > > So, when using this alternative, the TLV would look > > something like this: > > > > Format (1byte) Type (1byte) Length (2 bytes) > > > > Format is just a bad name I use in this email to indicate > > that this byte is used to identify the format of the > > following information (IP header or TLV) > > > > Type is the message type > > length is the message length > > > > 2. Explicit signalling > > > > In this mechanism we define a new flag in the BU that, when > > set, indicates that the MN/MR wants to use the following format: > > IP > > UDP > > TLV > > ...etc > > when the flag is cleared, it indicates the the MN/MR wants > > to use the following format: > > IP > > UDP > > ...etc (i.e. no TLV). > > > > Obviously when using this mechanism there must be a default > > mechanism for sending the BU itself. I.e., we can always > > send the BU in the current UDP encapsulation format witohut > > the TLV but if the request is accepted then data packets are > > sent as agreed during the BU/BA exchange. > > > > In either solution we will have to mandate that both the HA > > and the MN support the negotiation mechanism and one default > > format. So, all implementations have to support the current > > format of UDP encapsulation as a base. This allows for > > interoperability. > > > > In this alternative there is no need for the Format field in > > alternative 1, we only need to define Type and Length fields > > with one byte reserved. > > > > > > 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 Jul 05 12:05: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 1I6Tpt-0006bG-DB; Thu, 05 Jul 2007 12:05:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Tpr-0006ZN-Pw for mip6@ietf.org; Thu, 05 Jul 2007 12:05:39 -0400 Received: from web84112.mail.mud.yahoo.com ([68.142.206.199]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I6Top-0002Fc-83 for mip6@ietf.org; Thu, 05 Jul 2007 12:05:39 -0400 Received: (qmail 35660 invoked by uid 60001); 5 Jul 2007 15:57:53 -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=4WYW9ixiqYZWiGRd1820Dul/1R673AUBp+AA5Q+wOcxbm92nzAik4Hw59pbDd5iUpZUh2qNV8rrfhDoRDGcwtn1ahUh8/vBWfBiUbASMl0ONkJryOCvVXbVgc5W7A1+Rjg2Wshbidsv0M4x6RJ56mQZsNWlI4QWgaysUrjy7mUA=; X-YMail-OSG: civ8jfIVM1mn_9QinCc7D7KGnGIKlc9VIufKEtfif1JFxJiIMPVAT3BI3MgV5fJRecThNQl5UGmzIlZl4c.xV1EcL2EmKvRNDgRWY267aLPWNAypElU- Received: from [206.16.17.212] by web84112.mail.mud.yahoo.com via HTTP; Thu, 05 Jul 2007 08:57:52 PDT X-Mailer: YahooMailRC/651.38 YahooMailWebService/0.7.41.16 Date: Thu, 5 Jul 2007 08:57:52 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [Mip6] RE: Issue 93 - way forward To: Vijay Devarapalli , Hesham Soliman MIME-Version: 1.0 Message-ID: <990752.34361.qm@web84112.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0897154012==" Errors-To: mip6-bounces@ietf.org --===============0897154012== Content-Type: multipart/alternative; boundary="0-5776690-1183651072=:34361" --0-5776690-1183651072=:34361 Content-Type: text/plain; charset=ascii +1. Regards, Behcet ----- Original Message ---- From: Vijay Devarapalli To: Hesham Soliman Cc: nemo@ietf.org; mip6@ietf.org Sent: Thursday, July 5, 2007 10:26:44 AM Subject: Re: [Mip6] RE: Issue 93 - way forward I prefer alternative 2. Vijay Hesham Soliman wrote: > Folks, > > With the deadline fast approaching, I'd like to remind everyone to express a > choice, or a "don't care" about this issue. Given the contrast between the > amount of emails on this issue before Vs now, I'm inclined to assume that a > lot of people who participated before don't care which alternative we go > for. > > So just to be clear, the options are: > Alternative 1 > Alternative 2 > Don't care > > So far we had one opinion for alt 1 and another for alt 2. > > Personally, I prefer 2 because it's clearer and doesn't allow for a seamless > switch between the two packet formats on a per-packet basis. I think that > makes things more predictable for tunnel setup at the HA. I'm also less > comfortable with the generic ICMP error response from the HA when the MN > sends a packet in a format that is not supported by the HA. I think using > the BU to signal which format should be used is cleaner. > > My 2 cents. > > Hesham > > PS: If we get a lot of "don't care" then I'll ask the chairs/AD to make the > decisions for us. > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Sunday, July 01, 2007 2:27 PM > > To: 'mip6@ietf.org'; 'nemo@ietf.org' > > Subject: Issue 93 - way forward > > > > Folks, > > > > Some of the people involved in the recent discussions on > > issue 93, the NETLMM chairs and the AD had a teleconference > > a few days ago to discuss how to address the lack of > > concensus on this issue. The aim of the meeting was to find > > a way of accomodating both sides with one solution that > > avoids the technical inefficiency/lack of flexibility > > concerns of both sides. > > > > The following is a summary of what we agreed on in the meeting. > > > > The agreement was to define a way of handling both cases > > (presence of TLV or not). To do that two different > > mechanisms were proposed, I'll list a summary of each one below. > > > > 1. Implicit signalling > > > > The idea is to use the first byte after the UDP header to > > switch on whether the following header is IP (v4 or v6) or a > > TLV header. Effectively, the first byte is the version field > > of the IP header. versions 4 or 6 have the obvious meaning, > > for the TLV header we can use one of the version numbers > > that are not used today like 0 or 1. So for instance, 0 > > means TLV, 4 means IPv4, and 6 means IPv6. > > Jari mentioned that this is used by other protocols like > > MPLS and it is considered a hack by some people on the IESG > > but in our case we use a specific port number for DSMIP > > therefore no one who does not implement the DSMIP spec > > should receive this. > > > > So, when using this alternative, the TLV would look > > something like this: > > > > Format (1byte) Type (1byte) Length (2 bytes) > > > > Format is just a bad name I use in this email to indicate > > that this byte is used to identify the format of the > > following information (IP header or TLV) > > > > Type is the message type > > length is the message length > > > > 2. Explicit signalling > > > > In this mechanism we define a new flag in the BU that, when > > set, indicates that the MN/MR wants to use the following format: > > IP > > UDP > > TLV > > ...etc > > when the flag is cleared, it indicates the the MN/MR wants > > to use the following format: > > IP > > UDP > > ...etc (i.e. no TLV). > > > > Obviously when using this mechanism there must be a default > > mechanism for sending the BU itself. I.e., we can always > > send the BU in the current UDP encapsulation format witohut > > the TLV but if the request is accepted then data packets are > > sent as agreed during the BU/BA exchange. > > > > In either solution we will have to mandate that both the HA > > and the MN support the negotiation mechanism and one default > > format. So, all implementations have to support the current > > format of UDP encapsulation as a base. This allows for > > interoperability. > > > > In this alternative there is no need for the Format field in > > alternative 1, we only need to define Type and Length fields > > with one byte reserved. > > > > > > 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 --0-5776690-1183651072=:34361 Content-Type: text/html; charset=ascii
+1.

Regards,

Behcet

----- Original Message ----
From: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
To: Hesham Soliman <Hesham@elevatemobile.com>
Cc: nemo@ietf.org; mip6@ietf.org
Sent: Thursday, July 5, 2007 10:26:44 AM
Subject: Re: [Mip6] RE: Issue 93 - way forward

I prefer alternative 2.

Vijay

Hesham Soliman wrote:
> Folks,
>
> With the deadline fast approaching, I'd like to remind everyone to express a
> choice, or a "don't care" about this issue. Given the contrast between the
> amount of emails on this issue before Vs now, I'm inclined to assume that a
> lot of people who participated before don't care which alternative we go
> for.
>
> So just to be clear, the options are:
> Alternative 1
> Alternative 2
> Don't care
>
> So far we had one opinion for alt 1 and another for alt 2.
>
> Personally, I prefer 2 because it's clearer and doesn't allow for a seamless
> switch between the two packet formats on a per-packet basis. I think that
> makes things more predictable for tunnel setup at the HA. I'm also less
> comfortable with the generic ICMP error response from the HA when the MN
> sends a packet in a format that is not supported by the HA. I think using
> the BU to signal which format should be used is cleaner.
>
> My 2 cents.
>
> Hesham
>
> PS: If we get a lot of "don't care" then I'll ask the chairs/AD to make the
> decisions for us.
>
>  > -----Original Message-----
>  > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]
>  > Sent: Sunday, July 01, 2007 2:27 PM
>  > To: 'mip6@ietf.org'; 'nemo@ietf.org'
>  > Subject: Issue 93 - way forward
>  >
>  > Folks,
>  >
>  > Some of the people involved in the recent discussions on
>  > issue 93, the NETLMM chairs and the AD had a teleconference
>  > a few days ago to discuss how to address the lack of
>  > concensus on this issue. The aim of the meeting was to find
>  > a way of accomodating both sides with one solution that
>  > avoids the technical inefficiency/lack of flexibility
>  > concerns of both sides.
>  >
>  > The following is a summary of what we agreed on in the meeting.
>  >
>  > The agreement was to define a way of handling both cases
>  > (presence of TLV or not). To do that two different
>  > mechanisms were proposed, I'll list a summary of each one below.
>  >
>  > 1. Implicit signalling
>  >
>  > The idea is to use the first byte after the UDP header to
>  > switch on whether the following header is IP (v4 or v6) or a
>  > TLV header. Effectively, the first byte is the version field
>  > of the IP header. versions 4 or 6 have the obvious meaning,
>  > for the TLV header we can use one of the version numbers
>  > that are not used today like 0 or 1. So for instance, 0
>  > means TLV, 4 means IPv4, and 6 means IPv6.
>  > Jari mentioned that this is used by other protocols like
>  > MPLS and it is considered a hack by some people on the IESG
>  > but in our case we use a specific port number for DSMIP
>  > therefore no one who does not implement the DSMIP spec
>  > should receive this.
>  >
>  > So, when using this alternative, the TLV would look
>  > something like this:
>  >
>  > Format (1byte) Type (1byte)  Length (2 bytes)
>  >
>  > Format is just a bad name I use in this email to indicate
>  > that this byte is used to identify the format of the
>  > following information (IP header or TLV)
>  >
>  > Type is the message type
>  > length is the message length
>  >
>  > 2. Explicit signalling
>  >
>  > In this mechanism we define a new flag in the BU that, when
>  > set, indicates that the MN/MR wants to use the following format:
>  >   IP
>  >   UDP
>  >   TLV
>  >    ...etc
>  > when the flag is cleared, it indicates the the MN/MR wants
>  > to use the following format:
>  >   IP
>  >   UDP
>  >   ...etc (i.e. no TLV).
>  >
>  > Obviously when using this mechanism there must be a default
>  > mechanism for sending the BU itself. I.e., we can always
>  > send the BU in the current UDP encapsulation format witohut
>  > the TLV but if the request is accepted then data packets are
>  > sent as agreed during the BU/BA exchange.
>  >
>  > In either solution we will have to mandate that both the HA
>  > and the MN support the negotiation mechanism and one default
>  > format. So, all implementations have to support the current
>  > format of UDP encapsulation as a base. This allows for
>  > interoperability.
>  >
>  > In this alternative there is no need for the Format field in
>  > alternative 1, we only need to define Type and Length fields
>  > with one byte reserved.
>  >
>  >
>  > 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

--0-5776690-1183651072=:34361-- --===============0897154012== 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 --===============0897154012==-- From mip6-bounces@ietf.org Thu Jul 05 12:05: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 1I6Tq6-00071G-MX; Thu, 05 Jul 2007 12:05:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Tq4-0006xi-Hi; Thu, 05 Jul 2007 12:05:52 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Tp1-0002JG-Fk; Thu, 05 Jul 2007 12:05:52 -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 l65G4ij14516; Thu, 5 Jul 2007 16:04:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jul 2007 11:04:43 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437115614B2D@zrc2hxm2.corp.nortel.com> In-Reply-To: <20070705124643.FKGN24129.oaamta03sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: Issue 93 - way forward thread-index: Ace7mBtfZ3/6qerdQv62CoSb8S1s9wDaYH+wAAbrlRA= References: <20070705124643.FKGN24129.oaamta03sl.mx.bigpond.com@PC20005> From: "Ahmad Muhanna" To: "Hesham Soliman" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: Subject: [Mip6] RE: [nemo] RE: Issue 93 - way forward X-BeenThere: mip6@ietf.org X-Mailman-Version: 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 option 1 is contained and the proposed processing is very specific to the case at hand, I support option 1. That way we preserve one bit in the BU. Regards, Ahmad =20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Thursday, July 05, 2007 7:47 AM > To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > Subject: [nemo] RE: Issue 93 - way forward >=20 > Folks,=20 >=20 > With the deadline fast approaching, I'd like to remind=20 > everyone to express a choice, or a "don't care" about this=20 > issue. Given the contrast between the amount of emails on=20 > this issue before Vs now, I'm inclined to assume that a lot=20 > of people who participated before don't care which=20 > alternative we go for.=20 >=20 > So just to be clear, the options are: > Alternative 1 > Alternative 2 > Don't care >=20 > So far we had one opinion for alt 1 and another for alt 2.=20 >=20 > Personally, I prefer 2 because it's clearer and doesn't allow=20 > for a seamless switch between the two packet formats on a=20 > per-packet basis. I think that makes things more predictable=20 > for tunnel setup at the HA. I'm also less comfortable with=20 > the generic ICMP error response from the HA when the MN sends=20 > a packet in a format that is not supported by the HA. I think=20 > using the BU to signal which format should be used is cleaner.=20 >=20 > My 2 cents. >=20 > Hesham >=20 > PS: If we get a lot of "don't care" then I'll ask the=20 > chairs/AD to make the decisions for us. =20 >=20 > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >=20 > Sent: Sunday, July 01, 2007 2:27 PM > To: 'mip6@ietf.org';=20 > 'nemo@ietf.org' > > Subject: Issue 93 - way forward > > > > Folks, > > > > Some of the people involved in the recent discussions on =20 > > issue 93, the NETLMM chairs and the AD had a teleconference=20 > > a few days ago to discuss how to address the lack of >=20 > concensus on this issue. The aim of the meeting was to find =20 > > a way of accomodating both sides with one solution that >=20 > avoids the technical inefficiency/lack of flexibility >=20 > concerns of both sides. > > > > The following is a summary of what we agreed on in the meeting.=20 > > > > The agreement was to define a way of handling both cases =20 > > (presence of TLV or not). To do that two different >=20 > mechanisms were proposed, I'll list a summary of each one below.=20 > > > > 1. Implicit signalling > > > > The idea is to use the first byte after the UDP header to =20 > > switch on whether the following header is IP (v4 or v6) or=20 > a > TLV header. Effectively, the first byte is the version=20 > field > of the IP header. versions 4 or 6 have the obvious=20 > meaning, > for the TLV header we can use one of the version=20 > numbers > that are not used today like 0 or 1. So for=20 > instance, 0 > means TLV, 4 means IPv4, and 6 means IPv6.=20 > > Jari mentioned that this is used by other protocols like =20 > > MPLS and it is considered a hack by some people on the IESG=20 > > but in our case we use a specific port number for DSMIP >=20 > therefore no one who does not implement the DSMIP spec >=20 > should receive this.=20 > > > > So, when using this alternative, the TLV would look >=20 > something like this: > > > > Format (1byte) Type (1byte) Length (2 bytes) > > Format=20 > is just a bad name I use in this email to indicate > that=20 > this byte is used to identify the format of the > following=20 > information (IP header or TLV) > > Type is the message type=20 > > length is the message length > > 2. Explicit signalling =20 > > > In this mechanism we define a new flag in the BU that,=20 > when > set, indicates that the MN/MR wants to use the=20 > following format: > > IP > > UDP > > TLV > > ...etc > > when the flag is cleared, it indicates the the MN/MR wants=20 > > to use the following format: > > IP > > UDP > > ...etc (i.e. no TLV).=20 > > > > Obviously when using this mechanism there must be a=20 > default > mechanism for sending the BU itself. I.e., we can=20 > always > send the BU in the current UDP encapsulation format=20 > witohut > the TLV but if the request is accepted then data=20 > packets are > sent as agreed during the BU/BA exchange.=20 > > > > In either solution we will have to mandate that both the=20 > HA > and the MN support the negotiation mechanism and one=20 > default > format. So, all implementations have to support=20 > the current > format of UDP encapsulation as a base. This=20 > allows for > interoperability.=20 > > > > In this alternative there is no need for the Format field=20 > in > alternative 1, we only need to define Type and Length=20 > fields > with one byte reserved. > > > > > > Hesham > >=20 >=20 >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 05 12:10: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 1I6Tuj-0001qh-C3; Thu, 05 Jul 2007 12:10:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Tuh-0001bK-Qg for mip6@ietf.org; Thu, 05 Jul 2007 12:10:39 -0400 Received: from web84111.mail.mud.yahoo.com ([68.142.206.198]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I6Ttn-0003Ty-Au for mip6@ietf.org; Thu, 05 Jul 2007 12:10:39 -0400 Received: (qmail 83895 invoked by uid 60001); 5 Jul 2007 16:09:42 -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:MIME-Version:Content-Type:Message-ID; b=14NFJhzifJrXLfHMrNmn5hoPZYgvTIBe+FEZSUaOAZ408dORLuJwqXqu5ZIsN90Q/TQpQ69dhxWl/jJOYWbX0cKM/sqMUSC6s9xwWcVZfIUYCPq/aneywdDQIYfGgoGu6vej0jk9IsmK1eL3P2cXbiKVuizvXGO4o9dEBxSqy3w=; X-YMail-OSG: r2rmJKcVM1m0W4yx0_RmjpU8y3ZmeDZ6VaZaY5.JhYXCwZpOQRNmfNf6BWyCstUUYskvXJS0tjYe.i7DxgQCQhmaxcZJRr0wKk3q_IEQOXQ1LF1VRSs- Received: from [206.16.17.212] by web84111.mail.mud.yahoo.com via HTTP; Thu, 05 Jul 2007 09:09:42 PDT X-Mailer: YahooMailRC/651.38 YahooMailWebService/0.7.41.16 Date: Thu, 5 Jul 2007 09:09:42 -0700 (PDT) From: Behcet Sarikaya To: mip6@ietf.org MIME-Version: 1.0 Message-ID: <718827.83892.qm@web84111.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Mip6] Firewall Traversal X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1145151282==" Errors-To: mip6-bounces@ietf.org --===============1145151282== Content-Type: multipart/alternative; boundary="0-1799032536-1183651782=:83892" --0-1799032536-1183651782=:83892 Content-Type: text/plain; charset=ascii Hi all, We submitted a draft on Policy-based Firewall Traversal for Mobile IPv6it is available at: http://tools.ietf.org/wg/mip6/draft-xia-mip6-fw-policy-00.txt Please send your comments to the list. Regards, Behcet --0-1799032536-1183651782=:83892 Content-Type: text/html; charset=ascii
Hi all,
  We submitted a draft on 
Policy-based Firewall Traversal for Mobile IPv6
it is available at: http://tools.ietf.org/wg/mip6/draft-xia-mip6-fw-policy-00.txt

Please send your comments to the list.

Regards,

Behcet
--0-1799032536-1183651782=:83892-- --===============1145151282== 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 --===============1145151282==-- From mext-bounces@ietf.org Thu Jul 05 13:15: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 1I6Uuy-0005tK-WF; Thu, 05 Jul 2007 13:15:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6TGg-0004nh-Hf; Thu, 05 Jul 2007 11:29:18 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6TGg-0006HG-B2; Thu, 05 Jul 2007 11:29:18 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 41B774A3E; Thu, 5 Jul 2007 11:28:45 -0400 (EDT) From: Sam Hartman To: iesg@ietf.org References: Date: Thu, 05 Jul 2007 11:28:45 -0400 In-Reply-To: (IESG Secretary's message of "Tue, 26 Jun 2007 16:00:01 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Thu, 05 Jul 2007 13:14:59 -0400 Cc: mext@ietf.org Subject: [MEXT] Re: WG Review: Mobility EXTensions for IPv6 (mext) 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. Sorry for how late these comments are. It has come up in another discussion that there is ambiguity about to what extent it is appropriate for mext to be changing the IPsec protocols as a user of those protocols. I have no problem with mext defining new payloads to use IKE to configure some mobile IPV6 paramaters. I'm concerned though about basically any changes beyond that. I think this should be clarified in the charter. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 05 13:15: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 1I6UvF-00061E-IU; Thu, 05 Jul 2007 13:15:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6UvE-0005yw-33; Thu, 05 Jul 2007 13:15:16 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6UvD-0001sy-QY; Thu, 05 Jul 2007 13:15:16 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 200A1198666; Thu, 5 Jul 2007 20:14:42 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0EBA8198646; Thu, 5 Jul 2007 20:14:40 +0300 (EEST) Message-ID: <468D26FC.3000307@piuha.net> Date: Thu, 05 Jul 2007 19:14:36 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Sam Hartman 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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: iesg@ietf.org, mext@ietf.org Subject: [MEXT] Re: WG Review: Mobility EXTensions for IPv6 (mext) 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 Yes, I agree that this should be clarified. Sam, let me work on text with you and then we can post the suggestion to the list. Jari Sam Hartman kirjoitti: > Hi. > Sorry for how late these comments are. > > It has come up in another discussion that there is ambiguity about to > what extent it is appropriate for mext to be changing the IPsec > protocols as a user of those protocols. > > I have no problem with mext defining new payloads to use IKE to > configure some mobile IPV6 paramaters. I'm concerned though about > basically any changes beyond that. > > > I think this should be clarified in the charter. > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mip6-bounces@ietf.org Thu Jul 05 14:33: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 1I6W8b-0001Lu-28; Thu, 05 Jul 2007 14:33:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6W8a-0001Le-85; Thu, 05 Jul 2007 14:33:08 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6W8Z-0003Tf-Me; Thu, 05 Jul 2007 14:33:08 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 05 Jul 2007 11:32:56 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAP7VjEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,504,1175497200"; d="scan'208"; a="500392427:sNHT514523768" 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 l65IWuTn028822; Thu, 5 Jul 2007 11:32:56 -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 l65IWkke026336; Thu, 5 Jul 2007 18:32:52 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); Thu, 5 Jul 2007 11:32:47 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 11:32:46 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , , References: <20070705124643.FKGN24129.oaamta03sl.mx.bigpond.com@PC20005> Subject: RE: [Mip6] RE: Issue 93 - way forward Date: Thu, 5 Jul 2007 11:32:46 -0700 Message-ID: <005b01c7bf32$e22209a0$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.3138 In-Reply-To: <20070705124643.FKGN24129.oaamta03sl.mx.bigpond.com@PC20005> Thread-Index: Ace7mBtfZ3/6qerdQv62CoSb8S1s9wDaYH+wAAnlOuA= X-OriginalArrivalTime: 05 Jul 2007 18:32:47.0150 (UTC) FILETIME=[E26E54E0:01C7BF32] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4994; t=1183660376; x=1184524376; 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]=20RE=3A=20Issue=2093=20-=20way=20forward |Sender:=20; bh=gdTFRIvzcZOiROTzAo3vZzU63r/PvJxglNU6k6JULGw=; b=tesERn+J34B51FlHS/8ecXiJApAK0FiI8IqPk3HpjWiUAnYyzPL6lZ72V3sFpI/NMKeQqCeM Gz0a9J2Qssj+g7NCTGE5TpIO/82QZ+zwXhs9R0Wf7su7kuZMLDmBSdhX; 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: 87a3f533bb300b99e2a18357f3c1563d Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hesham, Sorry for the late reply on this. Can you confirm, for option#2, the flag will be present in the Binding Acknowledgment ? Thanks Sri > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Thursday, July 05, 2007 5:47 AM > To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > Subject: [Mip6] RE: Issue 93 - way forward > > Folks, > > With the deadline fast approaching, I'd like to remind > everyone to express a > choice, or a "don't care" about this issue. Given the > contrast between the > amount of emails on this issue before Vs now, I'm inclined to > assume that a > lot of people who participated before don't care which > alternative we go > for. > > So just to be clear, the options are: > Alternative 1 > Alternative 2 > Don't care > > So far we had one opinion for alt 1 and another for alt 2. > > Personally, I prefer 2 because it's clearer and doesn't allow > for a seamless > switch between the two packet formats on a per-packet basis. > I think that > makes things more predictable for tunnel setup at the HA. I'm > also less > comfortable with the generic ICMP error response from the HA > when the MN > sends a packet in a format that is not supported by the HA. I > think using > the BU to signal which format should be used is cleaner. > > My 2 cents. > > Hesham > > PS: If we get a lot of "don't care" then I'll ask the > chairs/AD to make the > decisions for us. > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Sunday, July 01, 2007 2:27 PM > > To: 'mip6@ietf.org'; 'nemo@ietf.org' > > Subject: Issue 93 - way forward > > > > Folks, > > > > Some of the people involved in the recent discussions on > > issue 93, the NETLMM chairs and the AD had a teleconference > > a few days ago to discuss how to address the lack of > > concensus on this issue. The aim of the meeting was to find > > a way of accomodating both sides with one solution that > > avoids the technical inefficiency/lack of flexibility > > concerns of both sides. > > > > The following is a summary of what we agreed on in the meeting. > > > > The agreement was to define a way of handling both cases > > (presence of TLV or not). To do that two different > > mechanisms were proposed, I'll list a summary of each one below. > > > > 1. Implicit signalling > > > > The idea is to use the first byte after the UDP header to > > switch on whether the following header is IP (v4 or v6) or a > > TLV header. Effectively, the first byte is the version field > > of the IP header. versions 4 or 6 have the obvious meaning, > > for the TLV header we can use one of the version numbers > > that are not used today like 0 or 1. So for instance, 0 > > means TLV, 4 means IPv4, and 6 means IPv6. > > Jari mentioned that this is used by other protocols like > > MPLS and it is considered a hack by some people on the IESG > > but in our case we use a specific port number for DSMIP > > therefore no one who does not implement the DSMIP spec > > should receive this. > > > > So, when using this alternative, the TLV would look > > something like this: > > > > Format (1byte) Type (1byte) Length (2 bytes) > > > > Format is just a bad name I use in this email to indicate > > that this byte is used to identify the format of the > > following information (IP header or TLV) > > > > Type is the message type > > length is the message length > > > > 2. Explicit signalling > > > > In this mechanism we define a new flag in the BU that, when > > set, indicates that the MN/MR wants to use the following format: > > IP > > UDP > > TLV > > ...etc > > when the flag is cleared, it indicates the the MN/MR wants > > to use the following format: > > IP > > UDP > > ...etc (i.e. no TLV). > > > > Obviously when using this mechanism there must be a default > > mechanism for sending the BU itself. I.e., we can always > > send the BU in the current UDP encapsulation format witohut > > the TLV but if the request is accepted then data packets are > > sent as agreed during the BU/BA exchange. > > > > In either solution we will have to mandate that both the HA > > and the MN support the negotiation mechanism and one default > > format. So, all implementations have to support the current > > format of UDP encapsulation as a base. This allows for > > interoperability. > > > > In this alternative there is no need for the Format field in > > alternative 1, we only need to define Type and Length fields > > with one byte reserved. > > > > > > 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 Jul 05 17:48: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 1I6ZBX-00008n-I0; Thu, 05 Jul 2007 17:48:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ZBW-00008b-0Z; Thu, 05 Jul 2007 17:48:22 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6ZBR-0001Qr-F9; Thu, 05 Jul 2007 17:48:21 -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, 5 Jul 2007 14:48:15 -0700 Message-ID: <468D6720.2060107@azairenet.com> Date: Thu, 05 Jul 2007 14:48:16 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [Mip6] RE: Issue 93 - way forward References: <20070705124643.FKGN24129.oaamta03sl.mx.bigpond.com@PC20005> <005b01c7bf32$e22209a0$d5f6200a@amer.cisco.com> In-Reply-To: <005b01c7bf32$e22209a0$d5f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2007 21:48:15.0890 (UTC) FILETIME=[314E0720:01C7BF4E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Sri Gundavelli wrote: > Hesham, > > Sorry for the late reply on this. > > Can you confirm, for option#2, the flag will be present in > the Binding Acknowledgment ? The flag would need to be echoed back in the binding acknowledgment. Vijay > > Thanks > Sri > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Thursday, July 05, 2007 5:47 AM > > To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > > Subject: [Mip6] RE: Issue 93 - way forward > > > > Folks, > > > > With the deadline fast approaching, I'd like to remind > > everyone to express a > > choice, or a "don't care" about this issue. Given the > > contrast between the > > amount of emails on this issue before Vs now, I'm inclined to > > assume that a > > lot of people who participated before don't care which > > alternative we go > > for. > > > > So just to be clear, the options are: > > Alternative 1 > > Alternative 2 > > Don't care > > > > So far we had one opinion for alt 1 and another for alt 2. > > > > Personally, I prefer 2 because it's clearer and doesn't allow > > for a seamless > > switch between the two packet formats on a per-packet basis. > > I think that > > makes things more predictable for tunnel setup at the HA. I'm > > also less > > comfortable with the generic ICMP error response from the HA > > when the MN > > sends a packet in a format that is not supported by the HA. I > > think using > > the BU to signal which format should be used is cleaner. > > > > My 2 cents. > > > > Hesham > > > > PS: If we get a lot of "don't care" then I'll ask the > > chairs/AD to make the > > decisions for us. > > > > > -----Original Message----- > > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > > Sent: Sunday, July 01, 2007 2:27 PM > > > To: 'mip6@ietf.org'; 'nemo@ietf.org' > > > Subject: Issue 93 - way forward > > > > > > Folks, > > > > > > Some of the people involved in the recent discussions on > > > issue 93, the NETLMM chairs and the AD had a teleconference > > > a few days ago to discuss how to address the lack of > > > concensus on this issue. The aim of the meeting was to find > > > a way of accomodating both sides with one solution that > > > avoids the technical inefficiency/lack of flexibility > > > concerns of both sides. > > > > > > The following is a summary of what we agreed on in the meeting. > > > > > > The agreement was to define a way of handling both cases > > > (presence of TLV or not). To do that two different > > > mechanisms were proposed, I'll list a summary of each one below. > > > > > > 1. Implicit signalling > > > > > > The idea is to use the first byte after the UDP header to > > > switch on whether the following header is IP (v4 or v6) or a > > > TLV header. Effectively, the first byte is the version field > > > of the IP header. versions 4 or 6 have the obvious meaning, > > > for the TLV header we can use one of the version numbers > > > that are not used today like 0 or 1. So for instance, 0 > > > means TLV, 4 means IPv4, and 6 means IPv6. > > > Jari mentioned that this is used by other protocols like > > > MPLS and it is considered a hack by some people on the IESG > > > but in our case we use a specific port number for DSMIP > > > therefore no one who does not implement the DSMIP spec > > > should receive this. > > > > > > So, when using this alternative, the TLV would look > > > something like this: > > > > > > Format (1byte) Type (1byte) Length (2 bytes) > > > > > > Format is just a bad name I use in this email to indicate > > > that this byte is used to identify the format of the > > > following information (IP header or TLV) > > > > > > Type is the message type > > > length is the message length > > > > > > 2. Explicit signalling > > > > > > In this mechanism we define a new flag in the BU that, when > > > set, indicates that the MN/MR wants to use the following format: > > > IP > > > UDP > > > TLV > > > ...etc > > > when the flag is cleared, it indicates the the MN/MR wants > > > to use the following format: > > > IP > > > UDP > > > ...etc (i.e. no TLV). > > > > > > Obviously when using this mechanism there must be a default > > > mechanism for sending the BU itself. I.e., we can always > > > send the BU in the current UDP encapsulation format witohut > > > the TLV but if the request is accepted then data packets are > > > sent as agreed during the BU/BA exchange. > > > > > > In either solution we will have to mandate that both the HA > > > and the MN support the negotiation mechanism and one default > > > format. So, all implementations have to support the current > > > format of UDP encapsulation as a base. This allows for > > > interoperability. > > > > > > In this alternative there is no need for the Format field in > > > alternative 1, we only need to define Type and Length fields > > > with one byte reserved. > > > > > > > > > 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 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 05 23:00: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 1I6e3A-0004jD-OO; Thu, 05 Jul 2007 23:00:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6e39-0004eL-B2; Thu, 05 Jul 2007 23:00:03 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6e38-0001Eb-IZ; Thu, 05 Jul 2007 23:00:03 -0400 Received: from oaamta04sl.mx.bigpond.com ([124.190.105.118]) by omta04sl.mx.bigpond.com with ESMTP id <20070706025902.KFGW4018.omta04sl.mx.bigpond.com@oaamta04sl.mx.bigpond.com>; Fri, 6 Jul 2007 02:59:02 +0000 Received: from PC20005 ([124.190.105.118]) by oaamta04sl.mx.bigpond.com with ESMTP id <20070706025901.GPWU22522.oaamta04sl.mx.bigpond.com@PC20005>; Fri, 6 Jul 2007 02:59:01 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , , Subject: RE: [Mip6] RE: Issue 93 - way forward Date: Fri, 6 Jul 2007 12:58: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 In-Reply-To: <005b01c7bf32$e22209a0$d5f6200a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace7mBtfZ3/6qerdQv62CoSb8S1s9wDaYH+wAAnlOuAAFBauUA== Message-Id: <20070706025901.GPWU22522.oaamta04sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de 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 Yes it has to be present in the BA. Hesham > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Friday, July 06, 2007 4:33 AM > To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] RE: Issue 93 - way forward > > Hesham, > > Sorry for the late reply on this. > > Can you confirm, for option#2, the flag will be present in > the Binding Acknowledgment ? > > Thanks > Sri > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Thursday, July 05, 2007 5:47 AM > > To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > > Subject: [Mip6] RE: Issue 93 - way forward > > > > Folks, > > > > With the deadline fast approaching, I'd like to remind > > everyone to express a > > choice, or a "don't care" about this issue. Given the > > contrast between the > > amount of emails on this issue before Vs now, I'm inclined to > > assume that a > > lot of people who participated before don't care which > > alternative we go > > for. > > > > So just to be clear, the options are: > > Alternative 1 > > Alternative 2 > > Don't care > > > > So far we had one opinion for alt 1 and another for alt 2. > > > > Personally, I prefer 2 because it's clearer and doesn't allow > > for a seamless > > switch between the two packet formats on a per-packet basis. > > I think that > > makes things more predictable for tunnel setup at the HA. I'm > > also less > > comfortable with the generic ICMP error response from the HA > > when the MN > > sends a packet in a format that is not supported by the HA. I > > think using > > the BU to signal which format should be used is cleaner. > > > > My 2 cents. > > > > Hesham > > > > PS: If we get a lot of "don't care" then I'll ask the > > chairs/AD to make the > > decisions for us. > > > > > -----Original Message----- > > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > > Sent: Sunday, July 01, 2007 2:27 PM > > > To: 'mip6@ietf.org'; 'nemo@ietf.org' > > > Subject: Issue 93 - way forward > > > > > > Folks, > > > > > > Some of the people involved in the recent discussions on > > > issue 93, the NETLMM chairs and the AD had a teleconference > > > a few days ago to discuss how to address the lack of > > > concensus on this issue. The aim of the meeting was to find > > > a way of accomodating both sides with one solution that > > > avoids the technical inefficiency/lack of flexibility > > > concerns of both sides. > > > > > > The following is a summary of what we agreed on in the meeting. > > > > > > The agreement was to define a way of handling both cases > > > (presence of TLV or not). To do that two different > > > mechanisms were proposed, I'll list a summary of each > one below. > > > > > > 1. Implicit signalling > > > > > > The idea is to use the first byte after the UDP header to > > > switch on whether the following header is IP (v4 or v6) or a > > > TLV header. Effectively, the first byte is the version field > > > of the IP header. versions 4 or 6 have the obvious meaning, > > > for the TLV header we can use one of the version numbers > > > that are not used today like 0 or 1. So for instance, 0 > > > means TLV, 4 means IPv4, and 6 means IPv6. > > > Jari mentioned that this is used by other protocols like > > > MPLS and it is considered a hack by some people on the IESG > > > but in our case we use a specific port number for DSMIP > > > therefore no one who does not implement the DSMIP spec > > > should receive this. > > > > > > So, when using this alternative, the TLV would look > > > something like this: > > > > > > Format (1byte) Type (1byte) Length (2 bytes) > > > > > > Format is just a bad name I use in this email to indicate > > > that this byte is used to identify the format of the > > > following information (IP header or TLV) > > > > > > Type is the message type > > > length is the message length > > > > > > 2. Explicit signalling > > > > > > In this mechanism we define a new flag in the BU that, when > > > set, indicates that the MN/MR wants to use the following format: > > > IP > > > UDP > > > TLV > > > ...etc > > > when the flag is cleared, it indicates the the MN/MR wants > > > to use the following format: > > > IP > > > UDP > > > ...etc (i.e. no TLV). > > > > > > Obviously when using this mechanism there must be a default > > > mechanism for sending the BU itself. I.e., we can always > > > send the BU in the current UDP encapsulation format witohut > > > the TLV but if the request is accepted then data packets are > > > sent as agreed during the BU/BA exchange. > > > > > > In either solution we will have to mandate that both the HA > > > and the MN support the negotiation mechanism and one default > > > format. So, all implementations have to support the current > > > format of UDP encapsulation as a base. This allows for > > > interoperability. > > > > > > In this alternative there is no need for the Format field in > > > alternative 1, we only need to define Type and Length fields > > > with one byte reserved. > > > > > > > > > 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 Fri Jul 06 01:20: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 1I6gEv-0004N3-Dj; Fri, 06 Jul 2007 01:20:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6gEM-00045U-3v; Fri, 06 Jul 2007 01:19:46 -0400 Received: from mail.sfc.wide.ad.jp ([2001:200:0:8803:203:47ff:fedf:73a6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6gEK-0006iA-Iw; Fri, 06 Jul 2007 01:19:45 -0400 Received: from [203.178.143.210] (dhcp-143-210.sfc.wide.ad.jp [203.178.143.210]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 22D5F4D88F; Fri, 6 Jul 2007 14:19:42 +0900 (JST) Message-ID: <468DD0FD.2040900@sfc.wide.ad.jp> Date: Fri, 06 Jul 2007 14:19:57 +0900 From: Jean Lorchat User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: mip6@ietf.org Subject: Re: [Mip6] RE: Issue 93 - way forward References: <20070705124643.FKGN24129.oaamta03sl.mx.bigpond.com@PC20005> In-Reply-To: <20070705124643.FKGN24129.oaamta03sl.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: nemo@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 Dear all, We are taking care of a Linux implementation of the DSMIP draft. From our point of view, alternative 1 seems better because it does not require a kind of new state on the HA for DSMIP operation. We did not think about issues related to changing the encapsulated protocol (v4/v6/TLV) on a per-packet basis though. Jean (Nautilus6 Project) Hesham Soliman wrote: > Folks, > > With the deadline fast approaching, I'd like to remind everyone to express a > choice, or a "don't care" about this issue. Given the contrast between the > amount of emails on this issue before Vs now, I'm inclined to assume that a > lot of people who participated before don't care which alternative we go > for. > > So just to be clear, the options are: > Alternative 1 > Alternative 2 > Don't care > > So far we had one opinion for alt 1 and another for alt 2. > > Personally, I prefer 2 because it's clearer and doesn't allow for a seamless > switch between the two packet formats on a per-packet basis. I think that > makes things more predictable for tunnel setup at the HA. I'm also less > comfortable with the generic ICMP error response from the HA when the MN > sends a packet in a format that is not supported by the HA. I think using > the BU to signal which format should be used is cleaner. > > My 2 cents. > > Hesham > > PS: If we get a lot of "don't care" then I'll ask the chairs/AD to make the > decisions for us. > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Sunday, July 01, 2007 2:27 PM > > To: 'mip6@ietf.org'; 'nemo@ietf.org' > > Subject: Issue 93 - way forward > > > > Folks, > > > > Some of the people involved in the recent discussions on > > issue 93, the NETLMM chairs and the AD had a teleconference > > a few days ago to discuss how to address the lack of > > concensus on this issue. The aim of the meeting was to find > > a way of accomodating both sides with one solution that > > avoids the technical inefficiency/lack of flexibility > > concerns of both sides. > > > > The following is a summary of what we agreed on in the meeting. > > > > The agreement was to define a way of handling both cases > > (presence of TLV or not). To do that two different > > mechanisms were proposed, I'll list a summary of each one below. > > > > 1. Implicit signalling > > > > The idea is to use the first byte after the UDP header to > > switch on whether the following header is IP (v4 or v6) or a > > TLV header. Effectively, the first byte is the version field > > of the IP header. versions 4 or 6 have the obvious meaning, > > for the TLV header we can use one of the version numbers > > that are not used today like 0 or 1. So for instance, 0 > > means TLV, 4 means IPv4, and 6 means IPv6. > > Jari mentioned that this is used by other protocols like > > MPLS and it is considered a hack by some people on the IESG > > but in our case we use a specific port number for DSMIP > > therefore no one who does not implement the DSMIP spec > > should receive this. > > > > So, when using this alternative, the TLV would look > > something like this: > > > > Format (1byte) Type (1byte) Length (2 bytes) > > > > Format is just a bad name I use in this email to indicate > > that this byte is used to identify the format of the > > following information (IP header or TLV) > > > > Type is the message type > > length is the message length > > > > 2. Explicit signalling > > > > In this mechanism we define a new flag in the BU that, when > > set, indicates that the MN/MR wants to use the following format: > > IP > > UDP > > TLV > > ...etc > > when the flag is cleared, it indicates the the MN/MR wants > > to use the following format: > > IP > > UDP > > ...etc (i.e. no TLV). > > > > Obviously when using this mechanism there must be a default > > mechanism for sending the BU itself. I.e., we can always > > send the BU in the current UDP encapsulation format witohut > > the TLV but if the request is accepted then data packets are > > sent as agreed during the BU/BA exchange. > > > > In either solution we will have to mandate that both the HA > > and the MN support the negotiation mechanism and one default > > format. So, all implementations have to support the current > > format of UDP encapsulation as a base. This allows for > > interoperability. > > > > In this alternative there is no need for the Format field in > > alternative 1, we only need to define Type and Length fields > > with one byte reserved. > > > > > > 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 Fri Jul 06 04:21: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 1I6j41-0000jD-0m; Fri, 06 Jul 2007 04:21:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6j3z-0000is-DS; Fri, 06 Jul 2007 04:21:15 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6j3y-0002Lx-P0; Fri, 06 Jul 2007 04:21:15 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Jul 2007 01:21:14 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJaXjUarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,507,1175497200"; d="scan'208"; a="177506436:sNHT33706665" 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 l668LDXr021747; Fri, 6 Jul 2007 01:21:13 -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 l668L5XH025903; Fri, 6 Jul 2007 08:21:09 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); Fri, 6 Jul 2007 01:21:05 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 01:21:04 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , , References: <005b01c7bf32$e22209a0$d5f6200a@amer.cisco.com> <20070706025901.GPWU22522.oaamta04sl.mx.bigpond.com@PC20005> Subject: RE: [Mip6] RE: Issue 93 - way forward Date: Fri, 6 Jul 2007 01:20:59 -0700 Message-ID: <00b101c7bfa6$95c94360$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.3138 In-Reply-To: <20070706025901.GPWU22522.oaamta04sl.mx.bigpond.com@PC20005> Thread-Index: Ace7mBtfZ3/6qerdQv62CoSb8S1s9wDaYH+wAAnlOuAAFBauUAAKntng X-OriginalArrivalTime: 06 Jul 2007 08:21:05.0032 (UTC) FILETIME=[98AD5080:01C7BFA6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6953; t=1183710073; x=1184574073; 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]=20RE=3A=20Issue=2093=20-=20way=20forward |Sender:=20; bh=CrIL/tS+j72Rgl9ESWqutNEb4tTekcR2w0MYAJgzJSQ=; b=uZ/lsbTwb27H1RqVgwBQaDY74cK4pzH7xGKMFJPz+uTB9J/LWmW9NaLzU+ycOWUvSWddOfod mdJ8o15YXnVawY6sXRdDQyyRYjalUycxMB5nah0HEl8VqZ/ObOdO0zpR; 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: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I agree Option#2 is cleaner and also disallowing encap mode switch over on a per packet basis might be a good idea. At the same time, I agree with Jean and Ahmad, it does not introduce additional states, keeps the implementation simple. We went over the flows as how the MN would ask for a specific enap mode, in the presence/absence of NAT, in all cases the explicit request appeared to be redundant, as the acceptance of a specific encap mode and the NAT detection, seem to implicitly dictate if TLV is required or not. Its a tough call, but I'll go for Option#2. Just to keep predictability in the operation and keep things explicit. Sri > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Thursday, July 05, 2007 7:59 PM > To: 'Sri Gundavelli'; mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] RE: Issue 93 - way forward > > Yes it has to be present in the BA. > > Hesham > > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Friday, July 06, 2007 4:33 AM > > To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > > Subject: RE: [Mip6] RE: Issue 93 - way forward > > > > Hesham, > > > > Sorry for the late reply on this. > > > > Can you confirm, for option#2, the flag will be present in > > the Binding Acknowledgment ? > > > > Thanks > > Sri > > > > > -----Original Message----- > > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > > Sent: Thursday, July 05, 2007 5:47 AM > > > To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > > > Subject: [Mip6] RE: Issue 93 - way forward > > > > > > Folks, > > > > > > With the deadline fast approaching, I'd like to remind > > > everyone to express a > > > choice, or a "don't care" about this issue. Given the > > > contrast between the > > > amount of emails on this issue before Vs now, I'm inclined to > > > assume that a > > > lot of people who participated before don't care which > > > alternative we go > > > for. > > > > > > So just to be clear, the options are: > > > Alternative 1 > > > Alternative 2 > > > Don't care > > > > > > So far we had one opinion for alt 1 and another for alt 2. > > > > > > Personally, I prefer 2 because it's clearer and doesn't allow > > > for a seamless > > > switch between the two packet formats on a per-packet basis. > > > I think that > > > makes things more predictable for tunnel setup at the HA. I'm > > > also less > > > comfortable with the generic ICMP error response from the HA > > > when the MN > > > sends a packet in a format that is not supported by the HA. I > > > think using > > > the BU to signal which format should be used is cleaner. > > > > > > My 2 cents. > > > > > > Hesham > > > > > > PS: If we get a lot of "don't care" then I'll ask the > > > chairs/AD to make the > > > decisions for us. > > > > > > > -----Original Message----- > > > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > > > Sent: Sunday, July 01, 2007 2:27 PM > > > > To: 'mip6@ietf.org'; 'nemo@ietf.org' > > > > Subject: Issue 93 - way forward > > > > > > > > Folks, > > > > > > > > Some of the people involved in the recent discussions on > > > > issue 93, the NETLMM chairs and the AD had a teleconference > > > > a few days ago to discuss how to address the lack of > > > > concensus on this issue. The aim of the meeting was to find > > > > a way of accomodating both sides with one solution that > > > > avoids the technical inefficiency/lack of flexibility > > > > concerns of both sides. > > > > > > > > The following is a summary of what we agreed on in > the meeting. > > > > > > > > The agreement was to define a way of handling both cases > > > > (presence of TLV or not). To do that two different > > > > mechanisms were proposed, I'll list a summary of each > > one below. > > > > > > > > 1. Implicit signalling > > > > > > > > The idea is to use the first byte after the UDP header to > > > > switch on whether the following header is IP (v4 or v6) or a > > > > TLV header. Effectively, the first byte is the version field > > > > of the IP header. versions 4 or 6 have the obvious meaning, > > > > for the TLV header we can use one of the version numbers > > > > that are not used today like 0 or 1. So for instance, 0 > > > > means TLV, 4 means IPv4, and 6 means IPv6. > > > > Jari mentioned that this is used by other protocols like > > > > MPLS and it is considered a hack by some people on the IESG > > > > but in our case we use a specific port number for DSMIP > > > > therefore no one who does not implement the DSMIP spec > > > > should receive this. > > > > > > > > So, when using this alternative, the TLV would look > > > > something like this: > > > > > > > > Format (1byte) Type (1byte) Length (2 bytes) > > > > > > > > Format is just a bad name I use in this email to indicate > > > > that this byte is used to identify the format of the > > > > following information (IP header or TLV) > > > > > > > > Type is the message type > > > > length is the message length > > > > > > > > 2. Explicit signalling > > > > > > > > In this mechanism we define a new flag in the BU that, when > > > > set, indicates that the MN/MR wants to use the > following format: > > > > IP > > > > UDP > > > > TLV > > > > ...etc > > > > when the flag is cleared, it indicates the the MN/MR wants > > > > to use the following format: > > > > IP > > > > UDP > > > > ...etc (i.e. no TLV). > > > > > > > > Obviously when using this mechanism there must be a default > > > > mechanism for sending the BU itself. I.e., we can always > > > > send the BU in the current UDP encapsulation format witohut > > > > the TLV but if the request is accepted then data packets are > > > > sent as agreed during the BU/BA exchange. > > > > > > > > In either solution we will have to mandate that both the HA > > > > and the MN support the negotiation mechanism and one default > > > > format. So, all implementations have to support the current > > > > format of UDP encapsulation as a base. This allows for > > > > interoperability. > > > > > > > > In this alternative there is no need for the Format field in > > > > alternative 1, we only need to define Type and Length fields > > > > with one byte reserved. > > > > > > > > > > > > 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 Fri Jul 06 04:57: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 1I6jcr-0007di-97; Fri, 06 Jul 2007 04:57:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6jcp-0007UK-J6 for mip6@ietf.org; Fri, 06 Jul 2007 04:57:15 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6jcp-0006vp-1K for mip6@ietf.org; Fri, 06 Jul 2007 04:57:15 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 06 Jul 2007 01:57:14 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CADKhjUarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,507,1175497200"; d="scan'208"; a="177518594:sNHT243762642" 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 l668vERX026929; Fri, 6 Jul 2007 01:57:14 -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 l668v9mo005144; Fri, 6 Jul 2007 08:57:13 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); Fri, 6 Jul 2007 01:57:09 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 01:57:08 -0700 From: "Sri Gundavelli" To: , References: <59D7431DE2527D4CB0F1EFEDA5683ED301F26A01@SEHAN021MB.tcad.telia.se> Subject: RE: [Mip6] FW: I-D ACTION:draft-korhonen-mip6-service-02.txt Date: Fri, 6 Jul 2007 01:57:03 -0700 Message-ID: <00bf01c7bfab$9f916fd0$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.3138 In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED301F26A01@SEHAN021MB.tcad.telia.se> Thread-Index: AcepPU56zCVYT+rkSVa9sbSDpeNePwAR/q4ABYkFbnA= X-OriginalArrivalTime: 06 Jul 2007 08:57:09.0124 (UTC) FILETIME=[A2938C40:01C7BFAB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5192; t=1183712234; x=1184576234; 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]=20FW=3A=20I-D=20ACTION=3Adraft-korhonen-mip6-s ervice-02.txt=20 |Sender:=20; bh=KQMIhLsyG3hNCQ8vGU5Cm1f17V5DB5wH5LPx9uuO8D8=; b=F0UEtOBIAGaqh0Hao8Ahh1JQgv2XM3iT1hLQ2l1jPJvE2xSZZxyY7I1PWsnN6/KqPjjySvul RnQAnGE1Tuy7AUbXCDoxfTXyK6uIIBp79+R3qHMPP6k00H3EiIa3ZN4Qj313+MvbT2cKVuSwUj m85OUY4lwms7z4/48OSrjtvmQ=; 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: 36b1f8810cb91289d885dc8ab4fc8172 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 Jouni, Some questions on your service selection draft. Please see inline. > Identifier: A variable length service identifier string used to > identify the requested service. The Identifier string is encoded > as a host name or a fully qualified domain name as defined in [4] > and [5]. Can you comment on the format of the service identification. Is the use FQDN format sufficient to represent any service and is that service definition universal ? Or, do you expect the specific HA/MN deployment to have a common understanding of that "service" definition. It would be nice, if the draft presents the potential services that the MN can ask. Some examples will be nice. > The Service Selection option is used to assist the authorization and > identifies a specific service that is to be authorized. The Service > Selection option MAY also affect the Home Address or Home Network > Prefix allocation when for example used with the MN-NAI option. For > the same NAI there MAY be different Home Addresses depending on the > identified service. Furthermore, the Service Selection option MAY > also affect the routing of the outbound IP packets in the home agent > depending on the selected service. Does the request/acceptance of a specific service, impact the current mobility session, in any ways ? Or is it, just a application traffic for the session. The above text hinted the use of this service negotiation for "QoS" traffic classification, can you comment on that and on the services that you have in mind. Thanks Sri > -----Original Message----- > From: jouni.korhonen@teliasonera.com > [mailto:jouni.korhonen@teliasonera.com] > Sent: Thursday, June 07, 2007 10:42 PM > To: mip6@ietf.org > 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 From mip6-bounces@ietf.org Sat Jul 07 07:29: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 1I78Ti-000127-6c; Sat, 07 Jul 2007 07:29:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I78Tg-00011v-Ha; Sat, 07 Jul 2007 07:29:28 -0400 Received: from omta03sl.mx.bigpond.com ([144.140.92.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I78Ta-00041J-U9; Sat, 07 Jul 2007 07:29:28 -0400 Received: from oaamta03sl.mx.bigpond.com ([124.190.105.118]) by omta03sl.mx.bigpond.com with ESMTP id <20070707112919.OYSZ12810.omta03sl.mx.bigpond.com@oaamta03sl.mx.bigpond.com>; Sat, 7 Jul 2007 11:29:19 +0000 Received: from PC20005 ([124.190.105.118]) by oaamta03sl.mx.bigpond.com with ESMTP id <20070707112919.UKJV24129.oaamta03sl.mx.bigpond.com@PC20005>; Sat, 7 Jul 2007 11:29:19 +0000 From: "Hesham Soliman" To: , Subject: RE: [Mip6] RE: Issue 93 - resolution Date: Sat, 7 Jul 2007 21:29: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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace7mBtfZ3/6qerdQv62CoSb8S1s9wDaYH+wAAnlOuAAFBauUABD7BKw Message-Id: <20070707112919.UKJV24129.oaamta03sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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 Ok, it looks like we're going with alternative 2. Thanks for all your input. I'll submit the draft this weekend with this issue's resolution included. I talked to Jari about what to do with his review of issue 73 and he suggested I submit the draft with all the other issues fixed. So whenever he comes back with a resolution for it I can update the draft and announce it on the list (i.e. even if I submit another version after the deadline). We don't have any other outstanding issues. Thanks, Hesham > > > Folks, > > > > > > With the deadline fast approaching, I'd like to remind > > > everyone to express a > > > choice, or a "don't care" about this issue. Given the > > > contrast between the > > > amount of emails on this issue before Vs now, I'm inclined to > > > assume that a > > > lot of people who participated before don't care which > > > alternative we go > > > for. > > > > > > So just to be clear, the options are: > > > Alternative 1 > > > Alternative 2 > > > Don't care > > > > > > So far we had one opinion for alt 1 and another for alt 2. > > > > > > Personally, I prefer 2 because it's clearer and doesn't allow > > > for a seamless > > > switch between the two packet formats on a per-packet basis. > > > I think that > > > makes things more predictable for tunnel setup at the HA. I'm > > > also less > > > comfortable with the generic ICMP error response from the HA > > > when the MN > > > sends a packet in a format that is not supported by the HA. I > > > think using > > > the BU to signal which format should be used is cleaner. > > > > > > My 2 cents. > > > > > > Hesham > > > > > > PS: If we get a lot of "don't care" then I'll ask the > > > chairs/AD to make the > > > decisions for us. > > > > > > > -----Original Message----- > > > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > > > Sent: Sunday, July 01, 2007 2:27 PM > > > > To: 'mip6@ietf.org'; 'nemo@ietf.org' > > > > Subject: Issue 93 - way forward > > > > > > > > Folks, > > > > > > > > Some of the people involved in the recent discussions on > > > > issue 93, the NETLMM chairs and the AD had a teleconference > > > > a few days ago to discuss how to address the lack of > > > > concensus on this issue. The aim of the meeting was to find > > > > a way of accomodating both sides with one solution that > > > > avoids the technical inefficiency/lack of flexibility > > > > concerns of both sides. > > > > > > > > The following is a summary of what we agreed on in > the meeting. > > > > > > > > The agreement was to define a way of handling both cases > > > > (presence of TLV or not). To do that two different > > > > mechanisms were proposed, I'll list a summary of each > > one below. > > > > > > > > 1. Implicit signalling > > > > > > > > The idea is to use the first byte after the UDP header to > > > > switch on whether the following header is IP (v4 or v6) or a > > > > TLV header. Effectively, the first byte is the version field > > > > of the IP header. versions 4 or 6 have the obvious meaning, > > > > for the TLV header we can use one of the version numbers > > > > that are not used today like 0 or 1. So for instance, 0 > > > > means TLV, 4 means IPv4, and 6 means IPv6. > > > > Jari mentioned that this is used by other protocols like > > > > MPLS and it is considered a hack by some people on the IESG > > > > but in our case we use a specific port number for DSMIP > > > > therefore no one who does not implement the DSMIP spec > > > > should receive this. > > > > > > > > So, when using this alternative, the TLV would look > > > > something like this: > > > > > > > > Format (1byte) Type (1byte) Length (2 bytes) > > > > > > > > Format is just a bad name I use in this email to indicate > > > > that this byte is used to identify the format of the > > > > following information (IP header or TLV) > > > > > > > > Type is the message type > > > > length is the message length > > > > > > > > 2. Explicit signalling > > > > > > > > In this mechanism we define a new flag in the BU that, when > > > > set, indicates that the MN/MR wants to use the > following format: > > > > IP > > > > UDP > > > > TLV > > > > ...etc > > > > when the flag is cleared, it indicates the the MN/MR wants > > > > to use the following format: > > > > IP > > > > UDP > > > > ...etc (i.e. no TLV). > > > > > > > > Obviously when using this mechanism there must be a default > > > > mechanism for sending the BU itself. I.e., we can always > > > > send the BU in the current UDP encapsulation format witohut > > > > the TLV but if the request is accepted then data packets are > > > > sent as agreed during the BU/BA exchange. > > > > > > > > In either solution we will have to mandate that both the HA > > > > and the MN support the negotiation mechanism and one default > > > > format. So, all implementations have to support the current > > > > format of UDP encapsulation as a base. This allows for > > > > interoperability. > > > > > > > > In this alternative there is no need for the Format field in > > > > alternative 1, we only need to define Type and Length fields > > > > with one byte reserved. > > > > > > > > > > > > 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 Sun Jul 08 01:34: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 1I7PPt-0006fh-TW; Sun, 08 Jul 2007 01:34:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7PPt-0006ev-3c for mip6@ietf.org; Sun, 08 Jul 2007 01:34:41 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7PPp-0006N1-QZ for mip6@ietf.org; Sun, 08 Jul 2007 01:34:41 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 68D6D19866B; Sun, 8 Jul 2007 08:34:36 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 13095198646; Sun, 8 Jul 2007 08:34:35 +0300 (EEST) Message-ID: <4690776C.90101@piuha.net> Date: Sun, 08 Jul 2007 08:34:36 +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 Subject: Re: [Mip6] bootstrapping-splitanycast/ikev2 ha selection feature 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> 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: de4f315c9369b71d7dd5909b42224370 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 Authors, I realize that this issue has been controversial, but I think the practical way forward is to submit a new version that takes the anycast functionality out, and once the -00 submissions open up again submit the taken out part as a new draft. I believe it is easy to address the other comments for bootstrapping-split, so I should be able to send the revised draft to RFC Editor right after it appears in the I-D directories. Thanks, Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jul 08 01:54: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 1I7PiZ-00006u-At; Sun, 08 Jul 2007 01:53:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7PiX-00006n-FI for mip6@ietf.org; Sun, 08 Jul 2007 01:53:57 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7PiT-0006vb-6D for mip6@ietf.org; Sun, 08 Jul 2007 01:53:57 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6DBED19866C; Sun, 8 Jul 2007 08:53:52 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 10B0D198646; Sun, 8 Jul 2007 08:53:52 +0300 (EEST) Message-ID: <46907BF0.4000903@piuha.net> Date: Sun, 08 Jul 2007 08:53:52 +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, 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: 08e48e05374109708c00c6208b534009 Cc: Subject: [Mip6] draft-ietf-mip6-bootstrapping-integrated-dhc 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 Authors, My recollection is that we agreed on what to do with the draft, after I posted my AD review. Please submit a new version. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jul 08 02:41: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 1I7QSd-0001wM-LY; Sun, 08 Jul 2007 02:41:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7QSc-0001w0-0F; Sun, 08 Jul 2007 02:41:34 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7QSX-0000Ef-7p; Sun, 08 Jul 2007 02:41:33 -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); Sat, 7 Jul 2007 23:41:27 -0700 Message-ID: <46908715.8040005@azairenet.com> Date: Sat, 07 Jul 2007 23:41:25 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Brian E Carpenter References: <46778180.2090702@gmail.com> In-Reply-To: <46778180.2090702@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jul 2007 06:41:27.0881 (UTC) FILETIME=[02D7F390:01C7C12B] X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Cc: General Area Review Team , Mobile IPv6 Mailing List , kempf@docomolabs-usa.com Subject: [Mip6] Re: Gen-ART review of draft-ietf-mip6-bootstrapping-split-05.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Brian, Thanks for the detailed review. We mostly probably will remove the Anycast based assignment of the Home Agent from the spec and standardize it separately. The use of anycast address for the IKE_SA_INIT request message and then picking a particular responder might have uses beyond just Mobile IPv6. Sam wanted this standardized separately with adequate review from IPsec folks. I am responding to your other comments. Brian E Carpenter wrote: > Substantive: > ------------ > > The draft is generally very clear if one accepts the underlying > model of a split between the Mobility Service Authorizer (MSA) > and Mobility Service Provider (MSP). However I have a concern > that under-specification of MSA/MSP interaction and some details > of MN/HA interaction may lead to interop issues and therefore > encourage the formation of walled gardens, which is the last > thing the Internet needs in mobile service. Also the term 'anycast' > is misused. Details follow: > >> 3. Split scenario > ... >> If, instead, a PKI is used, the Mobile Node and HA exchange >> certificates and there is no AAA server involved [10]. > > It is not indicated here or later how this is determined. How, in > an arbitrary deployment, does a MN know whether the AAA or PKI > model is used? Is a MN implementer supposed to code both solutions? The text is a bit loose. The above text should have been If, instead, PKI is used, the Mobile Node and HA use certificates to authenticate each other and there is no AAA server involved [8]. It will be configuration on the mobile node that tells it what kind of authentication it must use with the home agent. It could vary from pre-shared secrets, EAP (SIM, AKA, etc..) or certificates. >> 4. Components of the solution > ... >> An optional part of bootstrapping involves providing a way for the >> Mobile Node to have its FQDN updated in the DNS with a dynamically >> assigned home address. > > This turns out to assume that dynamic DNS updates are deployed. I wonder > whether this is a realistic assumption. If the mobile node needs to be reachable at its newly bootstrapped home address, then the DNS entry must be updated. If the home agent does not support updating DNS entries, it indicates this in the binding acknowledgment. So, the mobile node would know if its DNS entry was updated. >> 5.1.2. DNS lookup by service name > ... >> ...If the Home Agent of choice does not >> respond for some reason or the IKEv2 authentication fails, the Mobile >> Node SHOULD try other Home Agents on the list. > > This is underspecified - what is the timeout for non-response? > Also is the MN supposed to loop, or to try each HA once only? Added some more text. If the Home Agent of choice does not respond to the IKE_SA_INIT messages or if IKEv2 authentication fails, the Mobile Node SHOULD try the next Home Agent on the list. If none of the Home Agents respond, the Mobile Node SHOULD try again after a period of time that is configurable on the Mobile Node. If IKEv2 authentication fails with all Home Agents, it is an unrecoverable error on the Mobile Node. >> 5.2. IPsec Security Associations setup > ... >> ... Choice of an IKEv2 peer >> authentication method depends on the deployment. > > Again: that is underspecified. Does an MN implementer have > to implement both, and how does the MN know which one to use? It would be decided by configuration on the mobile node. Added some text. Choice of an IKEv2 peer authentication method depends on the deployment. The Mobile Node should be configured with the information on which IKEv2 authentication method to use. >> 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. Changed it to 'MUST'. > >> 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. draft-ietf-mip6-aaa-ha-goals-03 describes the goals for the interface between the Home Agent and the AAA server. RADIUS extensions for this interface are defined in http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-02.txt. Diameter extensions for this interface is defined in http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-03.txt I added references to the above two drafts. >> 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. Both MUST be implemented by the home agent. One of them can be used in a deployment. Modified the text as follows. Home agents MUST implement at least the following two modes of authorization: >> 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'? Ok. > Since use of dynamic DNS is optional, is this a > 'MUST implement' security requirement? If is a "MUST implement" requirement if DNS update is supported by the home agent. >> 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). [16] defines what is required for an interface between the HA and the AAA server. The RADIUS and Diameter extensions documents talk about how to support this. >> 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. If the DNS update for the home address fails, the mobile node would know about it. Isn't this sufficient? > 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/ Done. >> 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/ It is supposed to be "does". We had deleted some text that described how one could also resolve a Home Agent in the visited network by appending some "locaation information" to the FQDN. We had removed that text. But we do want to say it is possible to assign a local home agent. Re-wrote the paragraph Note that the configuration of a home agent FQDN on the mobile node can also be extended to dynamically assign a local home agent from the visited network. Such dynamic assignment would be useful, however, for instance from the point of view of improving routing efficiency in bidirectional tunneling mode. Enhancements or conventions for dynamic assignment of local home agents are outside the scope of this specification. >> 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/ Done. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jul 08 12:33: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 1I7ZhQ-00033O-Pa; Sun, 08 Jul 2007 12:33:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7ZhP-00033I-TK for mip6@ietf.org; Sun, 08 Jul 2007 12:33:27 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7ZhL-0008Tl-Gx for mip6@ietf.org; Sun, 08 Jul 2007 12:33:27 -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, 8 Jul 2007 09:33:22 -0700 Message-ID: <469111CF.2020303@azairenet.com> Date: Sun, 08 Jul 2007 09:33:19 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Lars Eggert References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jul 2007 16:33:22.0563 (UTC) FILETIME=[B33E5D30:01C7C17D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Mobile IPv6 Mailing List , mip6-chairs@tools.ietf.org Subject: [Mip6] Re: COMMENT: draft-ietf-mip6-bootstrapping-split X-BeenThere: mip6@ietf.org X-Mailman-Version: 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 Lars, Lars Eggert wrote: > Comment: > 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. There are four components of the solution. - HA discovery We are removing the anycast based method. So there are two options currently, lookup using the name and lookup using service name. Either of them can be used in a deployment. We are not mandating a particular solution. The mobile node would be configured with an FQDN that corresponds to a particular option. - IPsec SA setup This document basically refers to RFC 4877. Not much new. There are multiple options for authentication between the mobile node and the home agent. But that is natural for any solution where IKEv2 is used for authentication. - Home Address auto-configuration There are two solutions here. One for the home agent assigning a particular home address and one for the mobile node auto-configuring a home address. I believe both are needed. We have provided a mechanism in the draft for the home agent to deny auto-configuration and force the mobile node to use the assigned home address. Not sure if anything is needed beyond this. - DNS update There is only one mechanism described in this draft for DNS update. I believe multiple options for each component is necessary and it is too early to mandate a particular solution for each component. Maybe once we have some experience with Mobile IPv6 deployments we could narrow down the options. :) >> 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.) Agreed. Re-wrote the last part of the Abstract. The solution defined in this document solves the split scenario described in the Mobile IPv6 bootstrapping problem statement in RFC 4640. The split scenario refers the case where the Mobile Node's mobility service is authorized by a different service provider than basic network access. The solution described in this document is also generically applicable to any bootstrapping case, since other scenarios are more specific realizations of the split scenario. > 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? What the paragraph is trying to say is that only the FQDN must be configured on the mobile node. The latter paragraph is saying that the DNS server, to which the DNS request is sent to resolve the FQDN, could be obtained dynamically via DHCPv6 or already configured on the mobile node. Re-wrote the two sentences. As mentioned before in the document, the Mobile Node should be pre- configured with the domain name of the Mobility Service Provider. The Mobile Node needs to obtain the IP address of a DNS server before it can send a DNS request. This can be configured on the Mobile Node or obtained through DHCPv6 from the visited link [12]. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jul 08 14:47: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 1I7bmw-0003pA-AV; Sun, 08 Jul 2007 14:47:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7bmv-0003p5-Hv for mip6@ietf.org; Sun, 08 Jul 2007 14:47:17 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7bmq-0003Kz-Pu for mip6@ietf.org; Sun, 08 Jul 2007 14:47:17 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Jul 2007 20:47:06 +0200 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-korhonen-mip6-service-02.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 8 Jul 2007 20:47:05 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301F271C1@SEHAN021MB.tcad.telia.se> In-Reply-To: <00bf01c7bfab$9f916fd0$d5f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: I-D ACTION:draft-korhonen-mip6-service-02.txt Thread-Index: AcepPU56zCVYT+rkSVa9sbSDpeNePwAR/q4ABYkFbnAACh1D8A== References: <59D7431DE2527D4CB0F1EFEDA5683ED301F26A01@SEHAN021MB.tcad.telia.se> <00bf01c7bfab$9f916fd0$d5f6200a@amer.cisco.com> From: To: , X-OriginalArrivalTime: 08 Jul 2007 18:47:06.0345 (UTC) FILETIME=[61CA5590:01C7C190] X-Spam-Score: 0.2 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Sri, Thanks for the review. Some answers inline. > Hi Jouni, >=20 > Some questions on your service selection draft. Please see inline. > > > Identifier: A variable length service identifier string used to=20 > > identify the requested service. The Identifier string is=20 > encoded as a=20 > > host name or a fully qualified domain name as defined in=20 > [4] and [5]. >=20 > Can you comment on the format of the service identification.=20 > Is the use FQDN format sufficient to represent any service=20 > and is that service definition universal ? Or, do you expect=20 > the specific HA/MN deployment to have a common understanding=20 > of that "service" > definition. Right, this should be a bit more exact here. In a case the service was given as a host name (i.e. one label like "onlinegaming"), the HA/MN deployment must have a common understanding of service's scope. In a case the service was given as a FQDN (e.g. "onlinegaming.example.com"), the service "onlinegaming" is managed under the domain "example.com". A service "onlinegaming.example.net" might not be the same service.. depends on how the domains "example.com" and "example.net" deal with each other. So as a bottom line we are not after universally defined services rather something that is managed under some domain/realm. > It would be nice, if the draft presents the potential services > that the MN can ask. Some examples will be nice. Ok. Will captuare few. > > The Service Selection option is used to assist the authorization and > > identifies a specific service that is to be authorized. The Service > > Selection option MAY also affect the Home Address or Home Network > > Prefix allocation when for example used with the MN-NAI option. For > > the same NAI there MAY be different Home Addresses depending on the > > identified service. Furthermore, the Service Selection option MAY > > also affect the routing of the outbound IP packets in the home agent > > depending on the selected service.=20 >=20 >=20 > Does the request/acceptance of a specific service, impact the current > mobility session, in any ways ? Or is it, just a application traffic > for the session. The above text hinted the use of this service The draft mentions that the service selection option should only be used in the initial BU/PBU when setting up the mobility session. This is because the service selection itself may affect e.g. where the packets are allowed to be forwarded from the the HA etc. When used with e.g. draft-devarapalli-mip6-authprotocol-bootstrap-02 the service selection could even affect the selection of the HoA. > negotiation for "QoS" traffic classification, can you comment on > that and on the services that you have in mind. Different QoS treatment per service is definitely possible. Also=20 different traffic filtering based on the service is possible i.e. the traffic originating from the MN is not allowed to reach some service platform unless the authorization for the requested service succeeded (again one could do this with VPNs but I don't think it is a right path). The use cases I have in mind are mostly cases where a single operator HA is shared between multiple service providers or service platforms that each may require separate authorization for their services. A new option is imho cleaner than e.g. overloading MN-NAI (which would have also worked). Another use case / service in scope is a PMIP6 scenario where the PBU does not include a valid MN-HNP yet. In this case the service selection together with MN-NAI can be used to select a proper MN-HNP.. Assuming again that an operator shares a HA (well.. LMA) for multiple service providers or there might be different MH-HNP per selected external network (that again depends on the selected service). Cheers, Jouni >=20 > Thanks > Sri >=20 >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: jouni.korhonen@teliasonera.com=20 > > [mailto:jouni.korhonen@teliasonera.com]=20 > > Sent: Thursday, June 07, 2007 10:42 PM > > To: mip6@ietf.org > > 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]=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=20 > distinguish between > > > multiple services possibly provisioned to the said=20 > > 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=20 > > 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=20 > intended to > > > assist home agents to make a specific service selection for the > > > mobility service subscription during the binding update=20 > > procedure. > > >=20 > > > A URL for this Internet-Draft is: > > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-korhonen-mip6-service-02.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.=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.=20 > Login with the=20 > > > username "anonymous" and a password of your e-mail address. After=20 > > > logging in, type "cd internet-drafts" and then=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 > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jul 08 18:10: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 1I7exE-0006Lr-Nu; Sun, 08 Jul 2007 18:10:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7exD-0006LI-Eb for mip6@ietf.org; Sun, 08 Jul 2007 18:10:07 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7ex9-0001UJ-4T for mip6@ietf.org; Sun, 08 Jul 2007 18:10:07 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D0AEC19866A; Mon, 9 Jul 2007 01:10:01 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6B9D6198646; Mon, 9 Jul 2007 01:10:01 +0300 (EEST) Message-ID: <469160B9.4020103@piuha.net> Date: Mon, 09 Jul 2007 01:10:01 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Soliman, Hesham" , 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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Mip6] second look at issue 73 X-BeenThere: mip6@ietf.org X-Mailman-Version: 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 Hesham's request I looked at the past discussion relating to issue 73 (mapped v4 addresses vs. a new option). Like 93, consensus was thin if it existed at all, and you probably should have continued the discussion instead of closing the issue as soon as a one person majority was detected :-) This working group needs to understand issues and agree more, and have less divisive consensus calls that end up resembling voting. I was positively surprised that we were able to move forward with issue 93 after all, so lets continue that in future issues. But back to issue 73. Hesham, I would like you to implement this functionality through a separate option, on your AD's request and as a part of bypassing future issues in AD review. After reviewing RFC 4083 and RFC-to-be-draft-ietf- v6ops-security-overview, I believe we should not introduce additional on-the-wire usage for v4 mapped addresses where it can be easily avoided. Even if this usage would be for something else than the outer IP header. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 09 01:39:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7lxf-0008N8-R6; Mon, 09 Jul 2007 01:39:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7lxe-0008Mm-Ln for mip6@ietf.org; Mon, 09 Jul 2007 01:39:02 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7lxa-0003tx-Av for mip6@ietf.org; Mon, 09 Jul 2007 01:39:02 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3240C19866B; Mon, 9 Jul 2007 08:38:57 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C4131198666; Mon, 9 Jul 2007 08:38:56 +0300 (EEST) Message-ID: <4691C9F0.2090900@piuha.net> Date: Mon, 09 Jul 2007 08:38:56 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 References: <469160B9.4020103@piuha.net> In-Reply-To: <469160B9.4020103@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: 8abaac9e10c826e8252866cbe6766464 Cc: Mobile IPv6 Mailing List Subject: [Mip6] Re: second look at issue 73 X-BeenThere: mip6@ietf.org X-Mailman-Version: 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 I meant RFC 4038, not 4083... sorry for the typo. Jari > On Hesham's request I looked at the past discussion relating > to issue 73 (mapped v4 addresses vs. a new option). > > Like 93, consensus was thin if it existed at all, and you > probably should have continued the discussion instead > of closing the issue as soon as a one person majority was > detected :-) This working group needs to understand > issues and agree more, and have less divisive consensus > calls that end up resembling voting. I was positively > surprised that we were able to move forward with > issue 93 after all, so lets continue that in future issues. > > But back to issue 73. Hesham, I would like you to > implement this functionality through a separate > option, on your AD's request and as a part of > bypassing future issues in AD review. After > reviewing RFC 4083 and RFC-to-be-draft-ietf- > v6ops-security-overview, I believe we should > not introduce additional on-the-wire usage > for v4 mapped addresses where it can be > easily avoided. Even if this usage would be > for something else than the outer IP header. > > Jari > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 09 08:06: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 1I7s0f-0001s2-QV; Mon, 09 Jul 2007 08:06:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7s0b-0001px-Lz; Mon, 09 Jul 2007 08:06:29 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7s0W-00059Q-PN; Mon, 09 Jul 2007 08:06:29 -0400 Received: from oaamta08sl.mx.bigpond.com ([124.190.105.118]) by omta04sl.mx.bigpond.com with ESMTP id <20070709120621.XZHU4018.omta04sl.mx.bigpond.com@oaamta08sl.mx.bigpond.com>; Mon, 9 Jul 2007 12:06:21 +0000 Received: from PC20005 ([124.190.105.118]) by oaamta08sl.mx.bigpond.com with ESMTP id <20070709120621.TPOH17816.oaamta08sl.mx.bigpond.com@PC20005>; Mon, 9 Jul 2007 12:06:21 +0000 From: "Hesham Soliman" To: "'Ahmad Muhanna'" , , Subject: RE: [Mip6] issue 93 summary (Text Adequacy) Date: Mon, 9 Jul 2007 22:06:16 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437114C3A912@zrc2hxm2.corp.nortel.com> Thread-Index: Aceorx2gDxKnsRnRRCe92adTSLzcvAAELUjgAARjEMAADGzLYAZHhQRg Message-Id: <20070709120621.TPOH17816.oaamta08sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Ahmad, Sorry for the late reply and thanks for the comments. I included your comments below. One response though: > SUGGESTION: > =========== > 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. => Not if we're using MIPv6 for signalling. MIPv6 requires the use of the HoA and SAs are built based on that. So we can't send the :: address in the BU. I don't think the resources at the HA are a big deal. HAs can be increased if it's an issue for the operator. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 09 09:37: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 1I7tR2-00036P-4g; Mon, 09 Jul 2007 09:37:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7tQm-0002hc-Lp; Mon, 09 Jul 2007 09:37:37 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7tQi-0007lt-6n; Mon, 09 Jul 2007 09:37:36 -0400 Received: from oaamta05sl.mx.bigpond.com ([124.190.105.118]) by omta05sl.mx.bigpond.com with ESMTP id <20070709133728.NSIL29750.omta05sl.mx.bigpond.com@oaamta05sl.mx.bigpond.com>; Mon, 9 Jul 2007 13:37:28 +0000 Received: from PC20005 ([124.190.105.118]) by oaamta05sl.mx.bigpond.com with ESMTP id <20070709133728.FKVH23230.oaamta05sl.mx.bigpond.com@PC20005>; Mon, 9 Jul 2007 13:37:28 +0000 From: "Hesham Soliman" To: , Date: Mon, 9 Jul 2007 23:37: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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfCLkeFsmF3MNrURdimEQHJT+raWw== Message-Id: <20070709133728.FKVH23230.oaamta05sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Mip6] new DSMIP draft X-BeenThere: mip6@ietf.org X-Mailman-Version: 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, Until the draft is announced you can find it here: http://www.elevatemobile.com/ietf/draft-ietf-mip6-nemo-v4traversal-05.txt There are some id nits that I plan to handle with WGLC, I'm transferring it to xml now. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 09 12:00: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 1I7vfN-0006cs-Mv; Mon, 09 Jul 2007 12:00:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7vfE-0006Ko-QC for mip6@ietf.org; Mon, 09 Jul 2007 12:00:40 -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 1I7vez-0002yC-7Q for mip6@ietf.org; Mon, 09 Jul 2007 12:00:40 -0400 Message-ID: <03c301c7c242$1fe52710$576115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jari Arkko" , 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> <4690776C.90101@piuha.net> Subject: Re: [Mip6] bootstrapping-splitanycast/ikev2 ha selection feature Date: Mon, 9 Jul 2007 08:59:26 -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: 2.8 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Fine by me. jak ----- Original Message ----- From: "Jari Arkko" To: Cc: "Mobile IPv6 Mailing List" ; "Sam Hartman" Sent: Saturday, July 07, 2007 10:34 PM Subject: Re: [Mip6] bootstrapping-splitanycast/ikev2 ha selection feature Authors, I realize that this issue has been controversial, but I think the practical way forward is to submit a new version that takes the anycast functionality out, and once the -00 submissions open up again submit the taken out part as a new draft. I believe it is easy to address the other comments for bootstrapping-split, so I should be able to send the revised draft to RFC Editor right after it appears in the I-D directories. Thanks, Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 09 15:15: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 1I7yhZ-00008H-Im; Mon, 09 Jul 2007 15:15:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yhM-0008Gg-1Q; Mon, 09 Jul 2007 15:15:04 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7yhK-0002By-PM; Mon, 09 Jul 2007 15:15:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id A49603292C; Mon, 9 Jul 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7yhK-0001wL-GV; Mon, 09 Jul 2007 15:15: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, 09 Jul 2007 15:15: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-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 : MIP6-bootstrapping for the Integrated Scenario Author(s) : K. Chowdhury, A. Yegin Filename : draft-ietf-mip6-bootstrapping-integrated-dhc-05.txt Pages : 18 Date : 2007-7-9 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-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-bootstrapping-integrated-dhc-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-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-7-9145125.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-bootstrapping-integrated-dhc-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-9145125.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Tue Jul 10 06:22: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 1I8CrM-0008Nd-A6; Tue, 10 Jul 2007 06:22:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8CrK-0008NS-DU; Tue, 10 Jul 2007 06:22:18 -0400 Received: from datnt07.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8CrK-0000w2-1N; Tue, 10 Jul 2007 06:22:18 -0400 X-AuditID: c26e2f18-000020b00000148c-9f-46935d9401fc Received: from camaro.eu.tieto.com ([192.176.143.43]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 13:21:08 +0300 Received: from mustang.eu.tieto.com ([192.176.143.21]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 12:21:27 +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] new DSMIP draft Date: Tue, 10 Jul 2007 12:21:27 +0200 Message-ID: <6C8E068C4D0248408FA49036CC384C8338AE83@mustang.eu.tieto.com> In-Reply-To: <20070709133728.FKVH23230.oaamta05sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] new DSMIP draft Thread-Index: AcfCLkeFsmF3MNrURdimEQHJT+raWwApfB8g References: <20070709133728.FKVH23230.oaamta05sl.mx.bigpond.com@PC20005> From: To: , , X-OriginalArrivalTime: 10 Jul 2007 10:21:27.0179 (UTC) FILETIME=[13107DB0:01C7C2DC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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, A few comments: To me, there is some confusion in the draft as to whether=20 RH type 2 and HAO DST-OPT are used when MIPv6 signaling messages are encapsulated in IPv4. I think, that you now want to say that these are not used (?) Therefore the HAO DST-OPT have disappeared from Packet format A. in Section 4.2 -=20 Right ? If so, the RH type 2 should also disappear from Packet Format B, same section (?) For clarity I think that it could be good to add a few lines somewhere emphasizing this general difference to [MIPv6]. I.e., not only are we encapsulating in IPv4, RH and DST-OPT have also disappeared.=20 A long the same lines, I think that the last part of section 2.3.2.1 needs=20 updating, Ipv4-mapped addresses are no longer used - right ? Finally, Section 2.2 on Mobile Prefix Solicitations and Advertisements doesn't say=20 whether these messages are sent with DST-OPT and RH. Such is a MUST in [MIPv6] and therefore it would be good to clarify whether we keep them here or not. Also in Section 2.2., I do not understand the reference: =20 "Securing such messages would require the mobile node to have security association with the home agent, using IPsec (AH or ESP) and based on the mobile node's IPv4 care-of address as described in [MIPv6]." - ?? It is also here said that "If this effect is not desired, the mobile node can base the SA on the information in the inner header (i.e. using the home agent's IPv6 address, the mobile node's home address and the ICMP protocol number). Such security association would use transport mode ESP protection." Why should this be ESP transport, do you want to say IPv4, IPv6, ESP, ICMP - as in [MIPv6] had we no RH/DST-OPT, and specifically NOT: Ipv4, ESP, IPv6, ICMP. Thanks, Karen > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Monday, July 09, 2007 3:37 PM > To: mip6@ietf.org; nemo@ietf.org > Subject: [Mip6] new DSMIP draft >=20 > Folks,=20 >=20 > Until the draft is announced you can find it here: > http://www.elevatemobile.com/ietf/draft-ietf-mip6-nemo-v4trave rsal-05.txt >=20 > There are some id nits that I plan to handle with WGLC, I'm=20 > transferring it to xml now.=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 Tue Jul 10 07:39: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 1I8E3X-000719-8x; Tue, 10 Jul 2007 07:38:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8E3V-000703-9u; Tue, 10 Jul 2007 07:38:57 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8E3U-0001KV-SR; Tue, 10 Jul 2007 07:38:57 -0400 Received: from oaamta01sl.mx.bigpond.com ([124.190.105.118]) by omta01sl.mx.bigpond.com with ESMTP id <20070710113854.NCCY70.omta01sl.mx.bigpond.com@oaamta01sl.mx.bigpond.com>; Tue, 10 Jul 2007 11:38:54 +0000 Received: from PC20005 ([124.190.105.118]) by oaamta01sl.mx.bigpond.com with ESMTP id <20070710113853.PAQX19191.oaamta01sl.mx.bigpond.com@PC20005>; Tue, 10 Jul 2007 11:38:53 +0000 From: "Hesham Soliman" To: , , Subject: RE: [Mip6] new DSMIP draft Date: Tue, 10 Jul 2007 21:38:47 +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: AcfCLkeFsmF3MNrURdimEQHJT+raWwApfB8gAARWeCA= In-Reply-To: <6C8E068C4D0248408FA49036CC384C8338AE83@mustang.eu.tieto.com> Message-Id: <20070710113853.PAQX19191.oaamta01sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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, > > A few comments: > > To me, there is some confusion in the draft as to whether > RH type 2 and HAO DST-OPT are used when MIPv6 signaling messages > are encapsulated in IPv4. > > I think, that you now want to say that these are not used (?) > Therefore the HAO DST-OPT have disappeared from Packet format A. in > Section 4.2 - > Right ? => Well, since we're forced to use the HoA in the src address field, the HAO becomes redundant, so yes, that's true. > > If so, the RH type 2 should also disappear from Packet Format B, same > section (?) => Yes, it's a slip in the text. > > For clarity I think that it could be good to add a few lines > somewhere > emphasizing this general difference to [MIPv6]. I.e., not only are we > encapsulating > in IPv4, RH and DST-OPT have also disappeared. => ok. > > A long the same lines, I think that the last part of section 2.3.2.1 > needs > updating, Ipv4-mapped addresses are no longer used - right ? => I thought I did that, hmm, I'll take a look. > > Finally, Section 2.2 on Mobile Prefix Solicitations and > Advertisements > doesn't say > whether these messages are sent with DST-OPT and RH. Such is > a MUST in > [MIPv6] and therefore > it would be good to clarify whether we keep them here or not. => Yes. > > Also in Section 2.2., I do not understand the reference: > > "Securing such messages would require the mobile node to have > security > association with the home agent, using IPsec (AH or ESP) > and based on > the mobile node's IPv4 care-of address as described in [MIPv6]." > > - ?? > => This particular text is about 3 years old. At the time, I think my intention was to highlight that if the MN is in an IPv4 network and strictly follows the security requirements for those messages, which may be exchanged before the MN discovers its home address, then the IPv4 HoA may have to be used. That might be tricky with IPv4 and especially when NATs are present. > It is also here said that > > "If this effect > is not desired, the mobile node can base the SA on the > information in > the inner header (i.e. using the home agent's IPv6 address, the > mobile node's home address and the ICMP protocol number). Such > security association would use transport mode ESP protection." > > Why should this be ESP transport, do you want to say IPv4, IPv6, ESP, > ICMP - as in [MIPv6] > had we no RH/DST-OPT, => Right. and specifically NOT: > > Ipv4, ESP, IPv6, ICMP. => Well, this format won't work if a NAT is present. Or do you mean IPv4/UDP/ESP/...etc? Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jul 11 03:38: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 1I8Wm4-0004qW-Vj; Wed, 11 Jul 2007 03:38:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Wm3-0004q2-7m; Wed, 11 Jul 2007 03:38:11 -0400 Received: from ws000774.tietoenator.com ([193.12.181.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Wly-0007bz-Fp; Wed, 11 Jul 2007 03:38:11 -0400 X-AuditID: c10cb581-00001eec00001ed8-b2-469488d72869 Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 09:37:59 +0200 Received: from mustang.eu.tieto.com ([192.176.143.21]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 09:38:03 +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] new DSMIP draft Date: Wed, 11 Jul 2007 09:38:02 +0200 Message-ID: <6C8E068C4D0248408FA49036CC384C8338AF3B@mustang.eu.tieto.com> In-Reply-To: <20070710113853.PAQX19191.oaamta01sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] new DSMIP draft Thread-Index: AcfCLkeFsmF3MNrURdimEQHJT+raWwApfB8gAARWeCAAKXN9kA== References: <6C8E068C4D0248408FA49036CC384C8338AE83@mustang.eu.tieto.com> <20070710113853.PAQX19191.oaamta01sl.mx.bigpond.com@PC20005> From: To: , , X-OriginalArrivalTime: 11 Jul 2007 07:38:03.0377 (UTC) FILETIME=[69F4C610:01C7C38E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 =20 Hi,' >=20 > > > > A few comments: > > > > To me, there is some confusion in the draft as to whether =20 > > RH type 2 and HAO DST-OPT are used when MIPv6 signaling=20 > messages > are encapsulated in IPv4. > > > > I think, that you now want to say that these are not used=20 > (?) > Therefore the HAO DST-OPT have disappeared from Packet=20 > format A. in > Section 4.2 - > Right ? >=20 > =3D> Well, since we're forced to use the HoA in the src address=20 > field, the HAO becomes redundant, so yes, that's true. >=20 "forced to use" - because we should not have ipv4 mapped addresses on the wire - ? >=20 >=20 > > It is also here said that > >=20 > > "If this effect > > is not desired, the mobile node can base the SA on the=20 > > information in > > the inner header (i.e. using the home agent's IPv6 address, the > > mobile node's home address and the ICMP protocol number). Such > > security association would use transport mode ESP protection." > > > > Why should this be ESP transport, do you want to say IPv4,=20 > IPv6, ESP, > ICMP - as in [MIPv6] > had we no RH/DST-OPT,=20 >=20 > =3D> Right. >=20 > and specifically NOT: > > > > Ipv4, ESP, IPv6, ICMP. >=20 > =3D> Well, this format won't work if a NAT is present. Or do=20 > you mean IPv4/UDP/ESP/...etc?=20 If there is a NAT in the path, IP ESP IP changes to (should be changed to) IP UDP ESP IP, RFC 3948. In [MIPv6] these messages - Mobile Prefix Advertisements - are sent with RH and DST-OPT and=20 thus protected with IPSec ESP transport. Now, if (?) we are eliminating the RH and DST-OPT also here, which makes sense if they are eliminated everywhere else, then, as for the BU/BACK, we have the choices of * ESP transport on inner IPv6 level - adding Ipv4/IPv4 UDP tunnel headers afterwards. * ESP tunnel (with or without UDP) anchored on inner packet selectors. to protect this communication. Please note, that I do not want to reopen the IPSec-tunnel headers and more discussion. I am simply saying that the Mobile Prefix Advertisment situation is similar to the BU/BACK discussion. (Yes, except that NAT discovery shouldn't be needed.) Karen >=20 > Hesham >=20 >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jul 11 12:47: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 1I8fM1-0001J0-OG; Wed, 11 Jul 2007 12:47:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8fLw-0001GH-Bk; Wed, 11 Jul 2007 12:47:48 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8fLw-0006OL-41; Wed, 11 Jul 2007 12:47:48 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id EE43632A2E; Wed, 11 Jul 2007 16:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8eqD-0005oV-Qd; Wed, 11 Jul 2007 12:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 11 Jul 2007 12:15:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-split-06.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobile IPv6 bootstrapping in split scenario Author(s) : G. Giaretta, et al. Filename : draft-ietf-mip6-bootstrapping-split-06.txt Pages : 27 Date : 2007-7-11 A Mobile IPv6 node requires a Home Agent address, a home address, and IPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a Mobile IPv6 node can bootstrap this information from non-topological information and security credentials pre-configured on the Mobile Node. The solution defined in this document solves the split scenario described in the Mobile IPv6 bootstrapping problem statement in RFC 4640. The split scenario refers the case where the Mobile Node's mobility service is authorized by a different service provider than basic network access. The solution described in this document is also generically applicable to any bootstrapping case, since other scenarios are more specific realizations of the split scenario. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-bootstrapping-split-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-bootstrapping-split-06.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-7-11112038.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-bootstrapping-split-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-bootstrapping-split-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-11112038.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Wed Jul 11 14:51: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 1I8hHz-0002RL-MO; Wed, 11 Jul 2007 14:51:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8hHx-0002Qp-VV for mip6@ietf.org; Wed, 11 Jul 2007 14:51:50 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8hHx-00046R-MP for mip6@ietf.org; Wed, 11 Jul 2007 14:51:49 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 11 Jul 2007 11:51:49 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CADfDlEarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,527,1175497200"; d="scan'208"; a="385025735:sNHT39850874" 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 l6BIpmc5016516 for ; Wed, 11 Jul 2007 11:51:48 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6BIpmke002856 for ; Wed, 11 Jul 2007 18:51:48 GMT Received: from xmb-sjc-224.amer.cisco.com ([128.107.191.98]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 11:51:42 -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: Wed, 11 Jul 2007 11:51:41 -0700 Message-ID: <28CEA477BE98ED48AF08A0B637A74BF403D0D5F8@xmb-sjc-224.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF69: Soliciting agenda items and time-slot requests for the MIP6 meeting thread-index: AcepR4YLxFXojRU6EdyT2wARJNUNiAao+uWQ From: "Gopal Dommety \(gdommety\)" To: X-OriginalArrivalTime: 11 Jul 2007 18:51:42.0511 (UTC) FILETIME=[85A32BF0:01C7C3EC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=914; t=1184179908; x=1185043908; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gdommety@cisco.com; z=From:=20=22Gopal=20Dommety=20\(gdommety\)=22=20 |Subject:=20=20IETF69=3A=20Soliciting=20agenda=20items=20and=20time-slot= 20requests=20for=20the=20MIP6=20meeting |Sender:=20; bh=7M/KvrsL8YngKtRCvz66XzDGHxu7OE4EQPVbXWcebI8=; b=dRAhxBwOW4QFAzjot/LQtBh6fx+g8juyPFXrcB9pUytfzUzcHtzBtI5c7K7EXJOf9HRXPdr6 0kkZXI8Y7DV+tUm2FC1kRhCR3zJDl/Sf4g25MbgZoMoyNhUzjjbIf070; Authentication-Results: sj-dkim-2; header.From=gdommety@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Folks, We sent out a solicitation for agenda items (6/7/2007) before and I am resending the request. ------------------------------------------------------------------------ ------------=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 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 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jul 11 17:00: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 1I8jIF-0006Ev-UA; Wed, 11 Jul 2007 17:00:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8jIE-0006Ek-HK for mip6@ietf.org; Wed, 11 Jul 2007 17:00:14 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8jIE-0000Xy-8b for mip6@ietf.org; Wed, 11 Jul 2007 17:00:14 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l6BL3s0r011502 for ; Wed, 11 Jul 2007 16:03:54 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 15:59:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jul 2007 16:59:48 -0400 Message-ID: <95D8C1105D54EB41864F8831E6C4EB75021C809C@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tunneling Optimization Thread-Index: AcfD/msO/F2Y/lBrSjKqxR2cmQrNxw== From: "Wassim Haddad \(KI/EAB\)" To: X-OriginalArrivalTime: 11 Jul 2007 20:59:49.0405 (UTC) FILETIME=[6B621CD0:01C7C3FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: "Wassim Haddad \(KI/EAB\)" Subject: [Mip6] Tunneling Optimization X-BeenThere: mip6@ietf.org X-Mailman-Version: 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, FYI, A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : IP Tunneling Optimization in a Mobile = Environment Author(s) : W. Haddad, et al. Filename : = draft-haddad-mip6-tunneling-optimization-01.txt Pages : 18 Date : 2007-7-11 =20 This memo introduces a simple tunneling optimization mechanism, which removes the need for inserting an additional header in the IP packet. = The=20 main goals are to minimize the packet size, provide a simpler protocol=20 design and a better efficiency. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haddad-mip6-tunneling-optimizat= ion-01.txt Comments are appreciated. Regards, Wassim H. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 12 13:16:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I92HH-0003fb-Dj; Thu, 12 Jul 2007 13:16:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I92H9-0003Qb-UP; Thu, 12 Jul 2007 13:16:23 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I92H4-0003Uc-TP; Thu, 12 Jul 2007 13:16:23 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id D92D1329D0; Thu, 12 Jul 2007 17:16:18 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I92H4-0005XX-9H; Thu, 12 Jul 2007 13:16:18 -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, 12 Jul 2007 13:16:18 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-nemo-v4traversal-05.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) Author(s) : H. Soliman Filename : draft-ietf-mip6-nemo-v4traversal-05.txt Pages : 27 Date : 2007-7-12 The current Mobile IPv6 and NEMO specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the HA. This specification also allows the Mobile Node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4traversal-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-nemo-v4traversal-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-nemo-v4traversal-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-7-12122543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-nemo-v4traversal-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-nemo-v4traversal-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-12122543.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 Fri Jul 13 16:31: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 1I9Rns-0008FC-EK; Fri, 13 Jul 2007 16:31:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Rnq-0007zi-I4; Fri, 13 Jul 2007 16:31:50 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I9Rnp-0008Gb-NK; Fri, 13 Jul 2007 16:31:50 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1094698089f; Sat, 14 Jul 2007 04:43:18 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm9f46936ff0; Tue, 10 Jul 2007 10:35:55 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Tue, 10 Jul 2007 10:35:55 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yhY-0008TF-DU; Mon, 09 Jul 2007 15:15:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yhM-0008Gg-1Q; Mon, 09 Jul 2007 15:15:04 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7yhK-0002By-PM; Mon, 09 Jul 2007 15:15:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id A49603292C; Mon, 9 Jul 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7yhK-0001wL-GV; Mon, 09 Jul 2007 15:15: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, 09 Jul 2007 15:15:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-integrated-dhc-05.txt X-BeenThere: mip6@ietf.org Reply-To: internet-drafts@ietf.org 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-05.txt Pages : 18 Date : 2007-7-9 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-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-bootstrapping-integrated-dhc-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-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-7-9145125.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-bootstrapping-integrated-dhc-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-9145125.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Fri Jul 13 17:30: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 1I9Sia-0006vB-Mh; Fri, 13 Jul 2007 17:30:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Sia-0006v1-4P for mip6@ietf.org; Fri, 13 Jul 2007 17:30:28 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9SiZ-0001iK-QS for mip6@ietf.org; Fri, 13 Jul 2007 17:30:28 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL400E9MZQ0KY@usaga01-in.huawei.com> for mip6@ietf.org; Fri, 13 Jul 2007 14:30:01 -0700 (PDT) Received: from N737011 ([10.192.25.70]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL4007TBZPWYT@usaga01-in.huawei.com> for mip6@ietf.org; Fri, 13 Jul 2007 14:30:00 -0700 (PDT) Date: Fri, 13 Jul 2007 14:29:24 -0700 From: Madjid Nakhjiri Subject: HoA assignment: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-split-06.txt In-reply-to: To: mip6@ietf.org Message-id: <003301c7c594$e2fad6f0$4619c00a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfD2whtegSnhkyRQceBpOUhxiAfrQBuVMKA X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Question on this draft, I apologize if this has been discussed before. HoA bootstrapping seems to be done in two ways: 1) HoA assignment by HA 2) HoA auto-configuration Can't the HoA be bootstrapped through interaction with the AAA server? I believe this is an option with many other bootstrapping/AAA interaction documents. Thanks, Madjid -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, July 11, 2007 9:15 AM To: i-d-announce@ietf.org Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-split-06.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobile IPv6 bootstrapping in split scenario Author(s) : G. Giaretta, et al. Filename : draft-ietf-mip6-bootstrapping-split-06.txt Pages : 27 Date : 2007-7-11 A Mobile IPv6 node requires a Home Agent address, a home address, and IPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a Mobile IPv6 node can bootstrap this information from non-topological information and security credentials pre-configured on the Mobile Node. The solution defined in this document solves the split scenario described in the Mobile IPv6 bootstrapping problem statement in RFC 4640. The split scenario refers the case where the Mobile Node's mobility service is authorized by a different service provider than basic network access. The solution described in this document is also generically applicable to any bootstrapping case, since other scenarios are more specific realizations of the split scenario. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-06.t xt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-bootstrapping-split-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-bootstrapping-split-06.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 From mip6-bounces@ietf.org Sun Jul 15 11:22: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 1IA5vM-0007GH-4D; Sun, 15 Jul 2007 11:22:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5vK-0007B6-Kn for mip6@ietf.org; Sun, 15 Jul 2007 11:22:14 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IA5vF-0005T8-HH for mip6@ietf.org; Sun, 15 Jul 2007 11:22:14 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 3493659DA1; Mon, 16 Jul 2007 01:22:08 +1000 (EST) Message-ID: <469A3B92.6050902@firstpr.com.au> Date: Mon, 16 Jul 2007 01:21:54 +1000 From: Robin Whittle Organization: First Principles 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 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Subject: [Mip6] LISP or Ivip for IPv4/6 mobility support X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I am not directly involved with Mobile IP, but am working on a new routing and addressing architecture for the Internet, as are other people on the RAM list: http://www1.ietf.org/mailman/listinfo/ram in response to the IAB RAWS report: http://www.iab.org/about/workshops/routingandaddressing/ http://tools.ietf.org/html/draft-iab-raws-report A proposal called LISP (Locator/ID Separation Protocol): http://tools.ietf.org/html/draft-farinacci-lisp http://tools.ietf.org/html/draft-lear-lisp-nerd http://tools.ietf.org/html/draft-meyer-lisp-cons involves a global system of Ingress Tunnel Routers (ITRs) which intercept packets addressed to certain prefixes and tunnel them to one of many Egress Tunnel Routers (ETRs). The mapping between the original address (EID) and the tunnel endpoint (RLOC) is controlled, in one way or another, by a centralised or distributed database - in principle down to single IP address granularity for IPv4, and maybe /64 for IPv6. I have my own proposal - Ivip (Internet Vastly Improved Plumbing) which is based on some of LISP's principles. http://www.firstpr.com.au/ip/ivip/ An I-D draft-whittle-ivip-arch-00 is available there and should appear in the IETF system soon. I think Ivip is more incrementally deployable than LISP, because Ivip ITRs can be outside provider and AS-end-user networks, using anycast to attract packets which are addressed to Ivip-mapped addresses, without there needing to be an ITR in every such network (as with LISP) in order for hosts in those networks to be able to send packets to hosts with LISP/Ivip-mapped addresses. The current state of discussions on the RAM list indicates that the most likely solution to the problems with routing and addressing will be something like LISP or Ivip. Once such a system of ITRs exists, if it could be controlled rapidly (which it needs to be to fulfil its primary mission of supporting multihomed end-user networks without involving traditional PI address space or BGP), then this is a mighty powerful tool for directing packets sent by Correspondent Nodes (CNs) towards what I call "Translating Tunnel Routers" (TTRs). Consider thousands of TTRs all around the Net, inside and outside provider and AS-end-user networks. Mobile Nodes (MNs - which have their own care-of-address in each network they connect to) find a topologically nearby TTR and create a two-way tunnel to it. If the MN has two network connections (eg. UMTS and WiFi), it can find two different TTRs, probably in each network, but also perhaps nearby but not associated with these networks. Then it can build two tunnels to these two TTRs. Now consider each TTR to be somewhat like a home-agent with a 2-way tunnel from the MN. However, the MN can (probably with help from a centralised monitoring system) change the LISP/Ivip mapping database to make all the ITRs tunnel packets to one TTR or another. The TTR decapsulates the packets from the tunnel it entered at any one of these ITRs around the Net. It then tunnels the packet to the MN. Packets from the MN are sent out one link or the other, where the TTR at the end of that 2-way tunnel forwards them to the rest of the Net. The MN has its own LISP/Ivip-mapped IP address - completely unrelated to the addresses of these ITRs or TTRs. This means it can make multiple connections via various networks as it moves around the world, directing the LISP/Ivip system to beam packets to whichever TTR is best at the time. The MN can maintain sessions on its Ivip-mapped IP address. ................ ............ . N1 . . N2 . . . . . . CN1----ITR1~~~~~BR~~~TR~~~BR~~~~~TTR1===PE==\ . . \ . . = ................ | ............ = | = | = | MN1 ......... | ........... = . N4 . / . N3 . = . ./ . . = . TTR2==BR======BR==========PE==/ . . . . ......... ........... ~~~~ 1-way Ivip tunnel ==== 2-way tunnel established by Mobile Node to TTR Figure 10: Mobile IP with two TTRs. From "TTRs and Mobility": http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-arch-00.html#anchor81 Not shown is that multiple CNs all over the Net have their packets tunneled, by generally different ITRs near to each CN, to the same TTR for a given MN. The paths taken by the packets are generally highly optimal, since they flow from the CN to a nearby ITR (which is probably in the shortest path anyway) and then to the TTR which is close to the MN. Packets in the reverse direction come out of the MN and go via ordinary BGP routing to the CH - unless the CH has a LISP/Ivip-mapped address, in which case they go via an ITR near the TTR (or integrated into the TTR) and then an ETR near the CH. All this should work fine for unmodified CNs. The MH needs special software, of course. This should work for both IPv4 and IPv6. - Robin _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 16 13:46: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 1IAUe7-0007ka-0Z; Mon, 16 Jul 2007 13:46:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUe5-0007kJ-A8 for mip6@ietf.org; Mon, 16 Jul 2007 13:46:05 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAUe4-0006a5-UQ for mip6@ietf.org; Mon, 16 Jul 2007 13:46:05 -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, 16 Jul 2007 10:46:03 -0700 Message-ID: <469BAEDB.3010509@azairenet.com> Date: Mon, 16 Jul 2007 10:46:03 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Mobile IPv6 Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2007 17:46:03.0236 (UTC) FILETIME=[2DB64240:01C7C7D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [Mip6] MIP6_HOME_PREFIX attribute in draft-ietf-mip6-bootstrapping-split X-BeenThere: mip6@ietf.org X-Mailman-Version: 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, We completely messed up the format of the MIP6_HOME_PREFIX attribute in draft-ietf-mip6-bootstrapping-split. It is in section 8.2. Sheila Frankel caught it. Here are the comments we got as part of security review. > -- The Attribute Type is described as 15 bits, but the diagram displays it as 31 > bits. > -- The length is described as "multi-valued". This term is generally used in > IKEv2 to describe an attribute which can appear more than once (e.g. > INTERNAL_IPV6_ADDRESS). That term is not appropriate here to describe the length > field, since obviously it can take different values (one at a time), or > otherwise it would not be needed. > -- The length is described to be 0 or 17. The value 17 is specified as the > length of the home prefix and the prefix length. As shown, the home prefix and > prefix length are 18 octets. Also, the length field should include the prefix > lifetime, making the correct value 22 octets. > -- Generally, in IKEv2, IPv6 addresses (analogous to the home prefix) consist of > 17 octets: a 16-octet address, followed by a 1-octet prefix length. In this > case, if the Attribute Type and Length together are 4 octets, and are followed > by the 4-octet Prefix Lifetime, they can then be followed by a 17-octet home > prefix + prefix length. (I suggest placing the Prefix Lifetime first so the > 17-octet value can be on a 4-octet boundary.) The Length will then be 21 octets. The new format is as follows. 8.2. MIP6_HOME_PREFIX attribute The MIP6_HOME_PREFIX attribute is carried in IKEv2 Configuration Payload messages. This attribute is used to convey the home prefix from which the Mobile Node auto-configures its home address. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Home Prefix | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | +-+-+-+-+-+-+-+-+ Reserved (1 bit) This bit MUST be set to zero and MUST be ignored on receipt Attribute Type (15 bits) A unique identifier for the MIP6_HOME_PREFIX attribute. To be assigned by IANA Length (2 octets) Length in octets of Value field (Home Prefix, Prefix Lifetime and Prefix Length). This can be 0 or 21 Prefix Lifetime (4 octets) The lifetime of the Home Prefix Home Prefix (16 octets) The prefix of the home link through which the Mobile Node may auto-configure its Home Address Prefix Length (1 octet) The length in bits of the home prefix specified in the field Home Prefix When the MIP6_HOME_PREFIX attribute is included by the Mobile Node in the CFG_REQUEST payload, the value of the Length field is 0. When the MIP6_HOME_PREFIX attribute is included in the CFG_REPLY payload by the Home Agent, the value of the Length field is 21 and the attribute contains also the home prefix information. Please review. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 16 15:37: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 1IAWNQ-0005bm-DS; Mon, 16 Jul 2007 15:37:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAWNO-0005bh-Ur for mip6@ietf.org; Mon, 16 Jul 2007 15:36:58 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAWNK-0008Sa-6k for mip6@ietf.org; Mon, 16 Jul 2007 15:36:58 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 16 Jul 2007 12:36:43 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAH9lm0arR7PE/2dsb2JhbACCYA X-IronPort-AV: i="4.16,543,1175497200"; d="scan'208,217"; a="183012495:sNHT538755345" 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 l6GJahEl020087 for ; Mon, 16 Jul 2007 12:36:43 -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 l6GJacAE018421 for ; Mon, 16 Jul 2007 19:36:43 GMT Received: from xmb-sjc-224.amer.cisco.com ([128.107.191.98]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 12:36:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jul 2007 12:33:32 -0700 Message-ID: <28CEA477BE98ED48AF08A0B637A74BF403D97C40@xmb-sjc-224.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tentative Agenda for MIP6 WG thread-index: AcfH4DG+VGd3syDZT9udBcAeEPlxew== From: "Gopal Dommety \(gdommety\)" To: X-OriginalArrivalTime: 16 Jul 2007 19:36:41.0375 (UTC) FILETIME=[A259E2F0:01C7C7E0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11885; t=1184614603; x=1185478603; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gdommety@cisco.com; z=From:=20=22Gopal=20Dommety=20\(gdommety\)=22=20 |Subject:=20Tentative=20Agenda=20for=20MIP6=20WG |Sender:=20; bh=5IM8cORnkKlFIqRsfyN4+TzDIcbshsYhawcN/CWipbk=; b=o74h2XAcVmwuYMXtixkopsxr+KxaymSNqhn1woYLhpsbPAIyFTGLZlKRiBF67YDnSkSviY6y 77FixA+DVzgEDoZDioN5pM/INPL2fg9f8QboPf53ZFdh83MjHfZL8nFz; Authentication-Results: sj-dkim-4; header.From=gdommety@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Subject: [Mip6] Tentative Agenda for MIP6 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: , Content-Type: multipart/mixed; boundary="===============0383700330==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0383700330== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C7E0.A243163F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C7E0.A243163F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello All, =20 I have put together the tentative agenda consisting of requests I received. I have only received four requests. Please let me know if there are any requests that I missed. Some of you might have sent the request to Raj and I don't have access to them (as he is out on vacation). Please re-send them to me.=20 =20 Regards, Gopal =20 =20 =20 MIP6 Agenda, IETF 69 ----------------------- Tuesday, July 24, Afternoon Session II 1520-1720 =20 =20 1. Agenda review, Blue sheets and volunteers for=20 notes and Jabber 5 Mins =20 2. WG status and I-Ds update 10 Mins =20 3. draft-ietf-mip6-bootstrapping-split-06 15 Mins Vijay Devarapalli=20 =20 =20 4. draft-krishnan-mip6-firewall-01 15 min Suresh Krishnan =20 5. draft-muhanna-mip6-binding-revocation-01.txt 15 min Ahmad =20 6. draft-bharatia-mip6-gen-ext-01.txt. 15 min Kuntal =20 7. Next Steps Chairs 10 Mins =20 ------------------------------------------------------- Judgment hinders imagination ---------------------------------------------- | | Gopal Dommety. Ph.D :|: :|: Services and Mobility, NSSTG :|||: :|||: Cisco Systems :|||||||: :||||||||: Voice: 408.525.1404 .:|||||||||:.:|||||||||||:. Fax: 408.525.1653 C i s c o S y s t e m s Email: gdommety@cisco.com =20 ------_=_NextPart_001_01C7C7E0.A243163F Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello All,

 

    I have put = together the=20 tentative agenda consisting  of requests I received. I = have only=20 received four requests.  Please  let me know if there are any = requests=20 that I missed. Some of you might have sent the request to Raj and I = don't have=20 access to them (as he is out on vacation). Please re-send them to me.=20

 

Regards,

Gopal

 

 

 

MIP6 Agenda, IETF 69

-----------------------

Tuesday, July 24, Afternoon Session II 1520-1720

 

 

1. Agenda review, Blue sheets and volunteers for

   = notes=20 and Jabber           &n= bsp;           &nb= sp;           &nbs= p; =20            &nbs= p;    =20  5 = Mins

 

2. WG status and I-Ds update           &n= bsp;           &nb= sp;  =20           =20   10 = Mins

 

3. draft-ietf-mip6-bootstrapping-split-06            &nbs= p;         =20     15=20 Mins

Vijay Devarapalli

 

 

4. =  draft-krishnan-mip6-firewall-01           &nbs= p;            = ;       =20 15 min

Suresh Krishnan

 

5.=20 draft-muhanna-mip6-binding-revocation-01.txt         =20     15=20 min

Ahmad

 

6. draft-bharatia-mip6-gen-ext-01.txt.              &nbs= p;           =20 15 min

       =20 Kuntal

 

7. Next Steps

   =20 Chairs           &n= bsp;    =20            &n= bsp;           &nb= sp;                &nbs= p;           =20   10=20 Mins

 
-------------------------------------------------------
       Judgment hinders=20 imagination
----------------------------------------------
&= nbsp;    =20 |         =20 |            =        Gopal=20 Dommety. Ph.D
    =20 :|:       =20 :|:           &nbs= p;      =20 Services and Mobility, NSSTG
   =20 :|||:      =20 :|||:           &n= bsp;      Cisco=20 Systems
   :|||||||:  =20 :||||||||:          &nb= sp;    =20 Voice:=20 408.525.1404
 .:|||||||||:.:|||||||||||:.    =           =20 Fax:   408.525.1653
C i s c o S y s t e m=20 s     Email: gdommety@cisco.com
 
------_=_NextPart_001_01C7C7E0.A243163F-- --===============0383700330== 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 --===============0383700330==-- From mip6-bounces@ietf.org Mon Jul 16 17: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 1IAXiX-0003zI-As; Mon, 16 Jul 2007 17:02:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAXiW-0003zC-Gd for mip6@ietf.org; Mon, 16 Jul 2007 17:02:52 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAXiS-0002Gv-1U for mip6@ietf.org; Mon, 16 Jul 2007 17:02:52 -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, 16 Jul 2007 14:02:46 -0700 Message-ID: <469BDCF5.3090605@azairenet.com> Date: Mon, 16 Jul 2007 14:02:45 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Madjid Nakhjiri References: <003301c7c594$e2fad6f0$4619c00a@china.huawei.com> In-Reply-To: <003301c7c594$e2fad6f0$4619c00a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2007 21:02:46.0269 (UTC) FILETIME=[A8DE2AD0:01C7C7EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: mip6@ietf.org Subject: [Mip6] Re: HoA assignment X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Madjid Nakhjiri wrote: > Question on this draft, I apologize if this has been discussed before. > > HoA bootstrapping seems to be done in two ways: > 1) HoA assignment by HA > 2) HoA auto-configuration > > Can't the HoA be bootstrapped through interaction with the AAA server? Need more details. Is the AAA server managing the prefixes for a home link? Or does the AAA server store a static 128 bit home address for the mobile node as part of the mobile node's profile? Vijay > I believe this is an option with many other bootstrapping/AAA interaction > documents. > > Thanks, > Madjid > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, July 11, 2007 9:15 AM > To: i-d-announce@ietf.org > Cc: mip6@ietf.org > Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-split-06.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobility for IPv6 Working Group of the > IETF. > > Title : Mobile IPv6 bootstrapping in split scenario > Author(s) : G. Giaretta, et al. > Filename : draft-ietf-mip6-bootstrapping-split-06.txt > Pages : 27 > Date : 2007-7-11 > > A Mobile IPv6 node requires a Home Agent address, a home address, and > IPsec security associations with its Home Agent before it can start > utilizing Mobile IPv6 service. RFC 3775 requires that some or all of > these are statically configured. This document defines how a Mobile > IPv6 node can bootstrap this information from non-topological > information and security credentials pre-configured on the Mobile > Node. The solution defined in this document solves the split > scenario described in the Mobile IPv6 bootstrapping problem statement > in RFC 4640. The split scenario refers the case where the Mobile > Node's mobility service is authorized by a different service provider > than basic network access. The solution described in this document > is also generically applicable to any bootstrapping case, since other > scenarios are more specific realizations of the split scenario. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-06.t > xt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-mip6-bootstrapping-split-06.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mip6-bootstrapping-split-06.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 16 19:30:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAa1J-00065k-BZ; Mon, 16 Jul 2007 19:30:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAa1H-00065X-Cv for mip6@ietf.org; Mon, 16 Jul 2007 19:30:23 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAa14-0007Am-0s for mip6@ietf.org; Mon, 16 Jul 2007 19:30:23 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLA002IIPA92E@usaga01-in.huawei.com> for mip6@ietf.org; Mon, 16 Jul 2007 16:30:09 -0700 (PDT) Received: from N737011 ([10.192.25.70]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLA004U2PA437@usaga01-in.huawei.com> for mip6@ietf.org; Mon, 16 Jul 2007 16:30:09 -0700 (PDT) Date: Mon, 16 Jul 2007 16:30:05 -0700 From: Madjid Nakhjiri In-reply-to: <469BDCF5.3090605@azairenet.com> To: 'Vijay Devarapalli' Message-id: <005901c7c801$3db7b2c0$4619c00a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfH7HFGdf/tzHI2QIGffhvt4D3gagAEd2BQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: mip6@ietf.org Subject: [Mip6] RE: HoA assignment X-BeenThere: mip6@ietf.org X-Mailman-Version: 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, Both, I guess. Take the case of a fixed user (e.g. a WiMAX DSL replacement) where the user might always get the same IP address. In this case, she can get it from AAA. The alternative is if it just get the prefixes. Now aside from the details, it seems that the bootstrapping doc should include this option, otherwise the Diameter spec may not provide any accommodation from transfer of HoA or any parts of it from AAA. R, Madjid -----Original Message----- From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] Sent: Monday, July 16, 2007 2:03 PM To: Madjid Nakhjiri Cc: mip6@ietf.org Subject: Re: HoA assignment Madjid Nakhjiri wrote: > Question on this draft, I apologize if this has been discussed before. > > HoA bootstrapping seems to be done in two ways: > 1) HoA assignment by HA > 2) HoA auto-configuration > > Can't the HoA be bootstrapped through interaction with the AAA server? Need more details. Is the AAA server managing the prefixes for a home link? Or does the AAA server store a static 128 bit home address for the mobile node as part of the mobile node's profile? Vijay > I believe this is an option with many other bootstrapping/AAA interaction > documents. > > Thanks, > Madjid > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, July 11, 2007 9:15 AM > To: i-d-announce@ietf.org > Cc: mip6@ietf.org > Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-split-06.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobility for IPv6 Working Group of the > IETF. > > Title : Mobile IPv6 bootstrapping in split scenario > Author(s) : G. Giaretta, et al. > Filename : draft-ietf-mip6-bootstrapping-split-06.txt > Pages : 27 > Date : 2007-7-11 > > A Mobile IPv6 node requires a Home Agent address, a home address, and > IPsec security associations with its Home Agent before it can start > utilizing Mobile IPv6 service. RFC 3775 requires that some or all of > these are statically configured. This document defines how a Mobile > IPv6 node can bootstrap this information from non-topological > information and security credentials pre-configured on the Mobile > Node. The solution defined in this document solves the split > scenario described in the Mobile IPv6 bootstrapping problem statement > in RFC 4640. The split scenario refers the case where the Mobile > Node's mobility service is authorized by a different service provider > than basic network access. The solution described in this document > is also generically applicable to any bootstrapping case, since other > scenarios are more specific realizations of the split scenario. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-06.t > xt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-mip6-bootstrapping-split-06.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mip6-bootstrapping-split-06.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 16 19:50: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 1IAaKF-0003qj-PL; Mon, 16 Jul 2007 19:49:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAaKF-0003qM-6C for mip6@ietf.org; Mon, 16 Jul 2007 19:49:59 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAaKB-0006me-IW for mip6@ietf.org; Mon, 16 Jul 2007 19:49:59 -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, 16 Jul 2007 16:49:53 -0700 Message-ID: <469C0421.8010801@azairenet.com> Date: Mon, 16 Jul 2007 16:49:53 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Madjid Nakhjiri References: <005901c7c801$3db7b2c0$4619c00a@china.huawei.com> In-Reply-To: <005901c7c801$3db7b2c0$4619c00a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2007 23:49:53.0984 (UTC) FILETIME=[01DA0C00:01C7C804] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: mip6@ietf.org Subject: [Mip6] Re: HoA assignment X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Madjid Nakhjiri wrote: > Hi Vijay, > > Both, I guess. A AAA server managing the prefixes for a home link, IMHO, does not make sense. The home link prefix is associated with a particular home agent (or a set of home agents) that serves the home prefix. The home prefix management should be with the home agents. This prefixes could also change over time. It is sufficient if the mobile node gets to know about the home prefix from the home agent. Having a static home address for the mobile node in the AAA is possible. This would mean that the home prefix for the mobile node is fixed. > Take the case of a fixed user (e.g. a WiMAX DSL replacement) > where the user might always get the same IP address. In this case, she can > get it from AAA. The alternative is if it just get the prefixes. The "alternative" is not complete. > > Now aside from the details, it seems that the bootstrapping doc should > include this option, otherwise the Diameter spec may not provide any > accommodation from transfer of HoA or any parts of it from AAA. The MIP6 WG is still driving the requirements for the DIME extensions, right? ;) Vijay > > R, > > Madjid > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Monday, July 16, 2007 2:03 PM > To: Madjid Nakhjiri > Cc: mip6@ietf.org > Subject: Re: HoA assignment > > Madjid Nakhjiri wrote: >> Question on this draft, I apologize if this has been discussed before. >> >> HoA bootstrapping seems to be done in two ways: >> 1) HoA assignment by HA >> 2) HoA auto-configuration >> >> Can't the HoA be bootstrapped through interaction with the AAA server? > > Need more details. Is the AAA server managing the prefixes for a home > link? Or does the AAA server store a static 128 bit home address for > the mobile node as part of the mobile node's profile? > > Vijay > >> I believe this is an option with many other bootstrapping/AAA interaction >> documents. >> >> Thanks, >> Madjid >> >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: Wednesday, July 11, 2007 9:15 AM >> To: i-d-announce@ietf.org >> Cc: mip6@ietf.org >> Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-split-06.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Mobility for IPv6 Working Group of the >> IETF. >> >> Title : Mobile IPv6 bootstrapping in split scenario >> Author(s) : G. Giaretta, et al. >> Filename : draft-ietf-mip6-bootstrapping-split-06.txt >> Pages : 27 >> Date : 2007-7-11 >> >> A Mobile IPv6 node requires a Home Agent address, a home address, and >> IPsec security associations with its Home Agent before it can start >> utilizing Mobile IPv6 service. RFC 3775 requires that some or all of >> these are statically configured. This document defines how a Mobile >> IPv6 node can bootstrap this information from non-topological >> information and security credentials pre-configured on the Mobile >> Node. The solution defined in this document solves the split >> scenario described in the Mobile IPv6 bootstrapping problem statement >> in RFC 4640. The split scenario refers the case where the Mobile >> Node's mobility service is authorized by a different service provider >> than basic network access. The solution described in this document >> is also generically applicable to any bootstrapping case, since other >> scenarios are more specific realizations of the split scenario. >> >> A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-06.t >> xt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body of >> the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-ietf-mip6-bootstrapping-split-06.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-mip6-bootstrapping-split-06.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jul 17 03:30: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 1IAhWC-0005tl-VA; Tue, 17 Jul 2007 03:30:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAhWC-0005ta-7y for mip6@ietf.org; Tue, 17 Jul 2007 03:30:48 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IAhWB-00054e-O0 for mip6@ietf.org; Tue, 17 Jul 2007 03:30:48 -0400 Received: (qmail invoked by alias); 17 Jul 2007 07:30:30 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp049) with SMTP; 17 Jul 2007 09:30:30 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+tfG0cbY+tMG9uJgBnFhe02J3K7SluU631RFqs/w jhIfuhQJoM6VnL Message-ID: <469C7015.2030809@gmx.net> Date: Tue, 17 Jul 2007 09:30:29 +0200 From: Hannes Tschofenig 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-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [Mip6] [Fwd: [RAI] ICE tutorial in Chicago [DO NOT REPLY] - PLEASE ADVISE IF YOU WILL ATTEND!] X-BeenThere: mip6@ietf.org X-Mailman-Version: 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 tutorial about ICE might be of interest for the group. Please drop Jonathan a mail if you are interested. Ciao Hannes -------- Original Message -------- Subject: [RAI] ICE tutorial in Chicago [DO NOT REPLY] - PLEASE ADVISE IF YOU WILL ATTEND! Date: Mon, 16 Jul 2007 21:23:43 -0400 From: Jonathan Rosenberg To: IETF SIP List , IETF Sipping List , IETF MMUSIC WG , Behave WG , P2PSIP WG , rai@ietf.org, "'avt@ietf.org'" I've gotten very few responses indicating interest. If I don't get more acceptances I'll have to cancel. Please, if you do plan on attending, send me mail per the instructions below if you have not done so. (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt) [-17 should be available shortly] WHEN: Tuesday, July 24, 2007, 1145-1245 (lunch logistics are in progress and will be announced ASAP) WHERE: Red Lacquar WHO: Anyone that would like to learn more about ICE. WHY: ICE, developed by the mmusic working group, has been defined as the IETF tool for NAT traversal for SIP-based media. It is also seeing increased usage for traversal for other kinds of application traffic - anything worrying about any-to-any communications. In this tutorial, we will overview the background of the problem, consider the requirements driving ICE, and provide an overview of how ICE works. An understanding of SIP is not required. The tutorial will be based on the pending -17 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice) so I can get a count of the number of participants for lunch purposes. !DO NOT REPLY TO THIS NOTE! -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jul 17 03: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 1IAhmz-0007Aj-FI; Tue, 17 Jul 2007 03:48:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAhmv-00079k-Tv; Tue, 17 Jul 2007 03:48:05 -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 1IAhmr-00045r-Bu; Tue, 17 Jul 2007 03:48:05 -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 l6H7ljqp005267; Tue, 17 Jul 2007 10:47:54 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 10:47:48 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 10:47:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] I-D ACTION:draft-ietf-mip6-nemo-v4traversal-05.txt Date: Tue, 17 Jul 2007 10:47:45 +0300 Message-ID: <58357EDC7884E24BAD684C1B2D91F96D05CB6678@trebe101.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] I-D ACTION:draft-ietf-mip6-nemo-v4traversal-05.txt Thread-Index: AcfEqGuYgvi1vWtbQM+7XFbbr4Jn0QDlu5SA References: From: To: X-OriginalArrivalTime: 17 Jul 2007 07:47:47.0577 (UTC) FILETIME=[C4A51E90:01C7C846] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) 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 Hi Hesham, The new version has the IPv4-mapped IPv6 address text changed according to the new IPv4 CoA option except in a couple of occasions. Section 2.3.2.2 "All entries MUST point to the mobile node's IPv4 care-of address included=20 in the source address of the IPv6 packet and represented as an IPv4-mapped IPv6 address." Section 4.2 "When the home agent receives the encapsulated binding update it=20 compares the IPv4 address of the source address field in the=20 IPv4 header with the IPv4 address in the source address of the IPv6 header." Was it so that the TLV would never be used in BU/BACK or is it allowed after the initial binding has been created? This could be clarified in section 4.1. Cheers, Markku >-----Original Message----- >From: ext mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org]=20 >Sent: 12 July, 2007 20:16 >To: i-d-announce@ietf.org >Cc: mip6@ietf.org >Subject: [Mip6] I-D ACTION:draft-ietf-mip6-nemo-v4traversal-05.txt=20 > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. >This draft is a work item of the Mobility for IPv6 Working=20 >Group of the IETF. > > Title : Mobile IPv6 support for dual stack=20 >Hosts and Routers (DSMIPv6) > Author(s) : H. Soliman > Filename : draft-ietf-mip6-nemo-v4traversal-05.txt > Pages : 27 > Date : 2007-7-12 >=09 >The current Mobile IPv6 and NEMO specifications support IPv6 only. > This specification extends those standards to allow the registration > of IPv4 addresses and prefixes, respectively, and the transport of > both IPv4 and IPv6 packets over the tunnel to the HA. This > specification also allows the Mobile Node to roam over both IPv6 and > IPv4, including the case where Network Address Translation=20 >is present > on the path between the mobile node and its home agent. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4trav ersal-05.txt > >To remove yourself from the I-D Announcement list, send a=20 >message to i-d-announce-request@ietf.org with the word=20 >unsubscribe in the body of the message.=20 >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > >Internet-Drafts are also available by anonymous FTP. Login=20 >with the username "anonymous" and a password of your e-mail=20 >address. After logging in, type "cd internet-drafts" and then=20 >"get draft-ietf-mip6-nemo-v4traversal-05.txt". > >A list of Internet-Drafts directories can be found in=20 >http://www.ietf.org/shadow.html or=20 >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-mip6-nemo-v4traversal-05.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. > >Below is the data which will enable a MIME compliant mail=20 >reader implementation to automatically retrieve the ASCII=20 >version of the Internet-Draft. > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jul 17 03:54: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 1IAhtF-0005cU-0R; Tue, 17 Jul 2007 03:54:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAhtC-0005bg-DR; Tue, 17 Jul 2007 03:54:34 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAht6-0004FE-AH; Tue, 17 Jul 2007 03:54:33 -0400 Received: from oaamta08sl.mx.bigpond.com ([124.190.104.78]) by omta04sl.mx.bigpond.com with ESMTP id <20070717075425.JWWK4018.omta04sl.mx.bigpond.com@oaamta08sl.mx.bigpond.com>; Tue, 17 Jul 2007 07:54:25 +0000 Received: from PC20005 ([124.190.104.78]) by oaamta08sl.mx.bigpond.com with ESMTP id <20070717075424.FAGD17816.oaamta08sl.mx.bigpond.com@PC20005>; Tue, 17 Jul 2007 07:54:24 +0000 From: "Hesham Soliman" To: Subject: RE: [Mip6] I-D ACTION:draft-ietf-mip6-nemo-v4traversal-05.txt Date: Tue, 17 Jul 2007 17:54:20 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <58357EDC7884E24BAD684C1B2D91F96D05CB6678@trebe101.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfEqGuYgvi1vWtbQM+7XFbbr4Jn0QDlu5SAAAIPcwA= Message-Id: <20070717075424.FAGD17816.oaamta08sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) 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 Markku, It wasn't intentional, I thought I changed them but obviously I missed those two. I'll fix it up i nthe next rev. Thanks, Hesham > -----Original Message----- > From: Markku.Ala-Vannesluoma@nokia.com > [mailto:Markku.Ala-Vannesluoma@nokia.com] > Sent: Tuesday, July 17, 2007 5:48 PM > To: Hesham@elevatemobile.com > Cc: mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] I-D > ACTION:draft-ietf-mip6-nemo-v4traversal-05.txt > > Hi Hesham, > > The new version has the IPv4-mapped IPv6 address text > changed according > to the new IPv4 CoA option except > in a couple of occasions. > > Section 2.3.2.2 > > "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." > > Section 4.2 > > "When the home agent receives the encapsulated binding update it > compares the IPv4 address of the source address field in the > IPv4 header with the IPv4 address in the source address of the IPv6 > header." > > Was it so that the TLV would never be used in BU/BACK or is > it allowed > after the initial binding has been created? This could be > clarified in > section 4.1. > > Cheers, > Markku > > >-----Original Message----- > >From: ext mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] > >Sent: 12 July, 2007 20:16 > >To: i-d-announce@ietf.org > >Cc: mip6@ietf.org > >Subject: [Mip6] I-D ACTION:draft-ietf-mip6-nemo-v4traversal-05.txt > > > >A New Internet-Draft is available from the on-line > >Internet-Drafts directories. > >This draft is a work item of the Mobility for IPv6 Working > >Group of the IETF. > > > > Title : Mobile IPv6 support for dual stack > >Hosts and Routers (DSMIPv6) > > Author(s) : H. Soliman > > Filename : draft-ietf-mip6-nemo-v4traversal-05.txt > > Pages : 27 > > Date : 2007-7-12 > > > >The current Mobile IPv6 and NEMO specifications support IPv6 only. > > This specification extends those standards to allow the > registration > > of IPv4 addresses and prefixes, respectively, and the > transport of > > both IPv4 and IPv6 packets over the tunnel to the HA. This > > specification also allows the Mobile Node to roam over > both IPv6 and > > IPv4, including the case where Network Address Translation > >is present > > on the path between the mobile node and its home agent. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4trav > ersal-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-nemo-v4traversal-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-nemo-v4traversal-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. > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jul 17 15:34: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 1IAsow-0004br-GX; Tue, 17 Jul 2007 15:34:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsov-0004aq-3h for mip6@ietf.org; Tue, 17 Jul 2007 15:34:53 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAsot-0005D6-CC for mip6@ietf.org; Tue, 17 Jul 2007 15:34:53 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLC008YS9224E@usaga01-in.huawei.com> for mip6@ietf.org; Tue, 17 Jul 2007 12:34:50 -0700 (PDT) Received: from N737011 ([10.192.25.70]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLC005OR91YCN@usaga01-in.huawei.com> for mip6@ietf.org; Tue, 17 Jul 2007 12:34:50 -0700 (PDT) Date: Tue, 17 Jul 2007 12:34:45 -0700 From: Madjid Nakhjiri In-reply-to: <469C0421.8010801@azairenet.com> To: 'Vijay Devarapalli' Message-id: <003a01c7c8a9$8850bf90$4619c00a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfIA8ptWcpHqakwSf+AFQMBWnitdwApT+1A X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: mip6@ietf.org Subject: [Mip6] RE: HoA assignment X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Using a cooking analogy instead of your driving one! I do feel like a plumber fixing the kitchen sink without needing to know what is being made in the kitchen:) bottom line is the AAA pipe does need to push down HoAs at some instances, but not prefixes, right? -----Original Message----- From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] Sent: Monday, July 16, 2007 4:50 PM To: Madjid Nakhjiri Cc: mip6@ietf.org Subject: Re: HoA assignment Madjid Nakhjiri wrote: > Hi Vijay, > > Both, I guess. A AAA server managing the prefixes for a home link, IMHO, does not make sense. The home link prefix is associated with a particular home agent (or a set of home agents) that serves the home prefix. The home prefix management should be with the home agents. This prefixes could also change over time. It is sufficient if the mobile node gets to know about the home prefix from the home agent. Having a static home address for the mobile node in the AAA is possible. This would mean that the home prefix for the mobile node is fixed. > Take the case of a fixed user (e.g. a WiMAX DSL replacement) > where the user might always get the same IP address. In this case, she can > get it from AAA. The alternative is if it just get the prefixes. The "alternative" is not complete. > > Now aside from the details, it seems that the bootstrapping doc should > include this option, otherwise the Diameter spec may not provide any > accommodation from transfer of HoA or any parts of it from AAA. The MIP6 WG is still driving the requirements for the DIME extensions, right? ;) Vijay > > R, > > Madjid > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Monday, July 16, 2007 2:03 PM > To: Madjid Nakhjiri > Cc: mip6@ietf.org > Subject: Re: HoA assignment > > Madjid Nakhjiri wrote: >> Question on this draft, I apologize if this has been discussed before. >> >> HoA bootstrapping seems to be done in two ways: >> 1) HoA assignment by HA >> 2) HoA auto-configuration >> >> Can't the HoA be bootstrapped through interaction with the AAA server? > > Need more details. Is the AAA server managing the prefixes for a home > link? Or does the AAA server store a static 128 bit home address for > the mobile node as part of the mobile node's profile? > > Vijay > >> I believe this is an option with many other bootstrapping/AAA interaction >> documents. >> >> Thanks, >> Madjid >> >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: Wednesday, July 11, 2007 9:15 AM >> To: i-d-announce@ietf.org >> Cc: mip6@ietf.org >> Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-split-06.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Mobility for IPv6 Working Group of the >> IETF. >> >> Title : Mobile IPv6 bootstrapping in split scenario >> Author(s) : G. Giaretta, et al. >> Filename : draft-ietf-mip6-bootstrapping-split-06.txt >> Pages : 27 >> Date : 2007-7-11 >> >> A Mobile IPv6 node requires a Home Agent address, a home address, and >> IPsec security associations with its Home Agent before it can start >> utilizing Mobile IPv6 service. RFC 3775 requires that some or all of >> these are statically configured. This document defines how a Mobile >> IPv6 node can bootstrap this information from non-topological >> information and security credentials pre-configured on the Mobile >> Node. The solution defined in this document solves the split >> scenario described in the Mobile IPv6 bootstrapping problem statement >> in RFC 4640. The split scenario refers the case where the Mobile >> Node's mobility service is authorized by a different service provider >> than basic network access. The solution described in this document >> is also generically applicable to any bootstrapping case, since other >> scenarios are more specific realizations of the split scenario. >> >> A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-06.t >> xt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body of >> the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-ietf-mip6-bootstrapping-split-06.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-mip6-bootstrapping-split-06.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jul 17 17:13: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 1IAuLm-0006Rw-Iw; Tue, 17 Jul 2007 17:12:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAuLl-0006Rr-68 for mip6@ietf.org; Tue, 17 Jul 2007 17:12:53 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAuLj-0007nl-FS for mip6@ietf.org; Tue, 17 Jul 2007 17:12:53 -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, 17 Jul 2007 14:12:49 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HoA assignment Thread-Index: AcfIA8ptWcpHqakwSf+AFQMBWnitdwApT+1AAAN/YCA= References: <003a01c7c8a9$8850bf90$4619c00a@china.huawei.com> From: "Vijay Devarapalli" To: "Madjid Nakhjiri" X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: mip6@ietf.org Subject: [Mip6] RE: HoA assignment X-BeenThere: mip6@ietf.org X-Mailman-Version: 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 Madjid, > -----Original Message----- > From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com] > Sent: Tuesday, July 17, 2007 12:35 PM > To: Vijay Devarapalli > Cc: mip6@ietf.org > Subject: RE: HoA assignment >=20 > Using a cooking analogy instead of your driving one! I do feel like a > plumber fixing the kitchen sink without needing to know what is being made > in the kitchen:) Is there a document I should be looking at? > bottom line is the AAA pipe does need to push down HoAs at some instances, > but not prefixes, right? Yes. However, only if there is a static 128-bit home address for the mobile node stored as part of the mobile node's profile. Vijay >=20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Monday, July 16, 2007 4:50 PM > To: Madjid Nakhjiri > Cc: mip6@ietf.org > Subject: Re: HoA assignment >=20 > Madjid Nakhjiri wrote: > > Hi Vijay, > > > > Both, I guess. >=20 > A AAA server managing the prefixes for a home link, IMHO, does not > make sense. The home link prefix is associated with a particular > home agent (or a set of home agents) that serves the home prefix. > The home prefix management should be with the home agents. This > prefixes could also change over time. It is sufficient if the > mobile node gets to know about the home prefix from the home agent. >=20 > Having a static home address for the mobile node in the AAA is > possible. This would mean that the home prefix for the mobile node > is fixed. >=20 > > Take the case of a fixed user (e.g. a WiMAX DSL replacement) > > where the user might always get the same IP address. In this case, she > can > > get it from AAA. The alternative is if it just get the prefixes. >=20 > The "alternative" is not complete. >=20 > > > > Now aside from the details, it seems that the bootstrapping doc should > > include this option, otherwise the Diameter spec may not provide any > > accommodation from transfer of HoA or any parts of it from AAA. >=20 > The MIP6 WG is still driving the requirements for the DIME > extensions, right? ;) >=20 > Vijay >=20 > > > > R, > > > > Madjid > > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > Sent: Monday, July 16, 2007 2:03 PM > > To: Madjid Nakhjiri > > Cc: mip6@ietf.org > > Subject: Re: HoA assignment > > > > Madjid Nakhjiri wrote: > >> Question on this draft, I apologize if this has been discussed before. > >> > >> HoA bootstrapping seems to be done in two ways: > >> 1) HoA assignment by HA > >> 2) HoA auto-configuration > >> > >> Can't the HoA be bootstrapped through interaction with the AAA server? > > > > Need more details. Is the AAA server managing the prefixes for a home > > link? Or does the AAA server store a static 128 bit home address for > > the mobile node as part of the mobile node's profile? > > > > Vijay > > > >> I believe this is an option with many other bootstrapping/AAA > interaction > >> documents. > >> > >> Thanks, > >> Madjid > >> > >> -----Original Message----- > >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >> Sent: Wednesday, July 11, 2007 9:15 AM > >> To: i-d-announce@ietf.org > >> Cc: mip6@ietf.org > >> Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-split-06.txt > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> This draft is a work item of the Mobility for IPv6 Working Group of the > >> IETF. > >> > >> Title : Mobile IPv6 bootstrapping in split scenario > >> Author(s) : G. Giaretta, et al. > >> Filename : draft-ietf-mip6-bootstrapping-split-06.txt > >> Pages : 27 > >> Date : 2007-7-11 > >> > >> A Mobile IPv6 node requires a Home Agent address, a home address, and > >> IPsec security associations with its Home Agent before it can start > >> utilizing Mobile IPv6 service. RFC 3775 requires that some or all > of > >> these are statically configured. This document defines how a Mobile > >> IPv6 node can bootstrap this information from non-topological > >> information and security credentials pre-configured on the Mobile > >> Node. The solution defined in this document solves the split > >> scenario described in the Mobile IPv6 bootstrapping problem > statement > >> in RFC 4640. The split scenario refers the case where the Mobile > >> Node's mobility service is authorized by a different service > provider > >> than basic network access. The solution described in this document > >> is also generically applicable to any bootstrapping case, since > other > >> scenarios are more specific realizations of the split scenario. > >> > >> A URL for this Internet-Draft is: > >> > > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- > 06.t > >> xt > >> > >> To remove yourself from the I-D Announcement list, send a message to > >> i-d-announce-request@ietf.org with the word unsubscribe in the body of > >> the message. > >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > >> to change your subscription settings. > >> > >> Internet-Drafts are also available by anonymous FTP. Login with the > >> username "anonymous" and a password of your e-mail address. After > >> logging in, type "cd internet-drafts" and then > >> "get draft-ietf-mip6-bootstrapping-split-06.txt". > >> > >> A list of Internet-Drafts directories can be found in > >> http://www.ietf.org/shadow.html > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> Internet-Drafts can also be obtained by e-mail. > >> > >> Send a message to: > >> mailserv@ietf.org. > >> In the body type: > >> "FILE /internet-drafts/draft-ietf-mip6-bootstrapping-split-06.txt". > >> > >> NOTE: The mail server at ietf.org can return the document in > >> MIME-encoded form by using the "mpack" utility. To use this > >> feature, insert the command "ENCODING mime" before the "FILE" > >> command. To decode the response(s), you will need "munpack" or > >> a MIME-compliant mail reader. Different MIME-compliant mail readers > >> exhibit different behavior, especially when dealing with > >> "multipart" MIME messages (i.e. documents which have been split > >> up into multiple messages), so check your local documentation on > >> how to manipulate these messages. > >> > >> Below is the data which will enable a MIME compliant mail reader > >> implementation to automatically retrieve the ASCII version of the > >> Internet-Draft. > >> > >> > >> > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jul 18 06:12: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 1IB6Vw-0005Q3-Tc; Wed, 18 Jul 2007 06:12:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB6Vt-0005Hd-7a; Wed, 18 Jul 2007 06:12:09 -0400 Received: from mail1.rz.fhtw-berlin.de ([141.45.5.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IB6Vs-0003VZ-GL; Wed, 18 Jul 2007 06:12:09 -0400 Received: from e178186216.adsl.alicedsl.de ([85.178.186.216] helo=[192.168.178.20]) by mail1.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42 (FreeBSD)) id 1IB6Vr-000Aqc-Kf; Wed, 18 Jul 2007 12:12:07 +0200 Message-ID: <469DE83A.7050107@fhtw-berlin.de> Date: Wed, 18 Jul 2007 12:15:22 +0200 From: Thomas C Schmidt User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: mobopts , mipshop , multimob@ietf.org, sam@irtf.org, Mip6 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Subject: [Mip6] New ID: Multicast Mobility in MIPv6: Problem Statement X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: schmidt@fhtw-berlin.de List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi all, we completed an updated version of the RG ID of the problem statement on extending Multicast to Mobility. It can immediately be downloaded under: http://www.realmv6.org/papers/draft-irtf-mobopts-mmcastv6-ps-01.txt and will be presented in Chicago with sufficient time for discussions http://www3.ietf.org/proceedings/07jul/agenda/MobOpts.txt The document has been significantly extended by * A section on layer 2 aspects as discussed in Prague. This is still somewhat incomplete and we hope for your input! * A brief inclusion of hybrid multicast approaches with a pointer to SAM work. * Many minor extensions, gap filling and clarifications. * An updated and extended bibliography Details: Multicast Mobility in MIPv6: Problem Statement and Brief Survey Abstract In this document we discuss mobility extensions to current IP layer multicast solutions. Problems arising from mobile group communication in general, in the case of multicast listener mobility and for mobile Any Source Multicast as well as Source Specific Multicast senders are documented. Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized. The principal approaches to the multicast mobility problems are outlined subsequently. Looking forward to your hints & discussions! See you in Chicago, thomas _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jul 18 11:53: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 1IBBqN-0000FW-4b; Wed, 18 Jul 2007 11:53:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBBqL-0000FM-BV for mip6@ietf.org; Wed, 18 Jul 2007 11:53:37 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBBqJ-00069Y-OF for mip6@ietf.org; Wed, 18 Jul 2007 11:53:37 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 0FEAA90073 for ; Wed, 18 Jul 2007 11:53:30 -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 02823-05 for ; Wed, 18 Jul 2007 11:53:28 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 18 Jul 2007 11:53:28 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 11:53:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] RE: HoA assignment Date: Wed, 18 Jul 2007 11:53:06 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA307@exchtewks2.starentnetworks.com> In-Reply-To: <005901c7c801$3db7b2c0$4619c00a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: HoA assignment Thread-Index: AcfH7HFGdf/tzHI2QIGffhvt4D3gagAEd2BQAFUEUzA= From: "Chowdhury, Kuntal" To: "Madjid Nakhjiri" , "Vijay Devarapalli" X-OriginalArrivalTime: 18 Jul 2007 15:53:46.0132 (UTC) FILETIME=[D2E94540:01C7C953] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 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 We had this discussion during bootstrapping solution WGLC. The WG consensus was to only do HoA/HNP bootstrapping via the HA. -Kuntal > -----Original Message----- > From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com] > Sent: Monday, July 16, 2007 6:30 PM > To: 'Vijay Devarapalli' > Cc: mip6@ietf.org > Subject: [Mip6] RE: HoA assignment >=20 > Hi Vijay, >=20 > Both, I guess. Take the case of a fixed user (e.g. a WiMAX DSL > replacement) > where the user might always get the same IP address. In this case, she can > get it from AAA. The alternative is if it just get the prefixes. >=20 > Now aside from the details, it seems that the bootstrapping doc should > include this option, otherwise the Diameter spec may not provide any > accommodation from transfer of HoA or any parts of it from AAA. >=20 > R, >=20 > Madjid >=20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Monday, July 16, 2007 2:03 PM > To: Madjid Nakhjiri > Cc: mip6@ietf.org > Subject: Re: HoA assignment >=20 > Madjid Nakhjiri wrote: > > Question on this draft, I apologize if this has been discussed before. > > > > HoA bootstrapping seems to be done in two ways: > > 1) HoA assignment by HA > > 2) HoA auto-configuration > > > > Can't the HoA be bootstrapped through interaction with the AAA server? >=20 > Need more details. Is the AAA server managing the prefixes for a home > link? Or does the AAA server store a static 128 bit home address for > the mobile node as part of the mobile node's profile? >=20 > Vijay >=20 > > I believe this is an option with many other bootstrapping/AAA > interaction > > documents. > > > > Thanks, > > Madjid > > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Wednesday, July 11, 2007 9:15 AM > > To: i-d-announce@ietf.org > > Cc: mip6@ietf.org > > Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-split-06.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Mobility for IPv6 Working Group of the > > IETF. > > > > Title : Mobile IPv6 bootstrapping in split scenario > > Author(s) : G. Giaretta, et al. > > Filename : draft-ietf-mip6-bootstrapping-split-06.txt > > Pages : 27 > > Date : 2007-7-11 > > > > A Mobile IPv6 node requires a Home Agent address, a home address, and > > IPsec security associations with its Home Agent before it can start > > utilizing Mobile IPv6 service. RFC 3775 requires that some or all of > > these are statically configured. This document defines how a Mobile > > IPv6 node can bootstrap this information from non-topological > > information and security credentials pre-configured on the Mobile > > Node. The solution defined in this document solves the split > > scenario described in the Mobile IPv6 bootstrapping problem statement > > in RFC 4640. The split scenario refers the case where the Mobile > > Node's mobility service is authorized by a different service provider > > than basic network access. The solution described in this document > > is also generically applicable to any bootstrapping case, since other > > scenarios are more specific realizations of the split scenario. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- > 06.t > > xt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > > the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then > > "get draft-ietf-mip6-bootstrapping-split-06.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-mip6-bootstrapping-split-06.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jul 18 13:27: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 1IBDIj-0007K5-Jb; Wed, 18 Jul 2007 13:27:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBDIh-0007Jr-Vu for mip6@ietf.org; Wed, 18 Jul 2007 13:27:00 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBDIg-0000Vh-F3 for mip6@ietf.org; Wed, 18 Jul 2007 13:26:59 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLD00H0IXSUBI@usaga01-in.huawei.com> for mip6@ietf.org; Wed, 18 Jul 2007 10:26:54 -0700 (PDT) Received: from N737011 ([10.192.25.70]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLD00C6GXSQ2T@usaga01-in.huawei.com> for mip6@ietf.org; Wed, 18 Jul 2007 10:26:54 -0700 (PDT) Date: Wed, 18 Jul 2007 10:26:50 -0700 From: Madjid Nakhjiri Subject: RE: [Mip6] RE: HoA assignment In-reply-to: <7CCD07160348804497EF29E9EA5560D7024DA307$0001@exchtewks2.starentnetworks.com> To: "'Chowdhury, Kuntal'" , 'Vijay Devarapalli' Message-id: <006601c7c960$d3d4f1e0$4619c00a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfH7HFGdf/tzHI2QIGffhvt4D3gagAEd2BQAFUEUzAAA5eKkA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a 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 Ok, so we don't need to have AVPs carrying HoA/HNP from Diameter server then? -----Original Message----- From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] Sent: Wednesday, July 18, 2007 8:53 AM To: Madjid Nakhjiri; Vijay Devarapalli Cc: mip6@ietf.org Subject: RE: [Mip6] RE: HoA assignment We had this discussion during bootstrapping solution WGLC. The WG consensus was to only do HoA/HNP bootstrapping via the HA. -Kuntal > -----Original Message----- > From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com] > Sent: Monday, July 16, 2007 6:30 PM > To: 'Vijay Devarapalli' > Cc: mip6@ietf.org > Subject: [Mip6] RE: HoA assignment > > Hi Vijay, > > Both, I guess. Take the case of a fixed user (e.g. a WiMAX DSL > replacement) > where the user might always get the same IP address. In this case, she can > get it from AAA. The alternative is if it just get the prefixes. > > Now aside from the details, it seems that the bootstrapping doc should > include this option, otherwise the Diameter spec may not provide any > accommodation from transfer of HoA or any parts of it from AAA. > > R, > > Madjid > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Monday, July 16, 2007 2:03 PM > To: Madjid Nakhjiri > Cc: mip6@ietf.org > Subject: Re: HoA assignment > > Madjid Nakhjiri wrote: > > Question on this draft, I apologize if this has been discussed before. > > > > HoA bootstrapping seems to be done in two ways: > > 1) HoA assignment by HA > > 2) HoA auto-configuration > > > > Can't the HoA be bootstrapped through interaction with the AAA server? > > Need more details. Is the AAA server managing the prefixes for a home > link? Or does the AAA server store a static 128 bit home address for > the mobile node as part of the mobile node's profile? > > Vijay > > > I believe this is an option with many other bootstrapping/AAA > interaction > > documents. > > > > Thanks, > > Madjid > > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Wednesday, July 11, 2007 9:15 AM > > To: i-d-announce@ietf.org > > Cc: mip6@ietf.org > > Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-split-06.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Mobility for IPv6 Working Group of the > > IETF. > > > > Title : Mobile IPv6 bootstrapping in split scenario > > Author(s) : G. Giaretta, et al. > > Filename : draft-ietf-mip6-bootstrapping-split-06.txt > > Pages : 27 > > Date : 2007-7-11 > > > > A Mobile IPv6 node requires a Home Agent address, a home address, and > > IPsec security associations with its Home Agent before it can start > > utilizing Mobile IPv6 service. RFC 3775 requires that some or all of > > these are statically configured. This document defines how a Mobile > > IPv6 node can bootstrap this information from non-topological > > information and security credentials pre-configured on the Mobile > > Node. The solution defined in this document solves the split > > scenario described in the Mobile IPv6 bootstrapping problem statement > > in RFC 4640. The split scenario refers the case where the Mobile > > Node's mobility service is authorized by a different service provider > > than basic network access. The solution described in this document > > is also generically applicable to any bootstrapping case, since other > > scenarios are more specific realizations of the split scenario. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- > 06.t > > xt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > > the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then > > "get draft-ietf-mip6-bootstrapping-split-06.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-mip6-bootstrapping-split-06.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you." _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jul 18 13:34:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBDPe-0001SW-Qi; Wed, 18 Jul 2007 13:34:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBDPd-0001Io-8I for mip6@ietf.org; Wed, 18 Jul 2007 13:34:09 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBDPb-0000il-Kc for mip6@ietf.org; Wed, 18 Jul 2007 13:34:09 -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, 18 Jul 2007 10:34:06 -0700 Message-ID: <469E4F0B.8010407@azairenet.com> Date: Wed, 18 Jul 2007 10:34:03 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Madjid Nakhjiri Subject: Re: [Mip6] RE: HoA assignment References: <006601c7c960$d3d4f1e0$4619c00a@china.huawei.com> In-Reply-To: <006601c7c960$d3d4f1e0$4619c00a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2007 17:34:06.0163 (UTC) FILETIME=[D7211A30:01C7C961] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c 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 Madjid, draft-ietf-mip6-aaa-ha-goals-03 is still the document that lists the requirements for the HA-AAA and NAS-AAA interfaces. I haven't followed the DIME mailing list for a while. The goals document does not require sending a home address or home network prefix from the AAA server. Vijay Madjid Nakhjiri wrote: > Ok, so we don't need to have AVPs carrying HoA/HNP from Diameter server > then? > > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > Sent: Wednesday, July 18, 2007 8:53 AM > To: Madjid Nakhjiri; Vijay Devarapalli > Cc: mip6@ietf.org > Subject: RE: [Mip6] RE: HoA assignment > > We had this discussion during bootstrapping solution WGLC. The WG > consensus was to only do HoA/HNP bootstrapping via the HA. > > -Kuntal > > >> -----Original Message----- >> From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com] >> Sent: Monday, July 16, 2007 6:30 PM >> To: 'Vijay Devarapalli' >> Cc: mip6@ietf.org >> Subject: [Mip6] RE: HoA assignment >> >> Hi Vijay, >> >> Both, I guess. Take the case of a fixed user (e.g. a WiMAX DSL >> replacement) >> where the user might always get the same IP address. In this case, she > can >> get it from AAA. The alternative is if it just get the prefixes. >> >> Now aside from the details, it seems that the bootstrapping doc should >> include this option, otherwise the Diameter spec may not provide any >> accommodation from transfer of HoA or any parts of it from AAA. >> >> R, >> >> Madjid >> >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >> Sent: Monday, July 16, 2007 2:03 PM >> To: Madjid Nakhjiri >> Cc: mip6@ietf.org >> Subject: Re: HoA assignment >> >> Madjid Nakhjiri wrote: >>> Question on this draft, I apologize if this has been discussed > before. >>> HoA bootstrapping seems to be done in two ways: >>> 1) HoA assignment by HA >>> 2) HoA auto-configuration >>> >>> Can't the HoA be bootstrapped through interaction with the AAA > server? >> Need more details. Is the AAA server managing the prefixes for a home >> link? Or does the AAA server store a static 128 bit home address for >> the mobile node as part of the mobile node's profile? >> >> Vijay >> >>> I believe this is an option with many other bootstrapping/AAA >> interaction >>> documents. >>> >>> Thanks, >>> Madjid >>> >>> -----Original Message----- >>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>> Sent: Wednesday, July 11, 2007 9:15 AM >>> To: i-d-announce@ietf.org >>> Cc: mip6@ietf.org >>> Subject: [Mip6] I-D > ACTION:draft-ietf-mip6-bootstrapping-split-06.txt >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Mobility for IPv6 Working Group of > the >>> IETF. >>> >>> Title : Mobile IPv6 bootstrapping in split scenario >>> Author(s) : G. Giaretta, et al. >>> Filename : draft-ietf-mip6-bootstrapping-split-06.txt >>> Pages : 27 >>> Date : 2007-7-11 >>> >>> A Mobile IPv6 node requires a Home Agent address, a home address, > and >>> IPsec security associations with its Home Agent before it can > start >>> utilizing Mobile IPv6 service. RFC 3775 requires that some or > all of >>> these are statically configured. This document defines how a > Mobile >>> IPv6 node can bootstrap this information from non-topological >>> information and security credentials pre-configured on the Mobile >>> Node. The solution defined in this document solves the split >>> scenario described in the Mobile IPv6 bootstrapping problem > statement >>> in RFC 4640. The split scenario refers the case where the Mobile >>> Node's mobility service is authorized by a different service > provider >>> than basic network access. The solution described in this > document >>> is also generically applicable to any bootstrapping case, since > other >>> scenarios are more specific realizations of the split scenario. >>> >>> A URL for this Internet-Draft is: >>> > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- >> 06.t >>> xt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the body > of >>> the message. >>> You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce >>> to change your subscription settings. >>> >>> Internet-Drafts are also available by anonymous FTP. Login with the >>> username "anonymous" and a password of your e-mail address. After >>> logging in, type "cd internet-drafts" and then >>> "get draft-ietf-mip6-bootstrapping-split-06.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE > /internet-drafts/draft-ietf-mip6-bootstrapping-split-06.txt". >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail > readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >> >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > > "This email message and any attachments are confidential information of > Starent Networks, Corp. The information transmitted may not be used to > create or change any contractual obligations of Starent Networks, Corp. Any > review, retransmission, dissemination or other use of, or taking of any > action in reliance upon this e-mail and its attachments by persons or > entities other than the intended recipient is prohibited. If you are not the > intended recipient, please notify the sender immediately -- by replying to > this message or by sending an email to postmaster@starentnetworks.com -- and > destroy all copies of this message and any attachments without reading or > disclosing their contents. Thank you." > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jul 18 13:35: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 1IBDQg-0004KI-77; Wed, 18 Jul 2007 13:35:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBDQe-0004Al-Rq for mip6@ietf.org; Wed, 18 Jul 2007 13:35:12 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBDQd-0000l1-Af for mip6@ietf.org; Wed, 18 Jul 2007 13:35:12 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLD00H19Y6MBI@usaga01-in.huawei.com> for mip6@ietf.org; Wed, 18 Jul 2007 10:35:11 -0700 (PDT) Received: from N737011 ([10.192.25.70]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLD00CMSY6I2T@usaga01-in.huawei.com> for mip6@ietf.org; Wed, 18 Jul 2007 10:35:10 -0700 (PDT) Date: Wed, 18 Jul 2007 10:35:06 -0700 From: Madjid Nakhjiri In-reply-to: To: 'Vijay Devarapalli' Message-id: <006701c7c961$fb7ca890$4619c00a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfIA8ptWcpHqakwSf+AFQMBWnitdwApT+1AAAN/YCAAKqPg8A== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: mip6@ietf.org Subject: [Mip6] RE: HoA assignment X-BeenThere: mip6@ietf.org X-Mailman-Version: 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, There is a doc, but it is work in progress especially on the topic at hand and hence this thread:) http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-04.txt R, Madjid -----Original Message----- From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com] Sent: Tuesday, July 17, 2007 2:13 PM To: Madjid Nakhjiri Cc: mip6@ietf.org Subject: RE: HoA assignment Hi Madjid, > -----Original Message----- > From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com] > Sent: Tuesday, July 17, 2007 12:35 PM > To: Vijay Devarapalli > Cc: mip6@ietf.org > Subject: RE: HoA assignment > > Using a cooking analogy instead of your driving one! I do feel like a > plumber fixing the kitchen sink without needing to know what is being made > in the kitchen:) Is there a document I should be looking at? > bottom line is the AAA pipe does need to push down HoAs at some instances, > but not prefixes, right? Yes. However, only if there is a static 128-bit home address for the mobile node stored as part of the mobile node's profile. Vijay > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Monday, July 16, 2007 4:50 PM > To: Madjid Nakhjiri > Cc: mip6@ietf.org > Subject: Re: HoA assignment > > Madjid Nakhjiri wrote: > > Hi Vijay, > > > > Both, I guess. > > A AAA server managing the prefixes for a home link, IMHO, does not > make sense. The home link prefix is associated with a particular > home agent (or a set of home agents) that serves the home prefix. > The home prefix management should be with the home agents. This > prefixes could also change over time. It is sufficient if the > mobile node gets to know about the home prefix from the home agent. > > Having a static home address for the mobile node in the AAA is > possible. This would mean that the home prefix for the mobile node > is fixed. > > > Take the case of a fixed user (e.g. a WiMAX DSL replacement) > > where the user might always get the same IP address. In this case, she > can > > get it from AAA. The alternative is if it just get the prefixes. > > The "alternative" is not complete. > > > > > Now aside from the details, it seems that the bootstrapping doc should > > include this option, otherwise the Diameter spec may not provide any > > accommodation from transfer of HoA or any parts of it from AAA. > > The MIP6 WG is still driving the requirements for the DIME > extensions, right? ;) > > Vijay > > > > > R, > > > > Madjid > > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > Sent: Monday, July 16, 2007 2:03 PM > > To: Madjid Nakhjiri > > Cc: mip6@ietf.org > > Subject: Re: HoA assignment > > > > Madjid Nakhjiri wrote: > >> Question on this draft, I apologize if this has been discussed before. > >> > >> HoA bootstrapping seems to be done in two ways: > >> 1) HoA assignment by HA > >> 2) HoA auto-configuration > >> > >> Can't the HoA be bootstrapped through interaction with the AAA server? > > > > Need more details. Is the AAA server managing the prefixes for a home > > link? Or does the AAA server store a static 128 bit home address for > > the mobile node as part of the mobile node's profile? > > > > Vijay > > > >> I believe this is an option with many other bootstrapping/AAA > interaction > >> documents. > >> > >> Thanks, > >> Madjid > >> > >> -----Original Message----- > >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >> Sent: Wednesday, July 11, 2007 9:15 AM > >> To: i-d-announce@ietf.org > >> Cc: mip6@ietf.org > >> Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-split-06.txt > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> This draft is a work item of the Mobility for IPv6 Working Group of the > >> IETF. > >> > >> Title : Mobile IPv6 bootstrapping in split scenario > >> Author(s) : G. Giaretta, et al. > >> Filename : draft-ietf-mip6-bootstrapping-split-06.txt > >> Pages : 27 > >> Date : 2007-7-11 > >> > >> A Mobile IPv6 node requires a Home Agent address, a home address, and > >> IPsec security associations with its Home Agent before it can start > >> utilizing Mobile IPv6 service. RFC 3775 requires that some or all > of > >> these are statically configured. This document defines how a Mobile > >> IPv6 node can bootstrap this information from non-topological > >> information and security credentials pre-configured on the Mobile > >> Node. The solution defined in this document solves the split > >> scenario described in the Mobile IPv6 bootstrapping problem > statement > >> in RFC 4640. The split scenario refers the case where the Mobile > >> Node's mobility service is authorized by a different service > provider > >> than basic network access. The solution described in this document > >> is also generically applicable to any bootstrapping case, since > other > >> scenarios are more specific realizations of the split scenario. > >> > >> A URL for this Internet-Draft is: > >> > > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- > 06.t > >> xt > >> > >> To remove yourself from the I-D Announcement list, send a message to > >> i-d-announce-request@ietf.org with the word unsubscribe in the body of > >> the message. > >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > >> to change your subscription settings. > >> > >> Internet-Drafts are also available by anonymous FTP. Login with the > >> username "anonymous" and a password of your e-mail address. After > >> logging in, type "cd internet-drafts" and then > >> "get draft-ietf-mip6-bootstrapping-split-06.txt". > >> > >> A list of Internet-Drafts directories can be found in > >> http://www.ietf.org/shadow.html > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> Internet-Drafts can also be obtained by e-mail. > >> > >> Send a message to: > >> mailserv@ietf.org. > >> In the body type: > >> "FILE /internet-drafts/draft-ietf-mip6-bootstrapping-split-06.txt". > >> > >> NOTE: The mail server at ietf.org can return the document in > >> MIME-encoded form by using the "mpack" utility. To use this > >> feature, insert the command "ENCODING mime" before the "FILE" > >> command. To decode the response(s), you will need "munpack" or > >> a MIME-compliant mail reader. Different MIME-compliant mail readers > >> exhibit different behavior, especially when dealing with > >> "multipart" MIME messages (i.e. documents which have been split > >> up into multiple messages), so check your local documentation on > >> how to manipulate these messages. > >> > >> Below is the data which will enable a MIME compliant mail reader > >> implementation to automatically retrieve the ASCII version of the > >> Internet-Draft. > >> > >> > >> > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jul 18 13:45: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 1IBDac-0008Dd-Ee; Wed, 18 Jul 2007 13:45:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBDab-0008DX-8z for mip6@ietf.org; Wed, 18 Jul 2007 13:45:29 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBDaa-00013j-Ni for mip6@ietf.org; Wed, 18 Jul 2007 13:45:29 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLD00EF2YNSAT@usaga01-in.huawei.com> for mip6@ietf.org; Wed, 18 Jul 2007 10:45:28 -0700 (PDT) Received: from N737011 ([10.192.25.70]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLD00CETYNN2T@usaga01-in.huawei.com> for mip6@ietf.org; Wed, 18 Jul 2007 10:45:28 -0700 (PDT) Date: Wed, 18 Jul 2007 10:45:23 -0700 From: Madjid Nakhjiri Subject: RE: [Mip6] RE: HoA assignment In-reply-to: <469E4F0B.8010407@azairenet.com> To: 'Vijay Devarapalli' Message-id: <006801c7c963$6b003730$4619c00a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfJYaFjNNN8jDHWQKWCU6ioCb3RnQAAUY3w X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 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, If the split case solution does not require HoA bootstrapping, then I am fine. It is just different from V4 I guess. As far as aaa-ha-goals-3, first of all the draft is expired and is not on any of the reflectors, it does not show on MIP6 WG internet draft lists either:) Aside from that this is a requirement document, so I don't expect it talks about specifically what is bootstrapped from AAA, and what attributes are needed, as that would be solution space anyway. For that matter it does not require sending IKE PSK either, does it? Madjid -----Original Message----- From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] Sent: Wednesday, July 18, 2007 10:34 AM To: Madjid Nakhjiri Cc: 'Chowdhury, Kuntal'; mip6@ietf.org Subject: Re: [Mip6] RE: HoA assignment Madjid, draft-ietf-mip6-aaa-ha-goals-03 is still the document that lists the requirements for the HA-AAA and NAS-AAA interfaces. I haven't followed the DIME mailing list for a while. The goals document does not require sending a home address or home network prefix from the AAA server. Vijay Madjid Nakhjiri wrote: > Ok, so we don't need to have AVPs carrying HoA/HNP from Diameter server > then? > > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > Sent: Wednesday, July 18, 2007 8:53 AM > To: Madjid Nakhjiri; Vijay Devarapalli > Cc: mip6@ietf.org > Subject: RE: [Mip6] RE: HoA assignment > > We had this discussion during bootstrapping solution WGLC. The WG > consensus was to only do HoA/HNP bootstrapping via the HA. > > -Kuntal > > >> -----Original Message----- >> From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com] >> Sent: Monday, July 16, 2007 6:30 PM >> To: 'Vijay Devarapalli' >> Cc: mip6@ietf.org >> Subject: [Mip6] RE: HoA assignment >> >> Hi Vijay, >> >> Both, I guess. Take the case of a fixed user (e.g. a WiMAX DSL >> replacement) >> where the user might always get the same IP address. In this case, she > can >> get it from AAA. The alternative is if it just get the prefixes. >> >> Now aside from the details, it seems that the bootstrapping doc should >> include this option, otherwise the Diameter spec may not provide any >> accommodation from transfer of HoA or any parts of it from AAA. >> >> R, >> >> Madjid >> >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >> Sent: Monday, July 16, 2007 2:03 PM >> To: Madjid Nakhjiri >> Cc: mip6@ietf.org >> Subject: Re: HoA assignment >> >> Madjid Nakhjiri wrote: >>> Question on this draft, I apologize if this has been discussed > before. >>> HoA bootstrapping seems to be done in two ways: >>> 1) HoA assignment by HA >>> 2) HoA auto-configuration >>> >>> Can't the HoA be bootstrapped through interaction with the AAA > server? >> Need more details. Is the AAA server managing the prefixes for a home >> link? Or does the AAA server store a static 128 bit home address for >> the mobile node as part of the mobile node's profile? >> >> Vijay >> >>> I believe this is an option with many other bootstrapping/AAA >> interaction >>> documents. >>> >>> Thanks, >>> Madjid >>> >>> -----Original Message----- >>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>> Sent: Wednesday, July 11, 2007 9:15 AM >>> To: i-d-announce@ietf.org >>> Cc: mip6@ietf.org >>> Subject: [Mip6] I-D > ACTION:draft-ietf-mip6-bootstrapping-split-06.txt >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Mobility for IPv6 Working Group of > the >>> IETF. >>> >>> Title : Mobile IPv6 bootstrapping in split scenario >>> Author(s) : G. Giaretta, et al. >>> Filename : draft-ietf-mip6-bootstrapping-split-06.txt >>> Pages : 27 >>> Date : 2007-7-11 >>> >>> A Mobile IPv6 node requires a Home Agent address, a home address, > and >>> IPsec security associations with its Home Agent before it can > start >>> utilizing Mobile IPv6 service. RFC 3775 requires that some or > all of >>> these are statically configured. This document defines how a > Mobile >>> IPv6 node can bootstrap this information from non-topological >>> information and security credentials pre-configured on the Mobile >>> Node. The solution defined in this document solves the split >>> scenario described in the Mobile IPv6 bootstrapping problem > statement >>> in RFC 4640. The split scenario refers the case where the Mobile >>> Node's mobility service is authorized by a different service > provider >>> than basic network access. The solution described in this > document >>> is also generically applicable to any bootstrapping case, since > other >>> scenarios are more specific realizations of the split scenario. >>> >>> A URL for this Internet-Draft is: >>> > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- >> 06.t >>> xt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the body > of >>> the message. >>> You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce >>> to change your subscription settings. >>> >>> Internet-Drafts are also available by anonymous FTP. Login with the >>> username "anonymous" and a password of your e-mail address. After >>> logging in, type "cd internet-drafts" and then >>> "get draft-ietf-mip6-bootstrapping-split-06.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE > /internet-drafts/draft-ietf-mip6-bootstrapping-split-06.txt". >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail > readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >> >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > > "This email message and any attachments are confidential information of > Starent Networks, Corp. The information transmitted may not be used to > create or change any contractual obligations of Starent Networks, Corp. Any > review, retransmission, dissemination or other use of, or taking of any > action in reliance upon this e-mail and its attachments by persons or > entities other than the intended recipient is prohibited. If you are not the > intended recipient, please notify the sender immediately -- by replying to > this message or by sending an email to postmaster@starentnetworks.com -- and > destroy all copies of this message and any attachments without reading or > disclosing their contents. Thank you." > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jul 18 13:49: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 1IBDeU-0003uS-Bo; Wed, 18 Jul 2007 13:49:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBDeS-0003uK-Se for mip6@ietf.org; Wed, 18 Jul 2007 13:49:28 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBDeR-0008TM-NS for mip6@ietf.org; Wed, 18 Jul 2007 13:49:28 -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, 18 Jul 2007 10:49:26 -0700 Message-ID: <469E52A6.6020102@azairenet.com> Date: Wed, 18 Jul 2007 10:49:26 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Madjid Nakhjiri Subject: Re: [Mip6] RE: HoA assignment References: <006801c7c963$6b003730$4619c00a@china.huawei.com> In-Reply-To: <006801c7c963$6b003730$4619c00a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2007 17:49:26.0452 (UTC) FILETIME=[FBAA0F40:01C7C963] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f 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 Madjid Nakhjiri wrote: > Hi Vijay, > > If the split case solution does not require HoA bootstrapping, then I am > fine. It is just different from V4 I guess. > > As far as aaa-ha-goals-3, first of all the draft is expired and is not on > any of the reflectors, it does not show on MIP6 WG internet draft lists > either:) I know. Thats bad. I got it from the tools.ietf.org website. http://tools.ietf.org/wg/mip6/draft-ietf-mip6-aaa-ha-goals/ > Aside from that this is a requirement document, so I don't expect it talks > about specifically what is bootstrapped from AAA, It is a requirements document from defining AAA extensions for MIPv6. It does talk about what is obtained from the AAA server and when. > and what attributes are > needed, as that would be solution space anyway. For that matter it does not > require sending IKE PSK either, does it? Hmm.. if the IKEv2 PSK is stored on the AAA server, then this is required. I think draft-ietf-mip6-aaa-ha-goals missed this. It should be added in the next revision. Vijay > > Madjid > > > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Wednesday, July 18, 2007 10:34 AM > To: Madjid Nakhjiri > Cc: 'Chowdhury, Kuntal'; mip6@ietf.org > Subject: Re: [Mip6] RE: HoA assignment > > Madjid, > > draft-ietf-mip6-aaa-ha-goals-03 is still the document that lists > the requirements for the HA-AAA and NAS-AAA interfaces. I haven't > followed the DIME mailing list for a while. > > The goals document does not require sending a home address or > home network prefix from the AAA server. > > Vijay > > Madjid Nakhjiri wrote: >> Ok, so we don't need to have AVPs carrying HoA/HNP from Diameter server >> then? >> >> -----Original Message----- >> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] >> Sent: Wednesday, July 18, 2007 8:53 AM >> To: Madjid Nakhjiri; Vijay Devarapalli >> Cc: mip6@ietf.org >> Subject: RE: [Mip6] RE: HoA assignment >> >> We had this discussion during bootstrapping solution WGLC. The WG >> consensus was to only do HoA/HNP bootstrapping via the HA. >> >> -Kuntal >> >> >>> -----Original Message----- >>> From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com] >>> Sent: Monday, July 16, 2007 6:30 PM >>> To: 'Vijay Devarapalli' >>> Cc: mip6@ietf.org >>> Subject: [Mip6] RE: HoA assignment >>> >>> Hi Vijay, >>> >>> Both, I guess. Take the case of a fixed user (e.g. a WiMAX DSL >>> replacement) >>> where the user might always get the same IP address. In this case, she >> can >>> get it from AAA. The alternative is if it just get the prefixes. >>> >>> Now aside from the details, it seems that the bootstrapping doc should >>> include this option, otherwise the Diameter spec may not provide any >>> accommodation from transfer of HoA or any parts of it from AAA. >>> >>> R, >>> >>> Madjid >>> >>> -----Original Message----- >>> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >>> Sent: Monday, July 16, 2007 2:03 PM >>> To: Madjid Nakhjiri >>> Cc: mip6@ietf.org >>> Subject: Re: HoA assignment >>> >>> Madjid Nakhjiri wrote: >>>> Question on this draft, I apologize if this has been discussed >> before. >>>> HoA bootstrapping seems to be done in two ways: >>>> 1) HoA assignment by HA >>>> 2) HoA auto-configuration >>>> >>>> Can't the HoA be bootstrapped through interaction with the AAA >> server? >>> Need more details. Is the AAA server managing the prefixes for a home >>> link? Or does the AAA server store a static 128 bit home address for >>> the mobile node as part of the mobile node's profile? >>> >>> Vijay >>> >>>> I believe this is an option with many other bootstrapping/AAA >>> interaction >>>> documents. >>>> >>>> Thanks, >>>> Madjid >>>> >>>> -----Original Message----- >>>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>>> Sent: Wednesday, July 11, 2007 9:15 AM >>>> To: i-d-announce@ietf.org >>>> Cc: mip6@ietf.org >>>> Subject: [Mip6] I-D >> ACTION:draft-ietf-mip6-bootstrapping-split-06.txt >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Mobility for IPv6 Working Group of >> the >>>> IETF. >>>> >>>> Title : Mobile IPv6 bootstrapping in split scenario >>>> Author(s) : G. Giaretta, et al. >>>> Filename : draft-ietf-mip6-bootstrapping-split-06.txt >>>> Pages : 27 >>>> Date : 2007-7-11 >>>> >>>> A Mobile IPv6 node requires a Home Agent address, a home address, >> and >>>> IPsec security associations with its Home Agent before it can >> start >>>> utilizing Mobile IPv6 service. RFC 3775 requires that some or >> all of >>>> these are statically configured. This document defines how a >> Mobile >>>> IPv6 node can bootstrap this information from non-topological >>>> information and security credentials pre-configured on the Mobile >>>> Node. The solution defined in this document solves the split >>>> scenario described in the Mobile IPv6 bootstrapping problem >> statement >>>> in RFC 4640. The split scenario refers the case where the Mobile >>>> Node's mobility service is authorized by a different service >> provider >>>> than basic network access. The solution described in this >> document >>>> is also generically applicable to any bootstrapping case, since >> other >>>> scenarios are more specific realizations of the split scenario. >>>> >>>> A URL for this Internet-Draft is: >>>> >> http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- >>> 06.t >>>> xt >>>> >>>> To remove yourself from the I-D Announcement list, send a message to >>>> i-d-announce-request@ietf.org with the word unsubscribe in the body >> of >>>> the message. >>>> You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce >>>> to change your subscription settings. >>>> >>>> Internet-Drafts are also available by anonymous FTP. Login with the >>>> username "anonymous" and a password of your e-mail address. After >>>> logging in, type "cd internet-drafts" and then >>>> "get draft-ietf-mip6-bootstrapping-split-06.txt". >>>> >>>> A list of Internet-Drafts directories can be found in >>>> http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> Internet-Drafts can also be obtained by e-mail. >>>> >>>> Send a message to: >>>> mailserv@ietf.org. >>>> In the body type: >>>> "FILE >> /internet-drafts/draft-ietf-mip6-bootstrapping-split-06.txt". >>>> NOTE: The mail server at ietf.org can return the document in >>>> MIME-encoded form by using the "mpack" utility. To use this >>>> feature, insert the command "ENCODING mime" before the "FILE" >>>> command. To decode the response(s), you will need "munpack" or >>>> a MIME-compliant mail reader. Different MIME-compliant mail >> readers >>>> exhibit different behavior, especially when dealing with >>>> "multipart" MIME messages (i.e. documents which have been split >>>> up into multiple messages), so check your local documentation on >>>> how to manipulate these messages. >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>> >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >> >> "This email message and any attachments are confidential information of >> Starent Networks, Corp. The information transmitted may not be used to >> create or change any contractual obligations of Starent Networks, Corp. > Any >> review, retransmission, dissemination or other use of, or taking of any >> action in reliance upon this e-mail and its attachments by persons or >> entities other than the intended recipient is prohibited. If you are not > the >> intended recipient, please notify the sender immediately -- by replying to >> this message or by sending an email to postmaster@starentnetworks.com -- > and >> destroy all copies of this message and any attachments without reading or >> disclosing their contents. Thank you." >> >> > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jul 18 14: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 1IBDyp-0005Un-D7; Wed, 18 Jul 2007 14:10:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBDym-0005SY-7a for mip6@ietf.org; Wed, 18 Jul 2007 14:10:29 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBDyl-0001kS-Gs for mip6@ietf.org; Wed, 18 Jul 2007 14:10:28 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLD00E0GZTBAT@usaga01-in.huawei.com> for mip6@ietf.org; Wed, 18 Jul 2007 11:10:23 -0700 (PDT) Received: from N737011 ([10.192.25.70]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLD00CHNZT72T@usaga01-in.huawei.com> for mip6@ietf.org; Wed, 18 Jul 2007 11:10:23 -0700 (PDT) Date: Wed, 18 Jul 2007 11:10:19 -0700 From: Madjid Nakhjiri Subject: RE: [Mip6] RE: HoA assignment In-reply-to: <469E52A6.6020102@azairenet.com> To: 'Vijay Devarapalli' Message-id: <007101c7c966$e6df75c0$4619c00a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfJY8SPVN7hO2UhT8meBo7Ksj/VkgAAdSQQ X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org -----Original Message----- From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] Sent: Wednesday, July 18, 2007 10:49 AM To: Madjid Nakhjiri Cc: 'Chowdhury, Kuntal'; mip6@ietf.org Subject: Re: [Mip6] RE: HoA assignment Madjid Nakhjiri wrote: > Hi Vijay, > > If the split case solution does not require HoA bootstrapping, then I am > fine. It is just different from V4 I guess. > > As far as aaa-ha-goals-3, first of all the draft is expired and is not on > any of the reflectors, it does not show on MIP6 WG internet draft lists > either:) I know. Thats bad. I got it from the tools.ietf.org website. http://tools.ietf.org/wg/mip6/draft-ietf-mip6-aaa-ha-goals/ Madjid>>I had it on files:) > Aside from that this is a requirement document, so I don't expect it talks > about specifically what is bootstrapped from AAA, It is a requirements document from defining AAA extensions for MIPv6. It does talk about what is obtained from the AAA server and when. Madjid>>I look at the overview text on split and don't see much as far as what is coming from AAA. But I don't read that anyway, since I am looking for requirements, which is this document is for, I guess :) and in the requirement section, the general goals only have a bunch of security related goals that pertain to a general AAA protocol, not what is required for bootstrapping stuff out of a AAA server, was that the intent of this doc? > and what attributes are > needed, as that would be solution space anyway. For that matter it does not > require sending IKE PSK either, does it? Hmm.. if the IKEv2 PSK is stored on the AAA server, then this is required. I think draft-ietf-mip6-aaa-ha-goals missed this. It should be added in the next revision. Madjid>>Well, again not sure what the goal of this goal doc is:) I thought it was only requirements out of a AAA interface, not what is needed for a bootstrapping solution. But it seems that you have a section 5.5 discussing the parameters, if the goal is to also show what is coming out of AAA server, then you need to add that requirement. BTW, it seems that G5.1 talks about HoA going from HA to AAA, so probably need an attribute carrying HoA over AAA interface anyway (for DNS updates of HoA through AAA server). Not sure if AAA also needs to send the HoA back to HA as well. Vijay > > Madjid > > > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Wednesday, July 18, 2007 10:34 AM > To: Madjid Nakhjiri > Cc: 'Chowdhury, Kuntal'; mip6@ietf.org > Subject: Re: [Mip6] RE: HoA assignment > > Madjid, > > draft-ietf-mip6-aaa-ha-goals-03 is still the document that lists > the requirements for the HA-AAA and NAS-AAA interfaces. I haven't > followed the DIME mailing list for a while. > > The goals document does not require sending a home address or > home network prefix from the AAA server. > > Vijay > > Madjid Nakhjiri wrote: >> Ok, so we don't need to have AVPs carrying HoA/HNP from Diameter server >> then? >> >> -----Original Message----- >> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] >> Sent: Wednesday, July 18, 2007 8:53 AM >> To: Madjid Nakhjiri; Vijay Devarapalli >> Cc: mip6@ietf.org >> Subject: RE: [Mip6] RE: HoA assignment >> >> We had this discussion during bootstrapping solution WGLC. The WG >> consensus was to only do HoA/HNP bootstrapping via the HA. >> >> -Kuntal >> >> >>> -----Original Message----- >>> From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com] >>> Sent: Monday, July 16, 2007 6:30 PM >>> To: 'Vijay Devarapalli' >>> Cc: mip6@ietf.org >>> Subject: [Mip6] RE: HoA assignment >>> >>> Hi Vijay, >>> >>> Both, I guess. Take the case of a fixed user (e.g. a WiMAX DSL >>> replacement) >>> where the user might always get the same IP address. In this case, she >> can >>> get it from AAA. The alternative is if it just get the prefixes. >>> >>> Now aside from the details, it seems that the bootstrapping doc should >>> include this option, otherwise the Diameter spec may not provide any >>> accommodation from transfer of HoA or any parts of it from AAA. >>> >>> R, >>> >>> Madjid >>> >>> -----Original Message----- >>> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >>> Sent: Monday, July 16, 2007 2:03 PM >>> To: Madjid Nakhjiri >>> Cc: mip6@ietf.org >>> Subject: Re: HoA assignment >>> >>> Madjid Nakhjiri wrote: >>>> Question on this draft, I apologize if this has been discussed >> before. >>>> HoA bootstrapping seems to be done in two ways: >>>> 1) HoA assignment by HA >>>> 2) HoA auto-configuration >>>> >>>> Can't the HoA be bootstrapped through interaction with the AAA >> server? >>> Need more details. Is the AAA server managing the prefixes for a home >>> link? Or does the AAA server store a static 128 bit home address for >>> the mobile node as part of the mobile node's profile? >>> >>> Vijay >>> >>>> I believe this is an option with many other bootstrapping/AAA >>> interaction >>>> documents. >>>> >>>> Thanks, >>>> Madjid >>>> >>>> -----Original Message----- >>>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>>> Sent: Wednesday, July 11, 2007 9:15 AM >>>> To: i-d-announce@ietf.org >>>> Cc: mip6@ietf.org >>>> Subject: [Mip6] I-D >> ACTION:draft-ietf-mip6-bootstrapping-split-06.txt >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Mobility for IPv6 Working Group of >> the >>>> IETF. >>>> >>>> Title : Mobile IPv6 bootstrapping in split scenario >>>> Author(s) : G. Giaretta, et al. >>>> Filename : draft-ietf-mip6-bootstrapping-split-06.txt >>>> Pages : 27 >>>> Date : 2007-7-11 >>>> >>>> A Mobile IPv6 node requires a Home Agent address, a home address, >> and >>>> IPsec security associations with its Home Agent before it can >> start >>>> utilizing Mobile IPv6 service. RFC 3775 requires that some or >> all of >>>> these are statically configured. This document defines how a >> Mobile >>>> IPv6 node can bootstrap this information from non-topological >>>> information and security credentials pre-configured on the Mobile >>>> Node. The solution defined in this document solves the split >>>> scenario described in the Mobile IPv6 bootstrapping problem >> statement >>>> in RFC 4640. The split scenario refers the case where the Mobile >>>> Node's mobility service is authorized by a different service >> provider >>>> than basic network access. The solution described in this >> document >>>> is also generically applicable to any bootstrapping case, since >> other >>>> scenarios are more specific realizations of the split scenario. >>>> >>>> A URL for this Internet-Draft is: >>>> >> http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- >>> 06.t >>>> xt >>>> >>>> To remove yourself from the I-D Announcement list, send a message to >>>> i-d-announce-request@ietf.org with the word unsubscribe in the body >> of >>>> the message. >>>> You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce >>>> to change your subscription settings. >>>> >>>> Internet-Drafts are also available by anonymous FTP. Login with the >>>> username "anonymous" and a password of your e-mail address. After >>>> logging in, type "cd internet-drafts" and then >>>> "get draft-ietf-mip6-bootstrapping-split-06.txt". >>>> >>>> A list of Internet-Drafts directories can be found in >>>> http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> Internet-Drafts can also be obtained by e-mail. >>>> >>>> Send a message to: >>>> mailserv@ietf.org. >>>> In the body type: >>>> "FILE >> /internet-drafts/draft-ietf-mip6-bootstrapping-split-06.txt". >>>> NOTE: The mail server at ietf.org can return the document in >>>> MIME-encoded form by using the "mpack" utility. To use this >>>> feature, insert the command "ENCODING mime" before the "FILE" >>>> command. To decode the response(s), you will need "munpack" or >>>> a MIME-compliant mail reader. Different MIME-compliant mail >> readers >>>> exhibit different behavior, especially when dealing with >>>> "multipart" MIME messages (i.e. documents which have been split >>>> up into multiple messages), so check your local documentation on >>>> how to manipulate these messages. >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>> >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >> >> "This email message and any attachments are confidential information of >> Starent Networks, Corp. The information transmitted may not be used to >> create or change any contractual obligations of Starent Networks, Corp. > Any >> review, retransmission, dissemination or other use of, or taking of any >> action in reliance upon this e-mail and its attachments by persons or >> entities other than the intended recipient is prohibited. If you are not > the >> intended recipient, please notify the sender immediately -- by replying to >> this message or by sending an email to postmaster@starentnetworks.com -- > and >> destroy all copies of this message and any attachments without reading or >> disclosing their contents. Thank you." >> >> > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mext-bounces@ietf.org Sat Jul 21 16:35: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 1ICLfI-00028r-FC; Sat, 21 Jul 2007 16:35:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICLfH-00028m-Qn for mext@ietf.org; Sat, 21 Jul 2007 16:34:59 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICLfG-00084f-D7 for mext@ietf.org; Sat, 21 Jul 2007 16:34:59 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 034DE19867D for ; Sat, 21 Jul 2007 23:34:57 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7B709198667 for ; Sat, 21 Jul 2007 23:34:56 +0300 (EEST) Message-ID: <46A26DF0.6000108@piuha.net> Date: Sat, 21 Jul 2007 15:34:56 -0500 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: 7d33c50f3756db14428398e2bdedd581 Subject: [MEXT] Status of MEXT WG and chairs 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 Folks, This is a status update about the merged working group. The IESG has approved the charter pending a few edits from me (Sam's issue among other things). However, I have run out of time to get the WG setup before this meeting. The one thing missing is deciding who the chairs are. As a result, I have asked the current chairs to run the three slots we have in IETF-69. I also plan to use the week to talk to the potential candidates for chairs, from both the set of current chairs as well as new candidates. I have a some names in mind and some have contacted me about this. If there is anyone who feels they are interested, please contact me so that we can talk during the week. I plan to make the decision right after the IETF. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Jul 21 16:37: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 1ICLi7-0003fe-QZ; Sat, 21 Jul 2007 16:37:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICLi6-0003cM-Pw for mext@ietf.org; Sat, 21 Jul 2007 16:37:54 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICLi6-00089o-GS for mext@ietf.org; Sat, 21 Jul 2007 16:37:54 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E213919867D; Sat, 21 Jul 2007 23:37:53 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 11513198667; Sat, 21 Jul 2007 23:37:52 +0300 (EEST) Message-ID: <46A26EA0.4010804@piuha.net> Date: Sat, 21 Jul 2007 15:37:52 -0500 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Jean-Michel Combes Subject: Re: [MEXT] new charter version References: <84929.44768.qm@web84106.mail.mud.yahoo.com> <729b68be0707020546i27e6f377s2f60b9ec1032582f@mail.gmail.com> In-Reply-To: <729b68be0707020546i27e6f377s2f60b9ec1032582f@mail.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 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 If we still need to do the WGLC, I think we should include the item in the charter. Jari Jean-Michel Combes kirjoitti: > Hi Behcet, > > 2007/6/30, Behcet Sarikaya : >> >> 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. > > IMHO, I am not so sure. That depends whether you want, concerning the > IPsec failover, a MIP6 WG based solution or a general one (i.e. IFare > work) included the draft. > >> >> Kind regards, >> >> Behcet >> > > [snip] > > Best regards. > > JMC. > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Jul 21 17: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 1ICMqB-0007ez-Mx; Sat, 21 Jul 2007 17:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICMqB-0007ep-1A for mext@ietf.org; Sat, 21 Jul 2007 17:50:19 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICMq9-0001Iv-Jm for mext@ietf.org; Sat, 21 Jul 2007 17:50:19 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 29AAB19867D; Sun, 22 Jul 2007 00:50:16 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id CCBF21985FB; Sun, 22 Jul 2007 00:50:14 +0300 (EEST) Message-ID: <46A27F96.1030005@piuha.net> Date: Sat, 21 Jul 2007 16:50:14 -0500 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: weddy@grc.nasa.gov Subject: Re: [MEXT] new charter version References: <84929.44768.qm@web84106.mail.mud.yahoo.com> <729b68be0707020546i27e6f377s2f60b9ec1032582f@mail.gmail.com> <20070702130627.GD6234@grc.nasa.gov> In-Reply-To: <20070702130627.GD6234@grc.nasa.gov> 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: 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 Wesley, > I agree. When I read it last, it seemed like to meet all of its stated > capabilities, the HA reliability work would need to block on the IFARE > work, but perhaps it was just unclear and my understanding was wrong. > Other than this part, it did seem mostly complete to me. Specifically, > there didn't seem to be detailed enough information on the IPsec state > synchronization mechanism within the hareliability draft itself to > implement both interoperable, and fully-functional solutions. > The IPsec sync is outside the charter. The next revision of the charter text tries to make this clear (and at the same time address the issue that Sam raised). (But its another question of whether the WG wants to normatively refer to an IPsec sync specification. If so, at this time they would be referring to work that has not even been chartered yet, so you'd want to be careful that you don't insert such a dependency lightly.) Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Jul 22 18:57: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 1ICkMP-0002yX-Tn; Sun, 22 Jul 2007 18:57:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICkMP-0002yR-9R for mext@ietf.org; Sun, 22 Jul 2007 18:57:09 -0400 Received: from py-out-1112.google.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICkMO-0006je-TY for mext@ietf.org; Sun, 22 Jul 2007 18:57:09 -0400 Received: by py-out-1112.google.com with SMTP id f31so4908326pyh for ; Sun, 22 Jul 2007 15:57:08 -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=bGHB2cEnv4U0wpPbX+3eCuIorLRnl0/mxMhf5hz1iYoy5yCFYIAdJ6ubamc6eFs9h0axqgZlVdYNocjfl305D37UwSR914Y3QXLOUdWdKVvoJKo6V/U7SqLREl3gXSfp9vN4LjIz1oO2g3/CZPa/yzgFNxRqqa2KswYNVO6kT2c= 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=JPSF+mUMAF7gVnQ4BKsGbvd0blb5RpYUXwoWaknDRmQHXV1R6J9mKxo2ZTwvLNwa6EWUGKoEUbI0dm7LjfSS8OFEBkvup2Q9TUZsrM7+ieIL38aHlYQ7aNjb038kyw3nqQSKwCwlySIVxZURnFUCa4sgN0dwm/TOU3O9/OfL2kw= Received: by 10.35.14.18 with SMTP id r18mr4856656pyi.1185145028327; Sun, 22 Jul 2007 15:57:08 -0700 (PDT) Received: from ?172.28.170.128? ( [67.97.210.2]) by mx.google.com with ESMTPS id x72sm5684761pyg.2007.07.22.15.57.07 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Jul 2007 15:57:07 -0700 (PDT) In-Reply-To: <729b68be0707020546i27e6f377s2f60b9ec1032582f@mail.gmail.com> References: <84929.44768.qm@web84106.mail.mud.yahoo.com> <729b68be0707020546i27e6f377s2f60b9ec1032582f@mail.gmail.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: [MEXT] new charter version Date: Mon, 23 Jul 2007 07:57:00 +0900 To: Jean-Michel Combes X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Jean-Michel On 2007/07/02, at 21:46, Jean-Michel Combes wrote: > Hi Behcet, > > 2007/6/30, Behcet Sarikaya : >> >> 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. > > IMHO, I am not so sure. That depends whether you want, concerning the > IPsec failover, a MIP6 WG based solution or a general one (i.e. IFare > work) included the draft. IPsec failover is assumed only for the HA virtual switch case. There is no mechanism available so far in IETF. And we don't think the MIP6 WG is the right place to specify the ipsec failover. We already had consensus on this point in MIP6 WG. As soon as solution(IFARE?) are available, we can update the HA reliability to support that. regards, ryuji >> >> Kind regards, >> >> Behcet >> > > [snip] > > Best regards. > > JMC. > > _______________________________________________ > 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 mext-bounces@ietf.org Sun Jul 22 21: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 1ICnD7-0005n1-M5; Sun, 22 Jul 2007 21:59:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICnD5-0005li-7q for mext@ietf.org; Sun, 22 Jul 2007 21:59:43 -0400 Received: from static-ip-174-194-65-202.rev.dyxnet.com ([202.65.194.174] helo=hitachihk8.hitachi.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICnD2-0001Gi-OA for mext@ietf.org; Sun, 22 Jul 2007 21:59:43 -0400 Received: (qmail 25767 invoked from network); 23 Jul 2007 01:59:36 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk8;1818b4ef6a0190b21cfdc55dfdb91e8b; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1) by 170.95.94.11 with SMTP; 23 Jul 2007 01:59:35 -0000 Received: (qmail 11176 invoked from network); 23 Jul 2007 01:59:30 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;c28b2feb752d8bd5032571a78a84e3af; Received: from hchidc401.hitachi-china.com (HELO hchidc401.hitachi.cn) (170.95.94.69) by 172.16.10.9 with SMTP; 23 Jul 2007 01:59:30 -0000 Received: from hchidc204.hitachi.cn ([170.95.82.6]) by hchidc401.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 09:48:27 +0800 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 09:48:26 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [MEXT] new charter version Date: Mon, 23 Jul 2007 09:48:24 +0800 Message-ID: <8386EDF347730C46BA47710F87AE1FE9303B73@hcbjdc2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] new charter version Thread-Index: AcfMtF+/aTW6+bguTHK3IMLW4kKsbAAFr41T From: "DENG, HUI -HCHBJ" To: "RYUJI WAKIKAWA" , "Jean-Michel Combes" , X-OriginalArrivalTime: 23 Jul 2007 01:48:26.0183 (UTC) FILETIME=[8F87FD70:01C7CCCB] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1185155970.261-11163-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.07/0.51 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Scanned-By-hitachihk8: Virus scan performed by network-box X-Scanned-By-hitachihk8: Scanner file id is hitachihk8-1185155976.260-25742-000 X-Scanned-By-hitachihk8: No known viruses found in message (received+scanned in 0.05/0.08 secs) X-Scanned-By-hitachihk8: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk8: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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: , Content-Type: multipart/mixed; boundary="===============1002655154==" Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1002655154== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CCCB.8E8CF40E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CCCB.8E8CF40E Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 TWF5IEkgIGNvbmZvcm0gb25lIHRoaW5nIGhlcmU6IChwbGVhc2UgYWxsb3cgbWUgY2MgaWZhcmUp DQpJRkFSRSB3aWxsIGNvbnNpZGVyIGRpZmZlcmVudCBJUCBhZGRyZXNzIGZvciBHVywgaXMgdGhp cyBjb3JyZWN0Pw0KaWYgdGhpcyBpcyB0cnVlICwgaXQgbWF5IG5vdCBzeW5jIHdpdGggdmlydHVh bCBzd2l0Y2htb2RlLg0KIA0KLUh1aQ0KIA0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0g DQoJRnJvbTogUllVSkkgV0FLSUtBV0EgW21haWx0bzpyeXVqaS53YWtpa2F3YUBnbWFpbC5jb21d IA0KCVNlbnQ6IDIwMDctNy0yMyAo5pif5pyf5LiAKSA2OjU3IA0KCVRvOiBKZWFuLU1pY2hlbCBD b21iZXMgDQoJQ2M6IG1leHRAaWV0Zi5vcmcgDQoJU3ViamVjdDogUmU6IFtNRVhUXSBuZXcgY2hh cnRlciB2ZXJzaW9uDQoJDQoJDQoNCglIaSBKZWFuLU1pY2hlbA0KCQ0KCU9uIDIwMDcvMDcvMDIs IGF0IDIxOjQ2LCBKZWFuLU1pY2hlbCBDb21iZXMgd3JvdGU6DQoJDQoJPiBIaSBCZWhjZXQsDQoJ Pg0KCT4gMjAwNy82LzMwLCBCZWhjZXQgU2FyaWtheWEgPGJlaGNldHNhcmlrYXlhQHlhaG9vLmNv bT46DQoJPj4NCgk+PiBIaSBKYXJpLA0KCT4+ICAgSW4gZmFjdCBIQSByZWxpYWJpbGl0eSB3b3Jr IGlzIGFsbW9zdCBvdmVyLiBJIHRoaW5rIHRoZSBjdXJyZW50IA0KCT4+IGRyYWZ0IGlzDQoJPj4g ZXhwZWN0ZWQgdG8gZ28gZm9yIFdHTEMgc29vbiBhbmQgdGhlIHN1YnRlYW0gaXMgYWxtb3N0IGNs b3NlZC4gSSANCgk+PiBkb24ndCB0aGluaw0KCT4+IGl0IHdvdWxkIHRha2UgQXVnIDA4IHRvIGNv bXBsZXRlIHRoaXMgd29yay4gSEEgcmVsaWFiaWxpdHkgY291bGQgYmUNCgk+PiBjb21wbGV0ZWx5 IHJlbW92ZWQgZnJvbSB0aGlzIGNoYXJ0ZXIuDQoJPg0KCT4gSU1ITywgSSBhbSBub3Qgc28gc3Vy ZS4gVGhhdCBkZXBlbmRzIHdoZXRoZXIgeW91IHdhbnQsIGNvbmNlcm5pbmcgdGhlDQoJPiBJUHNl YyBmYWlsb3ZlciwgYSBNSVA2IFdHIGJhc2VkIHNvbHV0aW9uIG9yIGEgZ2VuZXJhbCBvbmUgKGku ZS4gSUZhcmUNCgk+IHdvcmspIGluY2x1ZGVkIHRoZSBkcmFmdC4NCgkNCglJUHNlYyBmYWlsb3Zl ciBpcyBhc3N1bWVkIG9ubHkgZm9yIHRoZSBIQSB2aXJ0dWFsIHN3aXRjaCBjYXNlLg0KCVRoZXJl IGlzIG5vIG1lY2hhbmlzbSBhdmFpbGFibGUgc28gZmFyIGluIElFVEYuDQoJQW5kIHdlIGRvbid0 IHRoaW5rIHRoZSBNSVA2IFdHIGlzIHRoZSByaWdodCBwbGFjZSB0byBzcGVjaWZ5IHRoZSANCglp cHNlYyBmYWlsb3Zlci4NCglXZSBhbHJlYWR5IGhhZCBjb25zZW5zdXMgb24gdGhpcyBwb2ludCBp biBNSVA2IFdHLg0KCUFzIHNvb24gYXMgc29sdXRpb24oSUZBUkU/KSBhcmUgYXZhaWxhYmxlLCB3 ZSBjYW4gdXBkYXRlIHRoZSBIQSANCglyZWxpYWJpbGl0eSB0byBzdXBwb3J0IHRoYXQuDQoJDQoJ cmVnYXJkcywNCglyeXVqaQ0KCQ0KCQ0KCT4+DQoJPj4gS2luZCByZWdhcmRzLA0KCT4+DQoJPj4g QmVoY2V0DQoJPj4NCgk+DQoJPiBbc25pcF0NCgk+DQoJPiBCZXN0IHJlZ2FyZHMuDQoJPg0KCT4g Sk1DLg0KCT4NCgk+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoJPiBNRVhUIG1haWxpbmcgbGlzdA0KCT4gTUVYVEBpZXRmLm9yZw0KCT4gaHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4dA0KCQ0KCQ0KCV9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJTUVYVCBtYWlsaW5nIGxpc3QNCglN RVhUQGlldGYub3JnDQoJaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4 dA0KCQ0KDQo= ------_=_NextPart_001_01C7CCCB.8E8CF40E Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjY2MDMuMCI+CjxUSVRMRT5SZTogW01FWFRdIG5ldyBj aGFydGVyIHZlcnNpb248L1RJVExFPgo8L0hFQUQ+CjxCT0RZIGRpcj1sdHI+CjxESVY+TWF5IEkm bmJzcDsgY29uZm9ybSBvbmUgdGhpbmcgaGVyZTogKHBsZWFzZSBhbGxvdyBtZSBjYyBpZmFyZSk8 L0RJVj4KPERJVj5JRkFSRSB3aWxsIGNvbnNpZGVyIGRpZmZlcmVudCBJUCBhZGRyZXNzIGZvciBH VywgaXMgdGhpcyBjb3JyZWN0PzwvRElWPgo8RElWPmlmIHRoaXMgaXMgdHJ1ZSAsIGl0IG1heSZu YnNwO25vdCBzeW5jIHdpdGgmbmJzcDt2aXJ0dWFsIHN3aXRjaG1vZGUuPC9ESVY+CjxESVY+Jm5i c3A7PC9ESVY+CjxESVY+LUh1aTwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8QkxPQ0tRVU9URSBk aXI9bHRyIHN0eWxlPSJNQVJHSU4tUklHSFQ6IDBweCI+CiAgPERJVj48Rk9OVCBzaXplPTI+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gPEJSPjxCPkZyb206PC9CPiBSWVVKSSBXQUtJS0FXQSAK ICBbbWFpbHRvOnJ5dWppLndha2lrYXdhQGdtYWlsLmNvbV0gPEJSPjxCPlNlbnQ6PC9CPiAyMDA3 LTctMjMgKOaYn+acn+S4gCkgNjo1NyAKICA8QlI+PEI+VG86PC9CPiBKZWFuLU1pY2hlbCBDb21i ZXMgPEJSPjxCPkNjOjwvQj4gbWV4dEBpZXRmLm9yZyAKICA8QlI+PEI+U3ViamVjdDo8L0I+IFJl OiBbTUVYVF0gbmV3IGNoYXJ0ZXIgdmVyc2lvbjxCUj48QlI+PC9GT05UPjwvRElWPgogIDxQPjxG T05UIHNpemU9Mj5IaSBKZWFuLU1pY2hlbDxCUj48QlI+T24gMjAwNy8wNy8wMiwgYXQgMjE6NDYs IEplYW4tTWljaGVsIAogIENvbWJlcyB3cm90ZTo8QlI+PEJSPiZndDsgSGkgQmVoY2V0LDxCUj4m Z3Q7PEJSPiZndDsgMjAwNy82LzMwLCBCZWhjZXQgCiAgU2FyaWtheWEgJmx0O2JlaGNldHNhcmlr YXlhQHlhaG9vLmNvbSZndDs6PEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7IEhpIAogIEphcmksPEJS PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IEluIGZhY3QgSEEgcmVsaWFiaWxpdHkgd29yayBpcyBhbG1v c3Qgb3Zlci4gSSAKICB0aGluayB0aGUgY3VycmVudCZuYnNwOzxCUj4mZ3Q7Jmd0OyBkcmFmdCBp czxCUj4mZ3Q7Jmd0OyBleHBlY3RlZCB0byBnbyBmb3IgCiAgV0dMQyBzb29uIGFuZCB0aGUgc3Vi dGVhbSBpcyBhbG1vc3QgY2xvc2VkLiBJJm5ic3A7PEJSPiZndDsmZ3Q7IGRvbid0IAogIHRoaW5r PEJSPiZndDsmZ3Q7IGl0IHdvdWxkIHRha2UgQXVnIDA4IHRvIGNvbXBsZXRlIHRoaXMgd29yay4g SEEgcmVsaWFiaWxpdHkgCiAgY291bGQgYmU8QlI+Jmd0OyZndDsgY29tcGxldGVseSByZW1vdmVk IGZyb20gdGhpcyBjaGFydGVyLjxCUj4mZ3Q7PEJSPiZndDsgCiAgSU1ITywgSSBhbSBub3Qgc28g c3VyZS4gVGhhdCBkZXBlbmRzIHdoZXRoZXIgeW91IHdhbnQsIGNvbmNlcm5pbmcgdGhlPEJSPiZn dDsgCiAgSVBzZWMgZmFpbG92ZXIsIGEgTUlQNiBXRyBiYXNlZCBzb2x1dGlvbiBvciBhIGdlbmVy YWwgb25lIChpLmUuIElGYXJlPEJSPiZndDsgCiAgd29yaykgaW5jbHVkZWQgdGhlIGRyYWZ0LjxC Uj48QlI+SVBzZWMgZmFpbG92ZXIgaXMgYXNzdW1lZCBvbmx5IGZvciB0aGUgSEEgCiAgdmlydHVh bCBzd2l0Y2ggY2FzZS48QlI+VGhlcmUgaXMgbm8gbWVjaGFuaXNtIGF2YWlsYWJsZSBzbyBmYXIg aW4gSUVURi48QlI+QW5kIAogIHdlIGRvbid0IHRoaW5rIHRoZSBNSVA2IFdHIGlzIHRoZSByaWdo dCBwbGFjZSB0byBzcGVjaWZ5IHRoZSZuYnNwOzxCUj5pcHNlYyAKICBmYWlsb3Zlci48QlI+V2Ug YWxyZWFkeSBoYWQgY29uc2Vuc3VzIG9uIHRoaXMgcG9pbnQgaW4gTUlQNiBXRy48QlI+QXMgc29v biBhcyAKICBzb2x1dGlvbihJRkFSRT8pIGFyZSBhdmFpbGFibGUsIHdlIGNhbiB1cGRhdGUgdGhl IEhBJm5ic3A7PEJSPnJlbGlhYmlsaXR5IHRvIAogIHN1cHBvcnQgdGhhdC48QlI+PEJSPnJlZ2Fy ZHMsPEJSPnJ5dWppPEJSPjxCUj48QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDsgS2luZCAKICByZWdh cmRzLDxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBCZWhjZXQ8QlI+Jmd0OyZndDs8QlI+Jmd0OzxC Uj4mZ3Q7IAogIFtzbmlwXTxCUj4mZ3Q7PEJSPiZndDsgQmVzdCByZWdhcmRzLjxCUj4mZ3Q7PEJS PiZndDsgSk1DLjxCUj4mZ3Q7PEJSPiZndDsgCiAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyBNRVhUIG1haWxpbmcgCiAgbGlzdDxCUj4mZ3Q7 IE1FWFRAaWV0Zi5vcmc8QlI+Jmd0OyA8QSAKICBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tZXh0Ij5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tZXh0PC9BPjxCUj48QlI+PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPEJSPk1FWFQgCiAgbWFpbGluZyBsaXN0PEJSPk1FWFRAaWV0Zi5vcmc8 QlI+PEEgCiAgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4 dCI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4dDwvQT48QlI+PC9G T05UPjwvUD48L0JMT0NLUVVPVEU+Cgo8L0JPRFk+CjwvSFRNTD4= ------_=_NextPart_001_01C7CCCB.8E8CF40E-- --===============1002655154== 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 --===============1002655154==-- From mext-bounces@ietf.org Tue Jul 24 11:09: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 1IDM0i-0000tU-0S; Tue, 24 Jul 2007 11:09:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDM0h-0000tF-6h for mext@ietf.org; Tue, 24 Jul 2007 11:09:15 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDM0g-0004MO-Rt for mext@ietf.org; Tue, 24 Jul 2007 11:09:15 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 16B8D198683; Tue, 24 Jul 2007 18:09:14 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3B405198667; Tue, 24 Jul 2007 18:09:13 +0300 (EEST) Message-ID: <46A6160B.8000309@piuha.net> Date: Tue, 24 Jul 2007 10:08:59 -0500 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "DENG, HUI -HCHBJ" Subject: Re: [MEXT] new charter version References: <8386EDF347730C46BA47710F87AE1FE9303B73@hcbjdc2> In-Reply-To: <8386EDF347730C46BA47710F87AE1FE9303B73@hcbjdc2> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 Hui, > May I conform one thing here: (please allow me cc ifare) > IFARE will consider different IP address for GW, is this correct? I think that was the goal of IFARE. Then again, we don't have an IFARE WG at the moment, so we are speculating. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mip6-bounces@ietf.org Tue Jul 24 12: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 1IDN2k-0003K7-OQ; Tue, 24 Jul 2007 12:15:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDN2O-0002hK-Ae; Tue, 24 Jul 2007 12:15:04 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDN2N-0006UH-Rx; Tue, 24 Jul 2007 12:15:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 76306175F6; Tue, 24 Jul 2007 16:15:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IDN2M-0005WP-O6; Tue, 24 Jul 2007 12:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 24 Jul 2007 12:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-hareliability-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 : Home Agent Reliability Protocol Author(s) : R. Wakikawa Filename : draft-ietf-mip6-hareliability-02.txt Pages : 45 Date : 2007-7-24 The home agent can be a single point of failure when Mobile IPv6 is used in a system. It is critical to provide home agent reliability in the event of a home agent crashing or becoming unavailable. This would allow another home agent to take over and continue providing service to the mobile nodes. This document describes the problem scope briefly and provides a mechanism of home agent failure detection, home agent state transfer, and home agent switching for home agent redundancy and reliability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-hareliability-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-hareliability-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-hareliability-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-7-24115510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-hareliability-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-hareliability-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-24115510.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 mext-bounces@ietf.org Tue Jul 24 12:27: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 1IDNEG-0003t5-5j; Tue, 24 Jul 2007 12:27:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDN74-0000Dn-62 for mext@ietf.org; Tue, 24 Jul 2007 12:19:54 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDN6t-0007U1-9P for mext@ietf.org; Tue, 24 Jul 2007 12:19:53 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A8EED198680 for ; Tue, 24 Jul 2007 19:19:41 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id AB4AD19867D for ; Tue, 24 Jul 2007 19:19:40 +0300 (EEST) Message-ID: <46A6268E.2020003@piuha.net> Date: Tue, 24 Jul 2007 11:19:26 -0500 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: f1405b5eaa25d745f8c52e3273d3af78 Subject: [MEXT] charter - final 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 I believe this version has all the edits that I needed to get in. Sam was OK with this as well. ---- 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) mechanisms to support high-availability home agents, (A.3) allowing the use of multiple interfaces in mobile nodes, (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). The group employs IPsec and IKE as a security mechanism. The group shall refrain, however, from making generic extensions to these protocols. Any proposed extension must be reviewed by the ADs before it can be accepted as a part of a work item. 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 2008 Submit final doc on Route Optimization Needs for Automobile and Highway Deployments, for Informational Jan 2008 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 2008 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 2008 Submit Multiple Interfaces Motivations and Scenario to IESG, for Informational Jul 2008 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 mext-bounces@ietf.org Tue Jul 24 13:51: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 1IDOXZ-0006qY-Dl; Tue, 24 Jul 2007 13:51:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDOXX-0006qL-VQ for mext@ietf.org; Tue, 24 Jul 2007 13:51:19 -0400 Received: from [2001:660:7301:3192:211:43ff:fea3:7e4b] (helo=laposte.rennes.enst-bretagne.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDOXV-00075h-1K for mext@ietf.org; Tue, 24 Jul 2007 13:51:19 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.7/8.13.7/2006.08.14) with ESMTP id l6OHpCWa002234; Tue, 24 Jul 2007 19:51:12 +0200 Received: from l2.rennes.enst-bretagne.fr (l2.rennes.enst-bretagne.fr [192.44.77.4]) by laposte.rennes.enst-bretagne.fr (8.13.7/8.13.7/2007.03.20) with ESMTP id l6OHp7ih002225; Tue, 24 Jul 2007 19:51:07 +0200 Received: from [130.129.21.215] (dhcp-15d7.ietf69.org [130.129.21.215]) (authenticated bits=0) by l2.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id l6OHp5Td028645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jul 2007 19:51:06 +0200 Message-ID: <46A63C07.6080505@enst-bretagne.fr> Date: Tue, 24 Jul 2007 19:51:03 +0200 From: Nicolas Montavont User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [MEXT] new charter version References: <8386EDF347730C46BA47710F87AE1FE9303B73@hcbjdc2> <46A6160B.8000309@piuha.net> In-Reply-To: <46A6160B.8000309@piuha.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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 and all, I am sorry I should have commented the charter earlier, but here are some thoughts. We will take some time at the monami6 meeting on Wednesday to discuss those. - I was wondering how multiple HA addresses is linked to multiple home addresses allocated to mobile hosts. When talking about multiple interfaces (item A.3), the charter mainly talks about multiple CoAs and multiple HA addresses. However, in the current documents that we have in the Monami6 WG, we focus more on multiple CoAs and multiple HoAs. For example, the current working group document draft-ietf-monami6-multiplecoa-03.txt proposes a mechanism to bind multiple CoAs to a single HoA, not a single HA address as written in the MEXT charter ("A protocol extension to support the registration of multiple Care-of Addresses at a given Home Agent address [Standard Track].") However, I think that multiple HA addresses do not imply that the node will have multiple HoAs, and vice versa (multiple HoAs do not imply that we have multiple HA addresses) (please correct me if I am wrong). I think that to fully consider the problem of multihomed MN in MobileIPv6 / NEMO, we should consider multiple CoAs, multiple HoAs, and multiple HA addresses. So I propose the following changes to the charter: * 2nd paragraph in (A.3) Use of multiple interfaces. from 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. to 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) or multiple home addresses. In addition, the Home Agent might be attached to multiple networks through multiple interfaces, or receive multiple IPv6 prefixes on a single network interface, 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. * deliverable 2: from - 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]. To An analysis document explaining what are the limitations for mobile hosts using multiple simultaneous Care-of Addresses, Home Agent addresses and Home addresses using Mobile IPv6, whether issues are specific to Mobile IPv6 or not [Informational]. * Deliverable 3: from A protocol extension to support the registration of multiple Care-of Addresses at a given Home Agent address [Standard Track]. TO A protocol extension to support the registration of multiple Care-of Addresses to a single home address [Standard Track]. - I have another issue with the fourth deliverable of this section A3. The current charter says in A3: 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]. I think this goal is not very clear and would need to be clarified. I can read here three different goals, which are: (1) Exchange policies to influence the choice of the CoA (2) Exchange policies to influence the choice of the HA address (3) Specify a generic format to describe the policies I think that (1) should be re-written to "Policies enforcement from the mobile host/routerto the HA to influence the choice of the CoA." I suggest that because the mobile host/router is the only one to know the addresses that are mapped to its interfaces. What we need, is a protocol to indicate to the HA which CoA to use at the HA for a specific flow. The policies set up (e.g., I want VoIP over your Wifi interface) was always out of scope of the work in monami6. (2) isn't it HA switching work? (3) Can't we add an additional item to make clear that we will have 2 documents? _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 24 14:35: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 1IDPEk-0001dW-2U; Tue, 24 Jul 2007 14:35:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDPEi-0001dK-Ey for mext@ietf.org; Tue, 24 Jul 2007 14:35:56 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDPEh-0003IB-PQ for mext@ietf.org; Tue, 24 Jul 2007 14:35:56 -0400 Received: from iseran.local (dhcp-118e.ietf69.org [130.129.17.142]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l6OIZqUp013249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Jul 2007 20:35:54 +0200 Date: Tue, 24 Jul 2007 20:35:53 +0200 From: Thierry Ernst To: mext@ietf.org Subject: Re: [MEXT] charter - final version Message-Id: <20070724203553.4ce9be07.thierry.ernst@inria.fr> In-Reply-To: <46A6268E.2020003@piuha.net> References: <46A6268E.2020003@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 46A64688.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 Please find inline a couple more comments before it is published. >Mobility EXTensions for IPv6 (MEXT) >Description of Working Group: > >Mobile IPv6 specifies routing support which permits an IPv6 host to The charter is alternatively using Mobile IPv6 / MIP6. I would suggest adding the abbreviation the first time it is mentioned: "Mobile IPb6 (MIP6). >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 NEMO + network mobility = pleonasm. Change "NEMO network mobility mechanisms" to "Network mobility (NEMO) mechanisms I would also remove "built on top of Mobile IPv6" as it would suggest there is a dependance between MIPv6 and NEMO, which is not the case. Both protocols are based on the same concepts and use the same mechanisms. >o RFC 3775 >o RFC 3963 >o RFC 4877 I would add the title of the RFC, not only the number. What about RFC 3776 ? Regarding NEMO, shouldn't we also add somewhere on the charter RFC 4885 to RFC 4889 as the newbie wouldn't have any hint they exist ? These are important informational documents to justify the work being done and the direction of the WG (something that is always missing in WG charters). >The MEXT Working Group continues the work of the MIP6, NEMO, and >MONAMI6 Working Groups. I would add "former" before MIP6, NEMO & MONANI6 WGs >Deployment considerations call for (A.1) solutions to enable >dual-stack operation, (A.2) mechanisms to support high-availability >home agents, (A.3) allowing the use of multiple interfaces in mobile >nodes, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, Mobile IPv6 => Mobile IPv6/NEMO >(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 MIP6 session => MIP6/NEMO session > attach to IPv4 access networks. Additionally provide a mechanism > for carrying IPv4 packets via the Home agent for MIP6 capable > dual-stack hosts. MIP6/NEMO capable > >(A.2) A protocol based solution for enhancing the reliability of home > agents and a method to force a host to switch home agents. host => host/router > 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. No more comments on the remaining text. Thanks, Thierry _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 24 16: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 1IDR36-0007Pm-PP; Tue, 24 Jul 2007 16:32:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDR35-0007Ph-4r for mext@ietf.org; Tue, 24 Jul 2007 16:32:03 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDR34-0002Nd-8t for mext@ietf.org; Tue, 24 Jul 2007 16:32:03 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7607E198680; Tue, 24 Jul 2007 23:32:01 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9415019867D; Tue, 24 Jul 2007 23:32:00 +0300 (EEST) Message-ID: <46A661B2.4070601@piuha.net> Date: Tue, 24 Jul 2007 15:31:46 -0500 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Nicolas Montavont Subject: Re: [MEXT] new charter version References: <8386EDF347730C46BA47710F87AE1FE9303B73@hcbjdc2> <46A6160B.8000309@piuha.net> <46A63C07.6080505@enst-bretagne.fr> In-Reply-To: <46A63C07.6080505@enst-bretagne.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 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 Nicolas, I have not sent this forward yet, so there is time to make edits. However, as I recall the Monami6 chartering process, the decision to not focus on multiple home addresses was done deliberately. That is, the use of multiple home addresses is very close to the generic multihoming problem and it seemed inappropriate to try to address that in a mobility working group. So, while I agree that the current text is not the best possible one, I'm not sure the new text is right either... Jari > I am sorry I should have commented the charter earlier, but here are > some thoughts. We will take some time at the monami6 meeting on > Wednesday to discuss those. > > - I was wondering how multiple HA addresses is linked to multiple > home addresses allocated to mobile hosts. When talking about multiple > interfaces (item A.3), the charter mainly talks about multiple CoAs > and multiple HA addresses. However, in the current documents that we > have in the Monami6 WG, we focus more on multiple CoAs and multiple > HoAs. For example, the current working group document > draft-ietf-monami6-multiplecoa-03.txt proposes a mechanism to bind > multiple CoAs to a single HoA, not a single HA address as written in > the MEXT charter ("A protocol extension to support the registration of > multiple Care-of Addresses at a given Home Agent address [Standard > Track].") > > However, I think that multiple HA addresses do not imply that the node > will have multiple HoAs, and vice versa (multiple HoAs do not imply > that we have multiple HA addresses) (please correct me if I am wrong). > I think that to fully consider the problem of multihomed MN in > MobileIPv6 / NEMO, we should consider multiple CoAs, multiple HoAs, > and multiple HA addresses. So I propose the following changes to the > charter: > > * 2nd paragraph in (A.3) Use of multiple interfaces. > from > 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. > > to > > 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) or multiple home addresses. > In addition, the Home Agent might be attached to multiple networks > through multiple interfaces, or receive multiple IPv6 prefixes on a > single network interface, 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. > > * deliverable 2: > from > - 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]. > > To > An analysis document explaining what are the limitations for mobile > hosts using multiple simultaneous Care-of Addresses, Home Agent > addresses and Home addresses using Mobile IPv6, whether issues are > specific to Mobile IPv6 or not [Informational]. > > * Deliverable 3: > from > A protocol extension to support the registration of multiple Care-of > Addresses at a given Home Agent address [Standard Track]. > TO > A protocol extension to support the registration of multiple Care-of > Addresses to a single home address [Standard Track]. > > - I have another issue with the fourth deliverable of this section > A3. The current charter says in A3: > > 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]. > > I think this goal is not very clear and would need to be clarified. I > can read here three different goals, which are: > (1) Exchange policies to influence the choice of the CoA > (2) Exchange policies to influence the choice of the HA address > (3) Specify a generic format to describe the policies > > I think that (1) should be re-written to "Policies enforcement from > the mobile host/routerto the HA to influence the choice of the CoA." I > suggest that because the mobile host/router is the only one to know > the addresses that are mapped to its interfaces. What we need, is a > protocol to indicate to the HA which CoA to use at the HA for a > specific flow. The policies set up (e.g., I want VoIP over your Wifi > interface) was always out of scope of the work in monami6. > > (2) isn't it HA switching work? > > (3) Can't we add an additional item to make clear that we will have 2 > documents? > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 24 17:30: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 1IDRxw-00029p-0R; Tue, 24 Jul 2007 17:30:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRxt-00029f-RJ for mext@ietf.org; Tue, 24 Jul 2007 17:30:45 -0400 Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDRxs-0007H4-HM for mext@ietf.org; Tue, 24 Jul 2007 17:30:45 -0400 Received: from wanynb1 ([129.254.1.8]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 06:36:20 +0900 From: "Taewan You" To: "'Jari Arkko'" References: <8386EDF347730C46BA47710F87AE1FE9303B73@hcbjdc2><46A6160B.8000309@piuha.net> <46A63C07.6080505@enst-bretagne.fr> <46A661B2.4070601@piuha.net> Subject: RE: [MEXT] new charter version Date: Wed, 25 Jul 2007 06:30:36 +0900 Message-ID: <002201c7ce39$e1ac1f40$3f168182@wanynb1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <46A661B2.4070601@piuha.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfOMt+xDG6/biYRS3CXPwptYHJ6bQABrhEw X-OriginalArrivalTime: 24 Jul 2007 21:36:20.0563 (UTC) FILETIME=[ACC90A30:01C7CE3A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 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 Dear Jari, I fully agree with Nicolas opinion about the multiple HoAs. We will assume a general situation in where a mobile node with three heterogeneous interfaces such as 802.11, CDMA, and 802.16e. In this situation, we will also assume that each technology is provided in different service provider. Then each interface has own home address for supporting connectivity to own subscribers. Therefore, there are so several issues to clarify in this situation as like according to the draft of "mip6 analysis" such as registration to given home agent, synchronizations between multiple home agents, and so on. Regarding a position of Administrators for each different L2 technologies, the issues of multiple home agents and addresses should be handled. And I think that the issues are belonging to mobility extension work. Regarding Taewan. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Wednesday, July 25, 2007 5:32 AM > To: Nicolas Montavont > Cc: mext@ietf.org > Subject: Re: [MEXT] new charter version > > > Nicolas, > > I have not sent this forward yet, so there is time to make > edits. > > However, as I recall the Monami6 chartering process, the > decision to not focus on multiple home addresses was done > deliberately. That is, the use of multiple home addresses > is very close to the generic multihoming problem and it > seemed inappropriate to try to address that in a mobility > working group. > > So, while I agree that the current text is not the best > possible one, I'm not sure the new text is right either... > > Jari > > > I am sorry I should have commented the charter earlier, but here are > > some thoughts. We will take some time at the monami6 meeting on > > Wednesday to discuss those. > > > > - I was wondering how multiple HA addresses is linked to multiple > > home addresses allocated to mobile hosts. When talking about multiple > > interfaces (item A.3), the charter mainly talks about multiple CoAs > > and multiple HA addresses. However, in the current documents that we > > have in the Monami6 WG, we focus more on multiple CoAs and multiple > > HoAs. For example, the current working group document > > draft-ietf-monami6-multiplecoa-03.txt proposes a mechanism to bind > > multiple CoAs to a single HoA, not a single HA address as written in > > the MEXT charter ("A protocol extension to support the registration of > > multiple Care-of Addresses at a given Home Agent address [Standard > > Track].") > > > > However, I think that multiple HA addresses do not imply that the node > > will have multiple HoAs, and vice versa (multiple HoAs do not imply > > that we have multiple HA addresses) (please correct me if I am wrong). > > I think that to fully consider the problem of multihomed MN in > > MobileIPv6 / NEMO, we should consider multiple CoAs, multiple HoAs, > > and multiple HA addresses. So I propose the following changes to the > > charter: > > > > * 2nd paragraph in (A.3) Use of multiple interfaces. > > from > > 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. > > > > to > > > > 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) or multiple home addresses. > > In addition, the Home Agent might be attached to multiple networks > > through multiple interfaces, or receive multiple IPv6 prefixes on a > > single network interface, 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. > > > > * deliverable 2: > > from > > - 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]. > > > > To > > An analysis document explaining what are the limitations for mobile > > hosts using multiple simultaneous Care-of Addresses, Home Agent > > addresses and Home addresses using Mobile IPv6, whether issues are > > specific to Mobile IPv6 or not [Informational]. > > > > * Deliverable 3: > > from > > A protocol extension to support the registration of multiple Care-of > > Addresses at a given Home Agent address [Standard Track]. > > TO > > A protocol extension to support the registration of multiple Care-of > > Addresses to a single home address [Standard Track]. > > > > - I have another issue with the fourth deliverable of this section > > A3. The current charter says in A3: > > > > 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]. > > > > I think this goal is not very clear and would need to be clarified. I > > can read here three different goals, which are: > > (1) Exchange policies to influence the choice of the CoA > > (2) Exchange policies to influence the choice of the HA address > > (3) Specify a generic format to describe the policies > > > > I think that (1) should be re-written to "Policies enforcement from > > the mobile host/routerto the HA to influence the choice of the CoA." I > > suggest that because the mobile host/router is the only one to know > > the addresses that are mapped to its interfaces. What we need, is a > > protocol to indicate to the HA which CoA to use at the HA for a > > specific flow. The policies set up (e.g., I want VoIP over your Wifi > > interface) was always out of scope of the work in monami6. > > > > (2) isn't it HA switching work? > > > > (3) Can't we add an additional item to make clear that we will have 2 > > documents? > > > > > > > _______________________________________________ > 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 mext-bounces@ietf.org Tue Jul 24 17:45: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 1IDSC9-0006SW-6G; Tue, 24 Jul 2007 17:45:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDSC7-0006SM-81 for mext@ietf.org; Tue, 24 Jul 2007 17:45:27 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDSC6-0007dX-5n for mext@ietf.org; Tue, 24 Jul 2007 17:45:27 -0400 Received: from iseran.local (dhcp-118e.ietf69.org [130.129.17.142]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l6OLjNmT017012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Jul 2007 23:45:25 +0200 Date: Tue, 24 Jul 2007 23:45:23 +0200 From: Thierry Ernst To: mext@ietf.org Subject: Re: [MEXT] new charter version Message-Id: <20070724234523.b76c6ed9.thierry.ernst@inria.fr> In-Reply-To: <46A661B2.4070601@piuha.net> References: <8386EDF347730C46BA47710F87AE1FE9303B73@hcbjdc2> <46A6160B.8000309@piuha.net> <46A63C07.6080505@enst-bretagne.fr> <46A661B2.4070601@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 46A672F3.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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 >I have not sent this forward yet, so there is time to make >edits. > >However, as I recall the Monami6 chartering process, the >decision to not focus on multiple home addresses was done >deliberately. That is, the use of multiple home addresses >is very close to the generic multihoming problem and it >seemed inappropriate to try to address that in a mobility >working group. > >So, while I agree that the current text is not the best >possible one, I'm not sure the new text is right either... You are right, this is resulting from the MonAmi6 chartering process. The problem is that a CoA is bound to a particular HoA, not the HA address, so we cannot skip dealing with the HoA. Not dealing with all of the cases bring inconsistancy between the charter and the documents. I'm in favor of clarity in the charter and the problem statements. Regarding the solutions, I think everyone will understand that the group is not going to work on issues dealt with Shim6 or other groups. Thierry >Jari > >> I am sorry I should have commented the charter earlier, but here are >> some thoughts. We will take some time at the monami6 meeting on >> Wednesday to discuss those. >> >> - I was wondering how multiple HA addresses is linked to multiple >> home addresses allocated to mobile hosts. When talking about multiple >> interfaces (item A.3), the charter mainly talks about multiple CoAs >> and multiple HA addresses. However, in the current documents that we >> have in the Monami6 WG, we focus more on multiple CoAs and multiple >> HoAs. For example, the current working group document >> draft-ietf-monami6-multiplecoa-03.txt proposes a mechanism to bind >> multiple CoAs to a single HoA, not a single HA address as written in >> the MEXT charter ("A protocol extension to support the registration of >> multiple Care-of Addresses at a given Home Agent address [Standard >> Track].") >> >> However, I think that multiple HA addresses do not imply that the node >> will have multiple HoAs, and vice versa (multiple HoAs do not imply >> that we have multiple HA addresses) (please correct me if I am wrong). >> I think that to fully consider the problem of multihomed MN in >> MobileIPv6 / NEMO, we should consider multiple CoAs, multiple HoAs, >> and multiple HA addresses. So I propose the following changes to the >> charter: >> >> * 2nd paragraph in (A.3) Use of multiple interfaces. >> from >> 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. >> >> to >> >> 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) or multiple home addresses. >> In addition, the Home Agent might be attached to multiple networks >> through multiple interfaces, or receive multiple IPv6 prefixes on a >> single network interface, 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. >> >> * deliverable 2: >> from >> - 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]. >> >> To >> An analysis document explaining what are the limitations for mobile >> hosts using multiple simultaneous Care-of Addresses, Home Agent >> addresses and Home addresses using Mobile IPv6, whether issues are >> specific to Mobile IPv6 or not [Informational]. >> >> * Deliverable 3: >> from >> A protocol extension to support the registration of multiple Care-of >> Addresses at a given Home Agent address [Standard Track]. >> TO >> A protocol extension to support the registration of multiple Care-of >> Addresses to a single home address [Standard Track]. >> >> - I have another issue with the fourth deliverable of this section >> A3. The current charter says in A3: >> >> 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]. >> >> I think this goal is not very clear and would need to be clarified. I >> can read here three different goals, which are: >> (1) Exchange policies to influence the choice of the CoA >> (2) Exchange policies to influence the choice of the HA address >> (3) Specify a generic format to describe the policies >> >> I think that (1) should be re-written to "Policies enforcement from >> the mobile host/routerto the HA to influence the choice of the CoA." I >> suggest that because the mobile host/router is the only one to know >> the addresses that are mapped to its interfaces. What we need, is a >> protocol to indicate to the HA which CoA to use at the HA for a >> specific flow. The policies set up (e.g., I want VoIP over your Wifi >> interface) was always out of scope of the work in monami6. >> >> (2) isn't it HA switching work? >> >> (3) Can't we add an additional item to make clear that we will have 2 >> documents? >> >> > > >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www1.ietf.org/mailman/listinfo/mext > -- Thierry ERNST, PhD INRIA Rocquencourt France Project-Team IMARA / JRU LARA http://www.lara.prd.fr +33 1 39 63 59 30 (office) -- The coming end of the IPv4 world: http://penrose.uk6x.com _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 24 18:07: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 1IDSXi-0006TR-HZ; Tue, 24 Jul 2007 18:07:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDSXh-0006TH-Dv for mext@ietf.org; Tue, 24 Jul 2007 18:07:45 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDSXg-0004Bw-1K for mext@ietf.org; Tue, 24 Jul 2007 18:07:45 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3DBDC198680; Wed, 25 Jul 2007 01:07:43 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8B57619867D; Wed, 25 Jul 2007 01:07:41 +0300 (EEST) Message-ID: <46A6781E.2050109@piuha.net> Date: Tue, 24 Jul 2007 17:07:26 -0500 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Taewan You Subject: Re: [MEXT] new charter version References: <8386EDF347730C46BA47710F87AE1FE9303B73@hcbjdc2><46A6160B.8000309@piuha.net> <46A63C07.6080505@enst-bretagne.fr> <46A661B2.4070601@piuha.net> <002201c7ce39$e1ac1f40$3f168182@wanynb1> In-Reply-To: <002201c7ce39$e1ac1f40$3f168182@wanynb1> 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: 25eb6223a37c19d53ede858176b14339 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 There is no question that the issues exist. The argument was that this is not the right place to deal with them. Jari Taewan You kirjoitti: > Dear Jari, > > I fully agree with Nicolas opinion about the multiple HoAs. > > We will assume a general situation in where a mobile node with three > heterogeneous interfaces such as 802.11, CDMA, and 802.16e. In this > situation, we will also assume that each technology is provided in different > service provider. Then each interface has own home address for supporting > connectivity to own subscribers. > > Therefore, there are so several issues to clarify in this situation as like > according to the draft of "mip6 analysis" such as registration to given home > agent, synchronizations between multiple home agents, and so on. > > Regarding a position of Administrators for each different L2 technologies, > the issues of multiple home agents and addresses should be handled. And I > think that the issues are belonging to mobility extension work. > > Regarding > Taewan. > > >> -----Original Message----- >> From: Jari Arkko [mailto:jari.arkko@piuha.net] >> Sent: Wednesday, July 25, 2007 5:32 AM >> To: Nicolas Montavont >> Cc: mext@ietf.org >> Subject: Re: [MEXT] new charter version >> >> >> Nicolas, >> >> I have not sent this forward yet, so there is time to make >> edits. >> >> However, as I recall the Monami6 chartering process, the >> decision to not focus on multiple home addresses was done >> deliberately. That is, the use of multiple home addresses >> is very close to the generic multihoming problem and it >> seemed inappropriate to try to address that in a mobility >> working group. >> >> So, while I agree that the current text is not the best >> possible one, I'm not sure the new text is right either... >> >> Jari >> >> >>> I am sorry I should have commented the charter earlier, but here are >>> some thoughts. We will take some time at the monami6 meeting on >>> Wednesday to discuss those. >>> >>> - I was wondering how multiple HA addresses is linked to multiple >>> home addresses allocated to mobile hosts. When talking about multiple >>> interfaces (item A.3), the charter mainly talks about multiple CoAs >>> and multiple HA addresses. However, in the current documents that we >>> have in the Monami6 WG, we focus more on multiple CoAs and multiple >>> HoAs. For example, the current working group document >>> draft-ietf-monami6-multiplecoa-03.txt proposes a mechanism to bind >>> multiple CoAs to a single HoA, not a single HA address as written in >>> the MEXT charter ("A protocol extension to support the registration of >>> multiple Care-of Addresses at a given Home Agent address [Standard >>> Track].") >>> >>> However, I think that multiple HA addresses do not imply that the node >>> will have multiple HoAs, and vice versa (multiple HoAs do not imply >>> that we have multiple HA addresses) (please correct me if I am wrong). >>> I think that to fully consider the problem of multihomed MN in >>> MobileIPv6 / NEMO, we should consider multiple CoAs, multiple HoAs, >>> and multiple HA addresses. So I propose the following changes to the >>> charter: >>> >>> * 2nd paragraph in (A.3) Use of multiple interfaces. >>> from >>> 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. >>> >>> to >>> >>> 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) or multiple home addresses. >>> In addition, the Home Agent might be attached to multiple networks >>> through multiple interfaces, or receive multiple IPv6 prefixes on a >>> single network interface, 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. >>> >>> * deliverable 2: >>> from >>> - 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]. >>> >>> To >>> An analysis document explaining what are the limitations for mobile >>> hosts using multiple simultaneous Care-of Addresses, Home Agent >>> addresses and Home addresses using Mobile IPv6, whether issues are >>> specific to Mobile IPv6 or not [Informational]. >>> >>> * Deliverable 3: >>> from >>> A protocol extension to support the registration of multiple Care-of >>> Addresses at a given Home Agent address [Standard Track]. >>> TO >>> A protocol extension to support the registration of multiple Care-of >>> Addresses to a single home address [Standard Track]. >>> >>> - I have another issue with the fourth deliverable of this section >>> A3. The current charter says in A3: >>> >>> 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]. >>> >>> I think this goal is not very clear and would need to be clarified. I >>> can read here three different goals, which are: >>> (1) Exchange policies to influence the choice of the CoA >>> (2) Exchange policies to influence the choice of the HA address >>> (3) Specify a generic format to describe the policies >>> >>> I think that (1) should be re-written to "Policies enforcement from >>> the mobile host/routerto the HA to influence the choice of the CoA." I >>> suggest that because the mobile host/router is the only one to know >>> the addresses that are mapped to its interfaces. What we need, is a >>> protocol to indicate to the HA which CoA to use at the HA for a >>> specific flow. The policies set up (e.g., I want VoIP over your Wifi >>> interface) was always out of scope of the work in monami6. >>> >>> (2) isn't it HA switching work? >>> >>> (3) Can't we add an additional item to make clear that we will have 2 >>> documents? >>> >>> >>> >> _______________________________________________ >> 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 Tue Jul 24 18:08: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 1IDSYO-00073Y-9d; Tue, 24 Jul 2007 18:08:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDSYN-0006zZ-C1 for mip6@ietf.org; Tue, 24 Jul 2007 18:08:27 -0400 Received: from an-out-0708.google.com ([209.85.132.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDSYN-0004D7-2V for mip6@ietf.org; Tue, 24 Jul 2007 18:08:27 -0400 Received: by an-out-0708.google.com with SMTP id c17so461936anc for ; Tue, 24 Jul 2007 15:08:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=qjH/SC6nW95IjPHKpUSFcUTsOz+xVd9BQ8ABA80JUZ+Yc2Udbjg7V3jkMspUw0R3miaV3dca+Sy18RaZVLhBu8Vhn/QQ3+4e75S4WtvCMQs+y7Wn0U9mGjJe7iRhKsvAfbtUtUg1kACOT7hmfaESf8PS6SXubK5kQ6+4g7StAMo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=UL0+AQByKIOnbgVSqiDs4ihRYM8jT5bcOajHWHmSU5hFU/4gUSc1vRsX5ypWbl3AeguYZ2pZQX7UnMHY1YrkGzzV5Zas/yu4eN0kpJImKWRzS7H6a/91WCjP9OKQ0+hWEy8Av5WDd+TwdxrUIEq9kRrKlLUpiGkkOukCTQYgaRQ= Received: by 10.100.37.4 with SMTP id k4mr2623398ank.1185314906675; Tue, 24 Jul 2007 15:08:26 -0700 (PDT) Received: by 10.100.135.16 with HTTP; Tue, 24 Jul 2007 15:08:26 -0700 (PDT) Message-ID: <729b68be0707241508o56de99ceje8872da1f1d2ae9c@mail.gmail.com> Date: Wed, 25 Jul 2007 00:08:26 +0200 From: "Jean-Michel Combes" To: "Mobile IPv6 Mailing List" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Mip6] Comment on draft-krishnan-mip6-firewall-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, regarding the MN-HA signalling (i.e. BU/BA), I've checked in different RFCs: o Authentication and transport mode are mandatory "When securing Binding Updates, Binding Acknowledgements, and prefix discovery, both the mobile nodes and the home agents MUST support and SHOULD use the Encapsulating Security Payload (ESP) [3] header in transport mode and MUST use a non-null payload authentication algorithm to provide data origin authentication, connectionless integrity and optional anti-replay protection." (RFC3776) "When securing Binding Updates, Binding Acknowledgements, and Mobile Prefix Discovery messages, both the mobile node and the home agent MUST support the use of the Encapsulating Security Payload (ESP) [6] header in transport mode and MUST use a non-null payload authentication algorithm to provide data origin authentication, connectionless integrity, and optional anti-replay protection." (RFC 4877) o Tunnel mode is optional "Support for protecting these messages using ESP in tunnel mode is optional." (RFC 4877) And the BU/BA packets looks like (RFC 3776): IPv6 header (source = care-of address, destination = home agent) Destination Options header Home Address option (home address) ESP header in transport mode Mobility header Binding Update Alternate Care-of Address option (care-of address) IPv6 header (source = home agent, destination = care-of address) Routing header (type 2) home address ESP header in transport mode Mobility header Binding Acknowledgement So a FW is able to look at the HoA in the BU/BA and so it is possible to set up a policy based on MN HoA even if you use ESP with encryption. Best regards. JMC. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mext-bounces@ietf.org Tue Jul 24 20:01: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 1IDUJR-0000mt-FT; Tue, 24 Jul 2007 20:01:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDUJQ-0000mo-TB for mext@ietf.org; Tue, 24 Jul 2007 20:01:08 -0400 Received: from [2001:660:7301:3192:211:43ff:fea3:7e4b] (helo=laposte.rennes.enst-bretagne.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDUJP-0006CN-0w for mext@ietf.org; Tue, 24 Jul 2007 20:01:08 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.7/8.13.7/2006.08.14) with ESMTP id l6P00mG7025654; Wed, 25 Jul 2007 02:00:48 +0200 Received: from l2.rennes.enst-bretagne.fr (l2.rennes.enst-bretagne.fr [192.44.77.4]) by laposte.rennes.enst-bretagne.fr (8.13.7/8.13.7/2007.03.20) with ESMTP id l6P00hIt025644; Wed, 25 Jul 2007 02:00:43 +0200 Received: from [130.129.23.203] (dhcp-17cb.ietf69.org [130.129.23.203]) (authenticated bits=0) by l2.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id l6P00aB7031780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 02:00:42 +0200 Message-ID: <46A692A1.3060005@enst-bretagne.fr> Date: Wed, 25 Jul 2007 02:00:33 +0200 From: Nicolas Montavont User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [MEXT] new charter version References: <8386EDF347730C46BA47710F87AE1FE9303B73@hcbjdc2> <46A6160B.8000309@piuha.net> <46A63C07.6080505@enst-bretagne.fr> <46A661B2.4070601@piuha.net> In-Reply-To: <46A661B2.4070601@piuha.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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, Jari Arkko wrote: > Nicolas, > > I have not sent this forward yet, so there is time to make > edits. > > However, as I recall the Monami6 chartering process, the > decision to not focus on multiple home addresses was done > deliberately. That is, the use of multiple home addresses > is very close to the generic multihoming problem and it > seemed inappropriate to try to address that in a mobility > working group. > I remember and still agree. I think that it is not the job of monami6 (and MEXT) to propose solutions for multiple HoA management. > So, while I agree that the current text is not the best > possible one, I'm not sure the new text is right either... > However I think that we can (and should) enhance the text, without proposing more work that we are actually doing in Monami6 (and follow in MEXT). For example, the item 3 (registration of multiple CoA) is definitely the registration of multiple CoA to a single home address, and not for a single HA address as we have now in the charter. The other changes I proposed (on the multiple HoAs issue) mainly concerns the problem statement document and does not suggest to deal with the problem in this working group. Indeed, in the problem statement document we suggest either to use other multihoming protocol (such as shim6), or to be able to register a HoA as a CoA in specific configuration. Regards, Nicolas > Jari > > >> I am sorry I should have commented the charter earlier, but here are >> some thoughts. We will take some time at the monami6 meeting on >> Wednesday to discuss those. >> >> - I was wondering how multiple HA addresses is linked to multiple >> home addresses allocated to mobile hosts. When talking about multiple >> interfaces (item A.3), the charter mainly talks about multiple CoAs >> and multiple HA addresses. However, in the current documents that we >> have in the Monami6 WG, we focus more on multiple CoAs and multiple >> HoAs. For example, the current working group document >> draft-ietf-monami6-multiplecoa-03.txt proposes a mechanism to bind >> multiple CoAs to a single HoA, not a single HA address as written in >> the MEXT charter ("A protocol extension to support the registration of >> multiple Care-of Addresses at a given Home Agent address [Standard >> Track].") >> >> However, I think that multiple HA addresses do not imply that the node >> will have multiple HoAs, and vice versa (multiple HoAs do not imply >> that we have multiple HA addresses) (please correct me if I am wrong). >> I think that to fully consider the problem of multihomed MN in >> MobileIPv6 / NEMO, we should consider multiple CoAs, multiple HoAs, >> and multiple HA addresses. So I propose the following changes to the >> charter: >> >> * 2nd paragraph in (A.3) Use of multiple interfaces. >> from >> 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. >> >> to >> >> 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) or multiple home addresses. >> In addition, the Home Agent might be attached to multiple networks >> through multiple interfaces, or receive multiple IPv6 prefixes on a >> single network interface, 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. >> >> * deliverable 2: >> from >> - 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]. >> >> To >> An analysis document explaining what are the limitations for mobile >> hosts using multiple simultaneous Care-of Addresses, Home Agent >> addresses and Home addresses using Mobile IPv6, whether issues are >> specific to Mobile IPv6 or not [Informational]. >> >> * Deliverable 3: >> from >> A protocol extension to support the registration of multiple Care-of >> Addresses at a given Home Agent address [Standard Track]. >> TO >> A protocol extension to support the registration of multiple Care-of >> Addresses to a single home address [Standard Track]. >> >> - I have another issue with the fourth deliverable of this section >> A3. The current charter says in A3: >> >> 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]. >> >> I think this goal is not very clear and would need to be clarified. I >> can read here three different goals, which are: >> (1) Exchange policies to influence the choice of the CoA >> (2) Exchange policies to influence the choice of the HA address >> (3) Specify a generic format to describe the policies >> >> I think that (1) should be re-written to "Policies enforcement from >> the mobile host/routerto the HA to influence the choice of the CoA." I >> suggest that because the mobile host/router is the only one to know >> the addresses that are mapped to its interfaces. What we need, is a >> protocol to indicate to the HA which CoA to use at the HA for a >> specific flow. The policies set up (e.g., I want VoIP over your Wifi >> interface) was always out of scope of the work in monami6. >> >> (2) isn't it HA switching work? >> >> (3) Can't we add an additional item to make clear that we will have 2 >> documents? >> >> >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mip6-bounces@ietf.org Wed Jul 25 10:36: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 1IDhyt-0008Ra-Cx; Wed, 25 Jul 2007 10:36:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDhyr-0008R5-Ow for mip6@ietf.org; Wed, 25 Jul 2007 10:36:49 -0400 Received: from mxs1.siemens.at ([194.138.12.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDhyq-0000MU-4K for mip6@ietf.org; Wed, 25 Jul 2007 10:36:49 -0400 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id l6PEaZCJ018101; Wed, 25 Jul 2007 16:36:35 +0200 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l6PEaY30002163; Wed, 25 Jul 2007 16:36:34 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jul 2007 16:36:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] new DSMIP draft Date: Wed, 25 Jul 2007 16:36:32 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD68025D663D@zagh223a.ww300.siemens.net> In-Reply-To: <20070709133728.FKVH23230.oaamta05sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] new DSMIP draft Thread-Index: AcfCLkeFsmF3MNrURdimEQHJT+raWwMmODMQ References: <20070709133728.FKVH23230.oaamta05sl.mx.bigpond.com@PC20005> From: "Premec, Domagoj" To: "Hesham Soliman" X-OriginalArrivalTime: 25 Jul 2007 14:36:34.0178 (UTC) FILETIME=[32F16E20:01C7CEC9] 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::070725163635-4AFBEBB0-64F40BF8/0-0/0-15 X-purgate-size: 1068/0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham, The draft is inconsistent about the situation when the HA doesn't = support the IPv4 HoA. In section 2.3.1, 4th paragraph, the draft = requires the MN not to send (SHOULD NOT) IPv4 HoA option in future = binding updates. In section 4.4, 1st bullet on page 19, the draft states = the MN MAY include IPv4 HoA option in future binding updates. I would = prefer the "SHOULD NOT" behaviour. thanks domagoj > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: 09. srpanj 2007 15:37 > To: mip6@ietf.org; nemo@ietf.org > Subject: [Mip6] new DSMIP draft >=20 > Folks,=20 >=20 > Until the draft is announced you can find it here: > http://www.elevatemobile.com/ietf/draft-ietf-mip6-nemo-v4trave rsal-05.txt >=20 > There are some id nits that I plan to handle with WGLC, I'm=20 > transferring it to xml now.=20 >=20 > Hesham >=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 Wed Jul 25 11:58: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 1IDjFv-0002uf-EY; Wed, 25 Jul 2007 11:58:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDjFu-0002ry-Vc for mip6@ietf.org; Wed, 25 Jul 2007 11:58:31 -0400 Received: from hiltonsmtp.worldspice.net ([216.37.94.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDjFt-00074e-Vd for mip6@ietf.org; Wed, 25 Jul 2007 11:58:30 -0400 Received: (qmail 25499 invoked by uid 0); 25 Jul 2007 15:50:51 -0000 Received: by simscan 1.2.0 ppid: 25486, pid: 25491, t: 0.8979s scanners: clamav: 0.90.2/m: spam: 3.1.8 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on hiltonsmtp.worldspice.net X-Spam-Level: * X-Spam-Status: No, score=1.0 required=6.5 tests=ALL_TRUSTED,BAYES_60, MISSING_MID autolearn=disabled version=3.2.1 Received: from unknown (HELO PC20005) (Hesham@elevatemobile.com@67.97.210.2) by hiltonsmtp.worldspice.net with ESMTPA; 25 Jul 2007 15:50:50 -0000 From: "Hesham Soliman" To: "'Premec, Domagoj'" Subject: RE: [Mip6] new DSMIP draft Date: Thu, 26 Jul 2007 01:58: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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 thread-index: AcfCLkeFsmF3MNrURdimEQHJT+raWwMmODMQAANOA/A= In-Reply-To: <3C31CDD06342EA4A8137716247B1CD68025D663D@zagh223a.ww300.siemens.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Message-Id: Hi Domagoj, Thanks for the catch. I agree with you. I'll add this to the LC comments when we start receiving them. Hesham > -----Original Message----- > From: Premec, Domagoj [mailto:domagoj.premec@siemens.com] > Sent: Thursday, July 26, 2007 12:37 AM > To: Hesham Soliman > Cc: mip6@ietf.org > Subject: RE: [Mip6] new DSMIP draft > > Hi Hesham, > > The draft is inconsistent about the situation when the HA > doesn't support the IPv4 HoA. In section 2.3.1, 4th > paragraph, the draft requires the MN not to send (SHOULD > NOT) IPv4 HoA option in future binding updates. In section > 4.4, 1st bullet on page 19, the draft states the MN MAY > include IPv4 HoA option in future binding updates. I would > prefer the "SHOULD NOT" behaviour. > > thanks > domagoj > > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: 09. srpanj 2007 15:37 > > To: mip6@ietf.org; nemo@ietf.org > > Subject: [Mip6] new DSMIP draft > > > > Folks, > > > > Until the draft is announced you can find it here: > > http://www.elevatemobile.com/ietf/draft-ietf-mip6-nemo-v4trave > rsal-05.txt > > > > There are some id nits that I plan to handle with WGLC, I'm > > transferring it to xml now. > > > > 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 mext-bounces@ietf.org Wed Jul 25 13:13: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 1IDkPy-0002Dw-Qm; Wed, 25 Jul 2007 13:12:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDkPw-0002Ct-DN for mext@ietf.org; Wed, 25 Jul 2007 13:12:56 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDkPu-0005UA-Lv for mext@ietf.org; Wed, 25 Jul 2007 13:12:56 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3BDE7198680; Wed, 25 Jul 2007 20:12:53 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8D5E619867D; Wed, 25 Jul 2007 20:12:52 +0300 (EEST) Message-ID: <46A78493.4050703@piuha.net> Date: Wed, 25 Jul 2007 12:12:51 -0500 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [MEXT] charter - final version References: <46A6268E.2020003@piuha.net> <20070724203553.4ce9be07.thierry.ernst@inria.fr> In-Reply-To: <20070724203553.4ce9be07.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: 8fbbaa16f9fd29df280814cb95ae2290 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 Thierry, Thanks for your comments. Inline: > The charter is alternatively using Mobile IPv6 / MIP6. I would suggest > adding the abbreviation the first time it is mentioned: "Mobile IPb6 > (MIP6). > Yes. Needs fixing. >> 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 >> > > NEMO + network mobility = pleonasm. Change "NEMO network mobility > mechanisms" to "Network mobility (NEMO) mechanisms > Ok. > I would also remove "built on top of Mobile IPv6" as it would suggest > there is a dependance between MIPv6 and NEMO, which is not the case. > Both protocols are based on the same concepts and use the same > mechanisms. > Now I lost you. Here's what RFC 3963 says in the abstract: "The protocol is an extension of Mobile IPv6 and ..." >> o RFC 3775 >> o RFC 3963 >> o RFC 4877 >> > > I would add the title of the RFC, not only the number. OK. > What about RFC > 3776 ? > Taken over by 4877, or at least that is imho the one that we should focus on. > Regarding NEMO, shouldn't we also add somewhere on the charter RFC 4885 > to RFC 4889 as the newbie wouldn't have any hint they exist ? These are > important informational documents to justify the work being done and > the direction of the WG (something that is always missing in WG > charters). > The list is not intended to be exhaustive but point to the main documents. > > >> The MEXT Working Group continues the work of the MIP6, NEMO, and >> MONAMI6 Working Groups. >> > > I would add "former" before MIP6, NEMO & MONANI6 WGs > Ok. > >> Deployment considerations call for (A.1) solutions to enable >> dual-stack operation, (A.2) mechanisms to support high-availability >> home agents, (A.3) allowing the use of multiple interfaces in mobile >> nodes, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, >> > > Mobile IPv6 => Mobile IPv6/NEMO > OK. >> (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 >> > > MIP6 session => MIP6/NEMO session > OK. > > >> attach to IPv4 access networks. Additionally provide a mechanism >> for carrying IPv4 packets via the Home agent for MIP6 capable >> dual-stack hosts. >> > > MIP6/NEMO capable > OK... > >> (A.2) A protocol based solution for enhancing the reliability of home >> agents and a method to force a host to switch home agents. >> > > host => host/router > OK. > >> 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. >> > > > No more comments on the remaining text. > Thanks. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mip6-bounces@ietf.org Wed Jul 25 13:15:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDkSf-0003kA-R9; Wed, 25 Jul 2007 13:15:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDkSU-0003Oy-7x; Wed, 25 Jul 2007 13:15:34 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDkSS-0005az-0p; Wed, 25 Jul 2007 13:15:34 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id EEA47328E6; Wed, 25 Jul 2007 17:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IDkRx-0008NP-S2; Wed, 25 Jul 2007 13:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 25 Jul 2007 13:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-split-07.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobile IPv6 bootstrapping in split scenario Author(s) : G. Giaretta, et al. Filename : draft-ietf-mip6-bootstrapping-split-07.txt Pages : 28 Date : 2007-7-25 A Mobile IPv6 node requires a Home Agent address, a home address, and IPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a Mobile IPv6 node can bootstrap this information from non-topological information and security credentials pre-configured on the Mobile Node. The solution defined in this document solves the split scenario described in the Mobile IPv6 bootstrapping problem statement in RFC 4640. The split scenario refers the case where the Mobile Node's mobility service is authorized by a different service provider than basic network access. The solution described in this document is also generically applicable to any bootstrapping case, since other scenarios are more specific realizations of the split scenario. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-bootstrapping-split-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-bootstrapping-split-07.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-7-25120019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-bootstrapping-split-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-bootstrapping-split-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-25120019.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 mext-bounces@ietf.org Wed Jul 25 18:30: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 1IDpMq-00041R-GZ; Wed, 25 Jul 2007 18:30:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDpMo-00041M-Rh for mext@ietf.org; Wed, 25 Jul 2007 18:30:02 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDpMo-0006AE-CX for mext@ietf.org; Wed, 25 Jul 2007 18:30:02 -0400 Received: from dhcp-15f9.ietf69.org (dhcp-15f9.ietf69.org [130.129.21.249]) (authenticated bits=0) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l6PMTwi9008180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Jul 2007 00:30:01 +0200 Date: Thu, 26 Jul 2007 00:29:58 +0200 From: Thierry Ernst To: mext@ietf.org Subject: Re: [MEXT] charter - final version Message-Id: <20070726002958.c0b9e1e5.thierry.ernst@inria.fr> In-Reply-To: <46A78493.4050703@piuha.net> References: <46A6268E.2020003@piuha.net> <20070724203553.4ce9be07.thierry.ernst@inria.fr> <46A78493.4050703@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 concorde with ID 46A7CEE7.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 >> I would also remove "built on top of Mobile IPv6" as it would suggest >> there is a dependance between MIPv6 and NEMO, which is not the case. >> Both protocols are based on the same concepts and use the same >> mechanisms. >> > >Now I lost you. Here's what RFC 3963 says in the abstract: "The protocol is >an extension of Mobile IPv6 and ..." OK, but I wasn't the one who wrote it otherwise this sentence would have been turned in a different way ;-) >> What about RFC >> 3776 ? >> > >Taken over by 4877, or at least that is imho the one that >we should focus on. OK > >> Regarding NEMO, shouldn't we also add somewhere on the charter RFC 4885 >> to RFC 4889 as the newbie wouldn't have any hint they exist ? These are >> important informational documents to justify the work being done and >> the direction of the WG (something that is always missing in WG >> charters). >> > >The list is not intended to be exhaustive but point to the main documents. Sure, but RFC 3963 was published long time before the other documents, so one reading RFC 3963 won't have a clue about the other RFCs if one haven't follow the history behind MEXT. This is were IETF WG charter pages are lacking (reference to prior published work when it was not published but the same group. Since MEXT is new, all the history behind MIP6 and NEMP WGs will be unknown to the newbie. How to improve this ? May be one way is to keep the NEMO, MIP6 and MONAMI6 WG chartes for historical purposes, and have a pointer from the new charter. But this is something we don't do currently, so I don't expect the MEXT charter to do it as it would have to be discussed with the IETF secretariat or whowever. To conclude, I would like to thank Jari who has done most of the work of merging the 3 charters into 1. Thanks also for having kicked us up many times to meet deadlines ;-) Thierry. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mip6-bounces@ietf.org Thu Jul 26 10:33: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 1IE4PO-0002yQ-LW; Thu, 26 Jul 2007 10:33:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlxR-0007dF-R5 for mip6@ietf.org; Wed, 25 Jul 2007 14:51:37 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDlxR-0006P2-IY for mip6@ietf.org; Wed, 25 Jul 2007 14:51:37 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6PIpac7025017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Jul 2007 13:51:36 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6PIpaLb012362; Wed, 25 Jul 2007 13:51:36 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6PIpVbc012234; Wed, 25 Jul 2007 13:51:36 -0500 (CDT) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 11:51:31 -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: Wed, 25 Jul 2007 11:51:30 -0700 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A03685990@XCH-NW-8V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MONAMI Draft - Aviation Input Thread-Index: AcfO7NBvF3k3kWzaSnCjNvnWGczXNg== From: "Davis, Terry L" To: X-OriginalArrivalTime: 25 Jul 2007 18:51:31.0780 (UTC) FILETIME=[D1064040:01C7CEEC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Thu, 26 Jul 2007 10:33:41 -0400 Cc: mip6@ietf.org, thierry.ernst@inria.fr Subject: [Mip6] MONAMI Draft - Aviation Input X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Aviation Community Please consider inputs or comments to this IETF draft as they are adding some aviation requirements to it. http://www.ietf.org/internet-drafts/draft-ietf-monami6-multihoming-motiv ation-scenario-02.txt=20 This document will go to "last call" in August after which time it will be too late for us to input. Take care Terry _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 26 12:22: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 1IE66F-00010x-IC; Thu, 26 Jul 2007 12:22:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE66D-00010J-DY for mip6@ietf.org; Thu, 26 Jul 2007 12:22:01 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IE66C-0001hT-KS for mip6@ietf.org; Thu, 26 Jul 2007 12:22:01 -0400 Received: (qmail invoked by alias); 26 Jul 2007 16:21:59 -0000 Received: from dhcp-15f4.ietf69.org (EHLO [130.129.21.244]) [130.129.21.244] by mail.gmx.net (mp046) with SMTP; 26 Jul 2007 18:21:59 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/agQ1KcrnaxSEU8s4mg2UlA+v1tegB0FycapuWVr 0jB6Ne0rVwsC9j Message-ID: <46A8CA28.8010509@gmx.net> Date: Thu, 26 Jul 2007 18:22:00 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: 'HIP WG' , mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [Mip6] [Fwd: [BEHAVE] ICE tutorial in Chicago - PLEASE PAY IF YOU ATE LUNCH] X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org FYI -------- Original Message -------- Subject: [BEHAVE] ICE tutorial in Chicago - PLEASE PAY IF YOU ATE LUNCH Date: Thu, 26 Jul 2007 12:19:15 -0400 From: Jonathan Rosenberg To: IETF SIP List , IETF Sipping List , IETF MMUSIC WG , Behave WG , P2PSIP WG , rai@ietf.org, "'avt@ietf.org'" Lunch during the tutorial was paid out of my pocket, and I was expecting to get re-imbursed by everyone that took a sandwich. Though all of the food was taken by the end of the tutorial, I am several hundred dollars short. Please, if you took lunch and did not give me $20, give it to me before you leave, and if you have not, contact me privately and we can arrange for paper mail. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jul 27 12:17: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 1IESVj-0003CA-8j; Fri, 27 Jul 2007 12:17:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESVi-0003C4-A9 for mip6@ietf.org; Fri, 27 Jul 2007 12:17:50 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IESVh-00089d-IR for mip6@ietf.org; Fri, 27 Jul 2007 12:17:50 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6RGHhxo016706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 Jul 2007 09:17:43 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6RGHg54024628; Fri, 27 Jul 2007 09:17:43 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6RGHVeZ024211; Fri, 27 Jul 2007 09:17:42 -0700 (PDT) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 09:17:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Jul 2007 09:17:41 -0700 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A036859C8@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: <46AA0BA6.5060608@mccallumwhyman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MPI]MONAMI Draft - Aviation Input Thread-Index: AcfQYBYqYBG9wvl/S16DX8P6kxIiKAACStpA References: <46AA0BA6.5060608@mccallumwhyman.com> From: "Davis, Terry L" To: "Tony Whyman" , "(Mobile Platform Internet Mailing List)" X-OriginalArrivalTime: 27 Jul 2007 16:17:42.0003 (UTC) FILETIME=[A8798C30:01C7D069] X-Spam-Score: -4.0 (----) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: mip6@ietf.org, thierry.ernst@inria.fr, weddy@grc.nasa.gov Subject: [Mip6] RE: [MPI]MONAMI Draft - Aviation Input X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Tony Thanks! We will re-drafting at least our inputs via the current aviation requirements draft which will go out next month. Wes Eddy is the current author and is an FAA contractor so I cc'd him. Take care Terry > -----Original Message----- > From: Tony Whyman [mailto:tony.whyman@mccallumwhyman.com] > Sent: Friday, July 27, 2007 8:14 AM > To: (Mobile Platform Internet Mailing List); Davis, Terry L > Cc: thierry.ernst@inria.fr; mip6@ietf.org > Subject: Re: [MPI]MONAMI Draft - Aviation Input >=20 > Terry, >=20 > I am writing this response to your call for comments whilst on vacation > and sipping a cold beer on a Greek Island. I say this not so much as to > make readers envious (of course) but as a disclaimer for what goes below > as I may not have read the draft in the detail I should have, and to > point out how useful a mobile technology is GPRS as otherwise how could > I read my EMail on an island in the middle of the Aegean. >=20 > 1. The draft seems not to mention one of the problems that has plagued > the ATN - which for want of a better name I will call the need for > symmetry. That is to ensure that the path from mobile to fixed is the > largely the same as the reverse. This is needed partly to avoid problems > with measuring the loop delay time, but more importantly to ensure that > the fixed to mobile packets follow the intended path. It's no good the > aircraft always carefully selecting VDL over SATCOM for downlink > messages if the ground then uploads a mega message via SATCOM. >=20 > This is not a randomly chosen example. It was the one given by the > airlines as an example of cost based route control. It was based on the > assumption that SATCOM was more expensive than VHF and that airlines > wanted cost control over both directions of transfer. >=20 > Essentially, the requirement is that the mobile must be able to direct > the remote system to use a given interface for data transfers even when > other interfaces are available. >=20 > 2. Returning to that same example, while AOC data may have 'cost' as its > basic selection metric, ATC data has reliability as its selection metric > and this may result in a different choice of preferred interface. >=20 > The requirement over interface choice is not system based, it is > application based and, again I don't feel this comesout of the draft as > the examples there seemed to assume that only a single application was > active at any one time. >=20 > 3. Under the heading "lessons learnt from the past", it's worth > recalling that one of the goals of the OSI Network Layer was to hide > routing from the user and as interfaces were also hidden, this made for > a complex problem whereby an application had to clearly indicate its QoS > requirements for each packet and the routing process in every > intermediate system had then to interpret them (symmetrically). Hence > the complex IDRP based solution in the SARPs. >=20 > On the other hand, if interfaces and route choice are not hidden from > the application, it is possible for applications to keep each other > up-to-date on available interfaces or more specifically, the mobile > network(s) that are available. The routing process is then simplified at > the expense of demanding a sub-protocol that allows the applications to > keep their peers up-to-date on route choice, which can then be expressed > in terms of the destination IP Address and perhaps some additional QOS > metrics, rather than having to express everything in terms of QOS. >=20 > The issue here is what is the correct trade-off between information > hiding in the network and application participation in route selection. > Alternatively this may be expressed as the trade off between router > complexity and end system complexity. This issue does not seem to come > clearly out of the draft. >=20 > Anyway, that's all - the sea beckons and I can't think of anything more > for now. >=20 > Regards >=20 > Tony Whyman >=20 > Davis, Terry L wrote: > > Aviation Community > > > > Please consider inputs or comments to this IETF draft as they are adding > > some aviation requirements to it. > > > > http://www.ietf.org/internet-drafts/draft-ietf-monami6-multihoming-motiv > > ation-scenario-02.txt > > > > This document will go to "last call" in August after which time it will > > be too late for us to input. > > > > Take care > > Terry > > > > ############################################################# > > This message is sent to you because you are subscribed to > > the mailing list . > > To unsubscribe, E-mail to: > > To switch to the DIGEST mode, E-mail to > > To switch to the INDEX mode, E-mail to > > Send administrative queries to > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 30 01: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 1IFNkB-0002WD-Jf; Mon, 30 Jul 2007 01:24:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFNkA-0002VP-1F; Mon, 30 Jul 2007 01:24:34 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IFNk8-0007Js-V7; Mon, 30 Jul 2007 01:24:33 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm6646ad83ef; Mon, 30 Jul 2007 13:36:25 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1c46a77904; Wed, 25 Jul 2007 19:59:26 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 25 Jul 2007 19:59:26 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDN2k-0003Fa-0b; Tue, 24 Jul 2007 12:15:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDN2O-0002hK-Ae; Tue, 24 Jul 2007 12:15:04 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDN2N-0006UH-Rx; Tue, 24 Jul 2007 12:15:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 76306175F6; Tue, 24 Jul 2007 16:15:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IDN2M-0005WP-O6; Tue, 24 Jul 2007 12:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 24 Jul 2007 12:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-hareliability-02.txt X-BeenThere: mip6@ietf.org Reply-To: internet-drafts@ietf.org 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 : Home Agent Reliability Protocol Author(s) : R. Wakikawa Filename : draft-ietf-mip6-hareliability-02.txt Pages : 45 Date : 2007-7-24 The home agent can be a single point of failure when Mobile IPv6 is used in a system. It is critical to provide home agent reliability in the event of a home agent crashing or becoming unavailable. This would allow another home agent to take over and continue providing service to the mobile nodes. This document describes the problem scope briefly and provides a mechanism of home agent failure detection, home agent state transfer, and home agent switching for home agent redundancy and reliability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-hareliability-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-hareliability-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-hareliability-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-7-24115510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-hareliability-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-hareliability-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-24115510.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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--