From eamonnjoe9@allanbruun.com Thu Nov 01 03:21:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InUN7-0007hO-PO for nemo-archive@lists.ietf.org; Thu, 01 Nov 2007 03:21:45 -0400 Received: from [211.224.15.11] (helo=211.224.15.11) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InUMy-0001hM-HR for nemo-archive@lists.ietf.org; Thu, 01 Nov 2007 03:21:40 -0400 Received: from [211.224.15.11] by puhh.allanbruun.com; Thu, 01 Nov 2007 07:21:30 +0000 Message-ID: <000701c81c57$01993913$bc36a9a2@wofbwthd> From: "ferrell siobahn" To: "Jason Mcelroy" Subject: Shop around for luxury items Date: Thu, 01 Nov 2007 05:34:08 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C81C57.01965199" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 2.7 (++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C81C57.01965199 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Perfectly crafted luxury timepieces, all at affordable prices. Thousands = of different models to choose from! http://my07fg.net/ ------=_NextPart_000_0004_01C81C57.01965199 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Perfectly crafted luxury timepieces, all at affordable prices. Thousands = of different models to choose from!

http://my07fg.net/ ------=_NextPart_000_0004_01C81C57.01965199-- From mext-bounces@ietf.org Thu Nov 01 05:38:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InWUC-00027o-Jg; Thu, 01 Nov 2007 05:37:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InW9w-0006uf-6s for mext@ietf.org; Thu, 01 Nov 2007 05:16:16 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InW9g-0006iX-HL for mext@ietf.org; Thu, 01 Nov 2007 05:16:05 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 10:15:44 +0100 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: [MEXT] AD review of draft-korhonen-mip6-service-03.txt Date: Thu, 1 Nov 2007 10:15:43 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9322@SEHAN021MB.tcad.telia.se> In-Reply-To: <47273F85.9000505@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] AD review of draft-korhonen-mip6-service-03.txt Thread-Index: AcgbAST4qz7Btzv7Qa2uxjkNQU7SJABZUigg References: <4700A05C.3070905@piuha.net> <471C3B28.7020107@piuha.net> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9261@SEHAN021MB.tcad.telia.se> <47273F85.9000505@piuha.net> From: To: X-OriginalArrivalTime: 01 Nov 2007 09:15:44.0114 (UTC) FILETIME=[C7E80520:01C81C67] X-Spam-Score: -4.0 (----) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: draft-korhonen-mip6-service@tools.ietf.org, 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 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Tuesday, October 30, 2007 4:28 PM >=20 > I'm wary of specifying something might be found in DNS or might not. >=20 > Also, do we have any evidence that we actually need the=20 > identifiers to be resolved by DNS? In any case, no one would=20 Hard to tell.. There are deployment scenarios where DNS definitely will be involved. However, at the same time I cannot say that it would apply to all deployment scenarios. Looks like it is better to leave out the explicit note on DNS. > turn on service for a particular domain without an agreement=20 > in place with that domain. So the box initiating a VPN tunnel=20 > simply has to have configuration for that domain, its not=20 > enough for the DNS query to succeed. If DNS were involved it could be used with the HA discovery. I.e. to point the MN to a group of HAs that host/allow access to the desired service. Cheers, Jouni >=20 > Jari >=20 > jouni.korhonen@teliasonera.com kirjoitti: > > There was comment I received offline pointing out that=20 > description of=20 > > the service selection option identifier in -04 does not mention DNS=20 > > anymore. In -03 it read > > "The Identifier MAY be resolveable by DNS." > > I think it could be put back. The new text could be: > > > > " o Type: 8-bit identifier set to TBD (to be defined by=20 > IANA) of the > > type of the skipable mobility option. Depending on the system > > deployment the Identifier MAY be resolveable by DNS." > > > > Any thoughts?=20 > > > > > > > > Cheers, > > Jouni > > > > =20 > >> -----Original Message----- > >> From: Jari Arkko [mailto:jari.arkko@piuha.net] > >> Sent: Monday, October 22, 2007 8:55 AM > >> To: Korhonen, Jouni /TeliaSonera Finland Oyj > >> Cc: draft-korhonen-mip6-service@tools.ietf.org; mext@ietf.org > >> Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt > >> > >> > >> The new version addresses the concerns I had. Thanks. The document=20 > >> will now be moved forward. > >> > >> Jari > >> > >> > >> > >> =20 > > > > > > =20 >=20 >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From kristina7claudia7@covad.net Thu Nov 01 06:23:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InXCx-0003rY-Lf for nemo-archive@lists.ietf.org; Thu, 01 Nov 2007 06:23:28 -0400 Received: from [193.109.240.186] (helo=rasbek.itpark.com.ua) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InXCo-0002I2-WB for nemo-archive@lists.ietf.org; Thu, 01 Nov 2007 06:23:19 -0400 Received: from [193.109.240.186] by gsycethp.covad.net; Thu, 01 Nov 2007 10:23:11 +0000 Message-ID: <000a01c81c71$01b4a6b6$1e8f9bba@gepjfqry> From: "joachim shaun" To: "Joy Pugh" Subject: Cocktail party Date: Thu, 01 Nov 2007 08:35:49 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C81C71.01B3594C" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C81C71.01B3594C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Perfectly crafted luxury timepieces, all at affordable prices. Thousands = of different models to choose from! http://brastylene.com/ ------=_NextPart_000_0007_01C81C71.01B3594C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Perfectly crafted luxury timepieces, all at affordable prices. Thousands = of different models to choose from!

http://brastylene.com/ ------=_NextPart_000_0007_01C81C71.01B3594C-- From mext-bounces@ietf.org Thu Nov 01 06:45: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 1InXVN-0003h2-13; Thu, 01 Nov 2007 06:42:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InXVL-0003fD-Fv for mext@ietf.org; Thu, 01 Nov 2007 06:42:27 -0400 Received: from [2001:14b8:400::130] (helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InXVI-00037K-Df for mext@ietf.org; Thu, 01 Nov 2007 06:42:27 -0400 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id B97ED1986C6; Thu, 1 Nov 2007 12:42:23 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 9F947198676; Thu, 1 Nov 2007 12:42:22 +0200 (EET) Message-ID: <4729AD8D.7080603@piuha.net> Date: Thu, 01 Nov 2007 12:42:21 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt References: <4700A05C.3070905@piuha.net> <471C3B28.7020107@piuha.net> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9261@SEHAN021MB.tcad.telia.se> <47273F85.9000505@piuha.net> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9322@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9322@SEHAN021MB.tcad.telia.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: draft-korhonen-mip6-service@tools.ietf.org, 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 DNS were involved it could be used with the HA discovery. > I.e. to point the MN to a group of HAs that host/allow access > to the desired service. > When the service id sent in a Mobile IPv6 message, we are past the discovery phase, no? In any case, my point was that no one would/should configure their HAs to allow them to be used for tunnel gateways for arbitrary domains. You must have configuration that tells you a business relationship exists. DNS doesn't give you that, even if it could supply additional pieces of information. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 01 07:21:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InY4s-0005v5-9j; Thu, 01 Nov 2007 07:19:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InY4q-0005ua-IH for mext@ietf.org; Thu, 01 Nov 2007 07:19:08 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InY4q-0004cZ-74 for mext@ietf.org; Thu, 01 Nov 2007 07:19:08 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 12:19:06 +0100 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: [MEXT] AD review of draft-korhonen-mip6-service-03.txt Date: Thu, 1 Nov 2007 12:19:08 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9334@SEHAN021MB.tcad.telia.se> In-Reply-To: <4729AD8D.7080603@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] AD review of draft-korhonen-mip6-service-03.txt Thread-Index: Acgcc+fsbpcUck0SQbyUKTQbpoiCoQAA7zWA References: <4700A05C.3070905@piuha.net> <471C3B28.7020107@piuha.net> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9261@SEHAN021MB.tcad.telia.se> <47273F85.9000505@piuha.net> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9322@SEHAN021MB.tcad.telia.se> <4729AD8D.7080603@piuha.net> From: To: X-OriginalArrivalTime: 01 Nov 2007 11:19:06.0144 (UTC) FILETIME=[03DC2A00:01C81C79] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: draft-korhonen-mip6-service@tools.ietf.org, 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 DNS were involved it could be used with the HA discovery. > > I.e. to point the MN to a group of HAs that host/allow=20 > access to the=20 > > desired service. > > =20 > When the service id sent in a Mobile IPv6 message, we are=20 > past the discovery phase, no? Yes.. I was just thinking that the id used for discovery could then also be included in the servise selection option. > In any case, my point was that no one would/should configure=20 > their HAs to allow them to be used for tunnel gateways for=20 > arbitrary domains. You must have configuration that tells you=20 > a business relationship exists. DNS doesn't give you that,=20 > even if it could supply additional pieces of information. Agree. /Jouni >=20 > Jari >=20 >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From BerrysmellSharpe@breitbart.com Thu Nov 01 18:05:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ini9v-0005j6-Jo; Thu, 01 Nov 2007 18:05:03 -0400 Received: from [189.174.228.39] (helo=arturobonmoss.gateway.2wire.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ini9m-0000Ty-GT; Thu, 01 Nov 2007 18:04:58 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host37218041.breitbart.com (8.13.1/8.13.1) with SMTP id QLfHjftm80.749222.1Fq.0JA.6116350421814 for ; Thu, 1 Nov 2007 15:04:06 +0700 Message-ID: From: "Olin Macias" To: Subject: Your order Date: Thu, 1 Nov 2007 15:04:06 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_E6A7_01C81CD3.2BCA8930" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_E6A7_01C81CD3.2BCA8930 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_E6A7_01C81CD3.2BCA8930 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_E6A7_01C81CD3.2BCA8930-- From nemo-bounces@ietf.org Fri Nov 02 01:36:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InpAc-0001cK-RR; Fri, 02 Nov 2007 01:34:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InpAZ-0001aT-7N; Fri, 02 Nov 2007 01:34:11 -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 1InpAX-0000k7-LT; Fri, 02 Nov 2007 01:34:11 -0400 Received: from [IPv6:2001:200:0:8801:211:25ff:fe1d:e74b] (unknown [IPv6:2001:200:0:8801:211:25ff:fe1d:e74b]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 641E54D96E; Fri, 2 Nov 2007 14:33:52 +0900 (JST) Message-ID: <472AB4D9.30507@sfc.wide.ad.jp> Date: Fri, 02 Nov 2007 14:25:45 +0900 From: Shinta Sugimoto User-Agent: Mozilla Thunderbird 1.0.2 (X11/20070820) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj Patil Subject: [nemo] Re: [Mip6] Please review and provide input to DSMIP6-IKEv2 discussion X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham and all, Thanks for the summary and excuse me for responding late. I went through all the emails concerning the topic of DSMIPv6 and IKE. Let me state my opinion. In conclusion, I prefer solution 1. It seems that there is no optimal solution to solve the problem. Ultimately, to achieve address-family-agnostic IP mobility with the support of network layer security (payload protection by IPsec) in a *clean* way, MOBIKE would be the best choice, I believe. And IMHO, we should note this fact when choosing the solution. Please note that I am NOT saying that DSMIPv6 is not needed at all. DSMIPv6 and MOBIKE are meant to solve different problems and have different properties. And thus we need a solution for DSMIPv6 to solve the problem that has been discussed in the mailing list. IMHO, we should take the arpproach that modifies DSMIPv6 rather than IKE because the approach of making modifications to IKE would never be superior to MOBIKE, anyway. For this reason, I prefer solution 1. However, I need one clarification on solution 1. How would IKE run initially (at the bootstrap stage)? In solution 1, it is assumed that IKE runs over MIPv6, i.e., IKE chooses home address as an IKE/IPsec endpoint. Then there is an obvious chicken-and-egg problem because IKE relies on MIPv6 and MIPv6 relies on IPsec (i.e., IKE). The implication is that IKE cannot be initiated in the bootstrapping stage, unless some exceptional handling is done. In bootstrapping, there is no MIPv6 home registration made yet, thus there is no home address available. I am not sure if such operation of IKE - establishing IPsec SA whose endpoint is an IP address which is not working/available at the point of IPsec SA negotiation - is permitted or not. If not, then solution 1 should be excluded from the candidate solution. If yes, then the specification should address how IKE negotiation is done in the bootstrapping stage. Another implication of solution 1 is that MN cannot bootstrap from IPv4 private networks because we don't assume IKE to handle NAT. Regards, Shinta Basavaraj Patil wrote: > > Hello, > > I would like to encourage more people on the MIP6 and NEMO lists to review > the discussion related to DSMIP6 and IKEv2 and the issue that was raised > earlier as well as the proposed solutions. > Please provide your feedback to the ML. > > At the present time there are only a handful of people commenting and it is > difficult to gauge consensus as a result. > > I have also requested a couple of IKE experts (Tero Kivinen and Pasi Eronen) > to review and provide input. > > -Basavaraj > > > On 10/25/07 9:01 AM, "ext Hesham Soliman" wrote: > > >>Folks, >> >>This discussion has been going on for a while and I'm sure it wasn't for >>easy to follow. >>This email contains a summary of the discussion so far and a call for >>comment/concensus. Please respond promptly because there is some pressure >>from 3GPP to get this draft out very soon. >> >>The issue is how to run IKE in combination with DSMIPv6 in a private >>IPv4-only network. If you want more detail about why this is a problem >>please look at the thread "DSMIPv6 and IKE". >> >>There are three types of solutions that we discussed. A quick summary of >>each below: >> >>1. The Virtual link approach. In this case IKE runs over v6 only and is >>completely unaware of the IPv4 network. As a result IKE's NAT traversal is >>never invoked. Only DSMIPv6's NAT traversal is used. In this approach, the >>DSMIPv6 implementation in the HA is required to cache the outer IPv4 address >>and source port of the IPv4 message that contains IKE, then append them to >>the response from its own IKE daemon. This is basically done to hide the >>IPv4 network from IKE and effectively disable its NAT traversal, which >>solves our problem. >>Three people agreed with this approach but two people (I'm including >>Christian) are against it. So there doesn't seem to be concensus on this. I >>believe the concern here was that the HA's caching of the outer address and >>port was complex for the implementation. >> >>2. Karen suggested a way of running IKE without any changes (again see the >>thread for details). In this approach DSMIPv6 BUs are secured with ESP as >>usual. Normal traffic is sent over the DSMIPv6 port. However, secure traffic >>is sent over the IKE port (4500). The result of this approach is that it >>takes two messages to complete a handover, one from DSMIPv6 (BU) and an >>update from IKE (for the secure traffic). The concern that I had here in the >>discussion with Karen was the number of messages and the delays associated >>for that. Of course IKE doesn't do movement detection ...etc. So my concern >>is the discriminatory experience of the handover for different parts of the >>traffic. >> >>3. The third class of solutions involves either modifying MIPv6 (adding new >>messages) or IKE or both. I'm only including this for completeness, no one >>really wants this. >> >>Please send your comments on the above. Basically the options are 1 or 2. In >>theory we could do both but I think it's best to pick one method for this to >>avoid interoperability issues and additional complexity. >> >>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 nemo-bounces@ietf.org Fri Nov 02 02: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 1Inq7V-00006i-MI; Fri, 02 Nov 2007 02:35:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inq7U-0008TE-Iw; Fri, 02 Nov 2007 02:35:04 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Inq7G-0002AW-8z; Fri, 02 Nov 2007 02:34:56 -0400 Received: from oaamta08sl.mx.bigpond.com ([124.190.106.219]) by omta04sl.mx.bigpond.com with ESMTP id <20071102063406.FQEZ1805.omta04sl.mx.bigpond.com@oaamta08sl.mx.bigpond.com>; Fri, 2 Nov 2007 06:34:06 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta08sl.mx.bigpond.com with ESMTP id <20071102063405.DNLL10966.oaamta08sl.mx.bigpond.com@PC20005>; Fri, 2 Nov 2007 06:34:05 +0000 From: "Hesham Soliman" To: "'Shinta Sugimoto'" Date: Fri, 2 Nov 2007 17:33:53 +1000 Message-ID: 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: AcgdEgAyxok7dOiETimGfXihs/g0HgAECbew X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <472AB4D9.30507@sfc.wide.ad.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: nemo@ietf.org, mip6@ietf.org, 'Basavaraj Patil' Subject: [nemo] RE: [Mip6] Please review and provide input to DSMIP6-IKEv2 discussion X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Shinta, Please see my response below > In conclusion, I prefer solution 1. => ok. > IMHO, we should take the arpproach that modifies DSMIPv6 > rather than IKE because the approach of making modifications > to IKE would never be superior to MOBIKE, anyway. For > this reason, I prefer solution 1. => ok. > > However, I need one clarification on solution 1. How > would IKE run initially (at the bootstrap stage)? > In solution 1, it is assumed that IKE runs over MIPv6, > i.e., IKE chooses home address as an IKE/IPsec endpoint. > Then there is an obvious chicken-and-egg problem because > IKE relies on MIPv6 and MIPv6 relies on IPsec (i.e., IKE). > The implication is that IKE cannot be initiated in the > bootstrapping stage, unless some exceptional handling > is done. In bootstrapping, there is no MIPv6 home > registration made yet, thus there is no home address > available. => I think given that we're not allowed to use a mapped address as a CoA, it should be understood that for DSMIPv6 to work there MUST be a home address known to the MN. I think this is bad news for DSMIPv6 but there is nothing I can do about it. So to answer your question, an IPv6 HoA must already be known. The rest of the handling is well know, the src address selection gives the IPv6 HoA to IKE (IKE need not *choose* it) and the HA side was explained in my email. Hesham > > > Regards, > Shinta > > Basavaraj Patil wrote: > > > > Hello, > > > > I would like to encourage more people on the MIP6 and NEMO > lists to review > > the discussion related to DSMIP6 and IKEv2 and the issue > that was raised > > earlier as well as the proposed solutions. > > Please provide your feedback to the ML. > > > > At the present time there are only a handful of people > commenting and it is > > difficult to gauge consensus as a result. > > > > I have also requested a couple of IKE experts (Tero > Kivinen and Pasi Eronen) > > to review and provide input. > > > > -Basavaraj > > > > > > On 10/25/07 9:01 AM, "ext Hesham Soliman" > wrote: > > > > > >>Folks, > >> > >>This discussion has been going on for a while and I'm sure > it wasn't for > >>easy to follow. > >>This email contains a summary of the discussion so far and > a call for > >>comment/concensus. Please respond promptly because there > is some pressure > >>from 3GPP to get this draft out very soon. > >> > >>The issue is how to run IKE in combination with DSMIPv6 in > a private > >>IPv4-only network. If you want more detail about why this > is a problem > >>please look at the thread "DSMIPv6 and IKE". > >> > >>There are three types of solutions that we discussed. A > quick summary of > >>each below: > >> > >>1. The Virtual link approach. In this case IKE runs over > v6 only and is > >>completely unaware of the IPv4 network. As a result IKE's > NAT traversal is > >>never invoked. Only DSMIPv6's NAT traversal is used. In > this approach, the > >>DSMIPv6 implementation in the HA is required to cache the > outer IPv4 address > >>and source port of the IPv4 message that contains IKE, > then append them to > >>the response from its own IKE daemon. This is basically > done to hide the > >>IPv4 network from IKE and effectively disable its NAT > traversal, which > >>solves our problem. > >>Three people agreed with this approach but two people (I'm > including > >>Christian) are against it. So there doesn't seem to be > concensus on this. I > >>believe the concern here was that the HA's caching of the > outer address and > >>port was complex for the implementation. > >> > >>2. Karen suggested a way of running IKE without any > changes (again see the > >>thread for details). In this approach DSMIPv6 BUs are > secured with ESP as > >>usual. Normal traffic is sent over the DSMIPv6 port. > However, secure traffic > >>is sent over the IKE port (4500). The result of this > approach is that it > >>takes two messages to complete a handover, one from > DSMIPv6 (BU) and an > >>update from IKE (for the secure traffic). The concern that > I had here in the > >>discussion with Karen was the number of messages and the > delays associated > >>for that. Of course IKE doesn't do movement detection > ...etc. So my concern > >>is the discriminatory experience of the handover for > different parts of the > >>traffic. > >> > >>3. The third class of solutions involves either modifying > MIPv6 (adding new > >>messages) or IKE or both. I'm only including this for > completeness, no one > >>really wants this. > >> > >>Please send your comments on the above. Basically the > options are 1 or 2. In > >>theory we could do both but I think it's best to pick one > method for this to > >>avoid interoperability issues and additional complexity. > >> > >>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 nemo-bounces@ietf.org Fri Nov 02 04:04:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InrTe-0007Pg-EE; Fri, 02 Nov 2007 04:02:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InrTc-0007MK-C6; Fri, 02 Nov 2007 04:02:00 -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 1InrTW-0004NH-PI; Fri, 02 Nov 2007 04:01:55 -0400 Received: from [IPv6:2001:200:0:8801:211:25ff:fe1d:e74b] (unknown [IPv6:2001:200:0:8801:211:25ff:fe1d:e74b]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 1D53E4D9B2; Fri, 2 Nov 2007 17:01:32 +0900 (JST) Message-ID: <472AD778.8070606@sfc.wide.ad.jp> Date: Fri, 02 Nov 2007 16:53:28 +0900 From: Shinta Sugimoto User-Agent: Mozilla Thunderbird 1.0.2 (X11/20070820) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nemo@ietf.org, mip6@ietf.org, 'Basavaraj Patil' Subject: [nemo] Re: [Mip6] Please review and provide input to DSMIP6-IKEv2 discussion X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham, Please find my comments below: Hesham Soliman wrote: (snip) > > However, I need one clarification on solution 1. How > > would IKE run initially (at the bootstrap stage)? > > In solution 1, it is assumed that IKE runs over MIPv6, > > i.e., IKE chooses home address as an IKE/IPsec endpoint. > > Then there is an obvious chicken-and-egg problem because > > IKE relies on MIPv6 and MIPv6 relies on IPsec (i.e., IKE). > > The implication is that IKE cannot be initiated in the > > bootstrapping stage, unless some exceptional handling > > is done. In bootstrapping, there is no MIPv6 home > > registration made yet, thus there is no home address > > available. > > => I think given that we're not allowed to use a mapped address as a CoA, it > should be understood that for DSMIPv6 to work there MUST be a home address > known to the MN. I think this is bad news for DSMIPv6 but there is nothing I > can do about it. Sorry, I don't follow. Could you please elaborate why the design choice made (to not use mapped address as a CoA) has an effect on the chicken-and-egg problem of IKE and DSMIPv6? > So to answer your question, an IPv6 HoA must already be > known. The rest of the handling is well know, the src address selection > gives the IPv6 HoA to IKE (IKE need not *choose* it) and the HA side was > explained in my email. Let me responde to your comments above, after I understand your earlier comments. Regards, Shinta From Kolonitskiykasagiannis@sibthorpe.com Fri Nov 02 09:21:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InwSQ-00058h-Pu for nemo-archive@lists.ietf.org; Fri, 02 Nov 2007 09:21:06 -0400 Received: from host202-186-dynamic.3-87-r.retail.telecomitalia.it ([87.3.186.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InwSP-0005mJ-7h for nemo-archive@lists.ietf.org; Fri, 02 Nov 2007 09:21:06 -0400 Received: from pcconfig by sibthorpe.com with ASMTP id 42CD3516 for ; Fri, 2 Nov 2007 14:21:31 +0100 Received: from pcconfig ([163.141.151.186]) by sibthorpe.com with ESMTP id FEEDDC965BEE for ; Fri, 2 Nov 2007 14:21:31 +0100 Message-ID: <000d01c81d53$3713ba70$caba0357@pcconfig> From: "Kolonitskiy kasagiannis" To: Subject: debraier Date: Fri, 2 Nov 2007 14:21:02 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C81D5B.98D82270" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0009_01C81D5B.98D82270 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hey darling nemo-archive confront your insecurities and do something about that tiny cock http://www.ezeyjob.com/ Kolonitskiy kasagiannis ------=_NextPart_000_0009_01C81D5B.98D82270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hey darling nemo-archive
confront your insecurities and do something = about that=20 tiny cock
http://www.ezeyjob.com/
Kolonitskiy = kasagiannis
------=_NextPart_000_0009_01C81D5B.98D82270-- From LowellomeletWebster@openratings.com Fri Nov 02 22:57:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io9Cj-0003cI-7G; Fri, 02 Nov 2007 22:57:45 -0400 Received: from i-83-67-44-40.freedom2surf.net ([83.67.44.40] helo=kewsls045.emeaaspac.ad.pegs.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Io9CT-0006Sn-Mx; Fri, 02 Nov 2007 22:57:30 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host88822086.openratings.com (8.13.1/8.13.1) with SMTP id CTaukjxv87.195371.JPw.dlX.7966647932221 for ; Sat, 3 Nov 2007 02:52:49 +0000 Message-ID: <63aa801c81dc4$ab3fa690$0201a8c0@kewsls045> From: "Myron Rios" To: Subject: Confirmation link Date: Sat, 3 Nov 2007 02:52:49 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_63AA4_01C81DC4.AB3FA690" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_63AA4_01C81DC4.AB3FA690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_63AA4_01C81DC4.AB3FA690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_63AA4_01C81DC4.AB3FA690-- From IrwingambitWoodward@hotel-atlantic.cz Sat Nov 03 01:44:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoBoV-00049O-Bx; Sat, 03 Nov 2007 01:44:55 -0400 Received: from [61.51.125.156] (helo=admin.domain) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IoBoP-0003Lb-7B; Sat, 03 Nov 2007 01:44:50 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host82620341.hotel-atlantic.cz (8.13.1/8.13.1) with SMTP id aAs9L4Pc55.929714.46J.y5v.1995854703891 for ; Sat, 3 Nov 2007 13:43:55 -0800 Message-ID: <39e5201c81ddc$9d2b9970$6501a8c0@Admin> From: "Kirby Woodward" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_39E4E_01C81DDC.9D2B9970-- From TerripluggableKessler@yogaholidays.net Sat Nov 03 05:41:11 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoFV8-0006pm-SJ; Sat, 03 Nov 2007 05:41:11 -0400 Received: from [221.134.70.98] (helo=itc254.agilis.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IoFV8-00020o-1J; Sat, 03 Nov 2007 05:41:10 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host80320906.yogaholidays.net (8.13.1/8.13.1) with SMTP id S6nFLFS748.730130.vLj.XKW.3063220478068 for ; Sat, 3 Nov 2007 05:36:17 +0500 Message-ID: <111a2401c81dfd$097d30f0$ce0110ac@ITC254> From: "Gina Locke" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_111A20_01C81DFD.097D30F0-- From ErvinheightPratt@vics.org Sat Nov 03 15:52:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoP2l-0003qG-MH; Sat, 03 Nov 2007 15:52:31 -0400 Received: from [151.63.181.12] (helo=casa) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IoP2j-0005Pg-RZ; Sat, 03 Nov 2007 15:52:31 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host62658930.vics.org (8.13.1/8.13.1) with SMTP id VULTVVDC45.215005.fRE.QOe.6151033832977 for ; Sat, 3 Nov 2007 20:52:19 -0100 Message-ID: <1622001c81e53$19454cb0$0cb53f97@casa> From: "Jody Schwartz" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_1621C_01C81E53.19454CB0-- From nemo-bounces@ietf.org Sat Nov 03 20:41:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoTYd-0002ur-DC; Sat, 03 Nov 2007 20:41:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoTYb-0002uQ-Bg; Sat, 03 Nov 2007 20:41:41 -0400 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IoTYZ-0001rk-Ft; Sat, 03 Nov 2007 20:41:41 -0400 Received: from oaamta04sl.mx.bigpond.com ([124.190.106.219]) by omta02sl.mx.bigpond.com with ESMTP id <20071104004136.EXXH22254.omta02sl.mx.bigpond.com@oaamta04sl.mx.bigpond.com>; Sun, 4 Nov 2007 00:41:36 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta04sl.mx.bigpond.com with ESMTP id <20071104004135.SFAE19591.oaamta04sl.mx.bigpond.com@PC20005>; Sun, 4 Nov 2007 00:41:35 +0000 From: "Hesham Soliman" To: "'Shinta Sugimoto'" Date: Sun, 4 Nov 2007 11:41:03 +1000 Message-ID: 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: AcgdJpcJcGSoBkRDT6Gw8F2VvYqjSgBXLuAg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <472AD778.8070606@sfc.wide.ad.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: nemo@ietf.org, mip6@ietf.org, 'Basavaraj Patil' Subject: [nemo] RE: [Mip6] Please review and provide input to DSMIP6-IKEv2 discussion X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > > However, I need one clarification on solution 1. How > > > would IKE run initially (at the bootstrap stage)? > > > In solution 1, it is assumed that IKE runs over MIPv6, > > > i.e., IKE chooses home address as an IKE/IPsec endpoint. > > > Then there is an obvious chicken-and-egg problem because > > > IKE relies on MIPv6 and MIPv6 relies on IPsec (i.e., IKE). > > > The implication is that IKE cannot be initiated in the > > > bootstrapping stage, unless some exceptional handling > > > is done. In bootstrapping, there is no MIPv6 home > > > registration made yet, thus there is no home address > > > available. > > > > => I think given that we're not allowed to use a mapped > address as a CoA, it > > should be understood that for DSMIPv6 to work there MUST > be a home address > > known to the MN. I think this is bad news for DSMIPv6 but > there is nothing I > > can do about it. > > Sorry, I don't follow. Could you please elaborate why the design > choice made (to not use mapped address as a CoA) has an effect on > the chicken-and-egg problem of IKE and DSMIPv6? => If I understood you correctly you were saying that when IKE is run, there is no home registration and therefore there is no home address. So I thought you were saying that because of that reason IKE cannot run using the IPv6 home address. So my answer is that we can't run IKE over an IPv6 CoA anyway because we don't have one. So we have to run it over the HoA, which implies that a HoA has to be known to the MN already and not through IKE. Hesham From Rehbergdjbg@arfp.org Sun Nov 04 00:16:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoWuK-0002qr-VQ for nemo-archive@lists.ietf.org; Sun, 04 Nov 2007 00:16:20 -0400 Received: from host88-96-dynamic.20-87-r.retail.telecomitalia.it ([87.20.96.88]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IoWuK-0001W0-7u for nemo-archive@lists.ietf.org; Sun, 04 Nov 2007 00:16:20 -0400 Received: from rosanna-c168af6 ([160.190.93.133] helo=rosanna-c168af6) by [87.20.96.88] ( sendmail 8.13.3/8.13.1) with esmtpa id 1kZjgn-000ZXQ-uQ for nemo-archive@lists.ietf.org; Sun, 4 Nov 2007 05:17:03 +0100 Message-ID: Date: Sun, 4 Nov 2007 05:16:25 +0100 From: "jeranne Rehberg" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: ajedulre Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hello Society nemo-archive make your little soldier serve better when you add some length to it http://faomron.com/ jeranne Rehberg From ReynaremusBoudreaux@bomberblitz.com Sun Nov 04 03:45:33 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iob6r-0004yA-OH; Sun, 04 Nov 2007 03:45:33 -0500 Received: from 237-137-135-64.gray-ng.dsl.pinetreenetworks.com ([64.135.137.237] helo=d76bdv51) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iob6r-0005TE-5c; Sun, 04 Nov 2007 03:45:33 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host72817578.bomberblitz.com (8.13.1/8.13.1) with SMTP id lzCHO7j000.187712.BIW.HsN.9758135783103 for ; Sun, 4 Nov 2007 03:44:59 +0500 Message-ID: <12791901c81ebf$0775da10$0201a8c0@D76BDV51> From: "Lolita Chu" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_127915_01C81EBF.0775DA10-- From agnes51irving5@articlesandcontent.com Sun Nov 04 04:35:51 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IobtX-0000ql-Bf for nemo-archive@lists.ietf.org; Sun, 04 Nov 2007 04:35:51 -0500 Received: from [124.216.249.129] (helo=124.216.249.129) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IobtW-00047V-Ld for nemo-archive@lists.ietf.org; Sun, 04 Nov 2007 04:35:51 -0500 Received: from [124.216.249.129] by ksabv.articlesandcontent.com; Mon, 05 Nov 2007 02:35:06 +0000 Message-ID: <000a01c81f54$0490263f$f1728abc@ahatkms> From: "ely dunbar" To: "Julie Payne" Subject: We specialize in the sales of brand-name quality Date: Mon, 05 Nov 2007 00:47:44 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C81F54.048FB9E1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 2.7 (++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C81F54.048FB9E1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Perfectly crafted luxury timepieces, all at affordable prices. Thousands = of different models to choose from! http://noicagio.com/ ------=_NextPart_000_0007_01C81F54.048FB9E1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Perfectly crafted luxury timepieces, all at affordable prices. Thousands = of different models to choose from!

http://noicagio.com/ ------=_NextPart_000_0007_01C81F54.048FB9E1-- From heman@osolemio.com Sun Nov 04 12:17:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ioj6a-0002N6-CI for nemo-archive@lists.ietf.org; Sun, 04 Nov 2007 12:17:48 -0500 Received: from dkv163.neoplus.adsl.tpnet.pl ([83.24.25.163]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ioj6Z-0006QO-RH for nemo-archive@lists.ietf.org; Sun, 04 Nov 2007 12:17:48 -0500 Received: from amd ([194.142.192.13]:26253 "EHLO amd" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by dkv163.neoplus.adsl.tpnet.pl with ESMTP id S22JDTFRLXHMWQVR (ORCPT ); Sun, 4 Nov 2007 18:18:22 +0100 Message-ID: <000c01c81f06$a59a0b20$a3191853@amd> From: "Kala heman" To: nemo-archive@lists.ietf.org Subject: utiliser Date: Sun, 4 Nov 2007 18:17:58 +0100 Message-ID: <000c01c81f06$a59a0b20$a3191853@amd> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea hallo buddy nemo-archive work hard, play hard and fuck hard when you take MANSTER http://www.hahoomap.com/ Kala heman From ElenaupstaterKern@flickr.com Sun Nov 04 15:42:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IomIb-0003aG-VY; Sun, 04 Nov 2007 15:42:26 -0500 Received: from 137.red-83-49-22.dynamicip.rima-tde.net ([83.49.22.137] helo=desktop) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IomIb-0006Nw-DC; Sun, 04 Nov 2007 15:42:25 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host81491260.flickr.com (8.13.1/8.13.1) with SMTP id 9Nbdr1lb53.478560.LQg.k2e.2846662999199 for ; Sun, 4 Nov 2007 21:41:53 -0100 Message-ID: <7f5601c81f23$2cb190d0$2101a8c0@desktop> From: "Mable Bloom" To: Subject: Your life Date: Sun, 4 Nov 2007 21:41:53 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_7F52_01C81F23.2CB190D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_7F52_01C81F23.2CB190D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_7F52_01C81F23.2CB190D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_7F52_01C81F23.2CB190D0-- From nemo-bounces@ietf.org Sun Nov 04 21:26: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 1IorfU-00078V-73; Sun, 04 Nov 2007 21:26:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IorfS-00075T-8b; Sun, 04 Nov 2007 21:26:22 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IorfR-0008Ld-DX; Sun, 04 Nov 2007 21:26:22 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lA52PucU006272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 4 Nov 2007 18:25:57 -0800 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lA52Pum7024390; Sun, 4 Nov 2007 18:25:56 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Nov 2007 18:25:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Please review and provide input to DSMIP6-IKEv2 discussion Date: Sun, 4 Nov 2007 18:25:54 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Please review and provide input to DSMIP6-IKEv2 discussion Thread-Index: AcgXD2Nk409BdK32Rr+w24XNw+KidQEZ7tPIAPU2yCA= References: From: "Narayanan, Vidya" To: "Basavaraj Patil" , "ext Hesham Soliman" , , X-OriginalArrivalTime: 05 Nov 2007 02:25:56.0131 (UTC) FILETIME=[31FA8F30:01C81F53] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org All, After all these iterations we've had, Alternative #2 sounds the best to me. However, I think the recommended mode of operation to update a tunnel mode SA should be to use MOBIKE. This way, the update is only 1RT and can happen in parallel with the BU/BA update. Also, there is no mandate to only use transport mode SA for BU/BA exchange - if a tunnel mode SA is in use for that, the IKE SA will have to be first updated before the BU/BA can even be exchanged from the new attachment point. So, in all these cases, the use of MOBIKE is a better approach. Of course, we wouldn't need to mandate MOBIKE - when it is not supported, a transport mode SA for BU/BA, along with a sequential IKE update or a parallel full IKEv2 exchange can be done. =20 Also, one other point to note is that the MIP6 update is only needed when there is unprotected data exchange. In a case where all the data exchange is protected using IPsec, the MOBIKE update is sufficient. The MIP6 update can happen later when required. So, in essence, the IKE SA update is more time critical for protected traffic. In reverse, the MIP6 update is more time critical for unprotected traffic, as has already been pointed out. =20 We also need to describe the process properly so that implementations can accept the IPsec BU/BA that are not exchanged on port 4500 (apart from running it by the IPsec community :)).=20 Regards, Vidya > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Tuesday, October 30, 2007 9:33 PM > To: ext Hesham Soliman; mip6@ietf.org; nemo@ietf.org > Subject: [nemo] Please review and provide input to=20 > DSMIP6-IKEv2 discussion >=20 >=20 >=20 > Hello, >=20 > I would like to encourage more people on the MIP6 and NEMO=20 > lists to review the discussion related to DSMIP6 and IKEv2=20 > and the issue that was raised earlier as well as the proposed=20 > solutions. > Please provide your feedback to the ML. >=20 > At the present time there are only a handful of people=20 > commenting and it is difficult to gauge consensus as a result. >=20 > I have also requested a couple of IKE experts (Tero Kivinen=20 > and Pasi Eronen) to review and provide input. >=20 > -Basavaraj >=20 >=20 > On 10/25/07 9:01 AM, "ext Hesham Soliman"=20 > wrote: >=20 > > Folks, > >=20 > > This discussion has been going on for a while and I'm sure=20 > it wasn't=20 > > for easy to follow. > > This email contains a summary of the discussion so far and=20 > a call for=20 > > comment/concensus. Please respond promptly because there is some=20 > > pressure from 3GPP to get this draft out very soon. > >=20 > > The issue is how to run IKE in combination with DSMIPv6 in=20 > a private=20 > > IPv4-only network. If you want more detail about why this=20 > is a problem=20 > > please look at the thread "DSMIPv6 and IKE". > >=20 > > There are three types of solutions that we discussed. A=20 > quick summary=20 > > of each below: > >=20 > > 1. The Virtual link approach. In this case IKE runs over v6=20 > only and=20 > > is completely unaware of the IPv4 network. As a result IKE's NAT=20 > > traversal is never invoked. Only DSMIPv6's NAT traversal is=20 > used. In=20 > > this approach, the > > DSMIPv6 implementation in the HA is required to cache the=20 > outer IPv4=20 > > address and source port of the IPv4 message that contains IKE, then=20 > > append them to the response from its own IKE daemon. This=20 > is basically=20 > > done to hide the > > IPv4 network from IKE and effectively disable its NAT=20 > traversal, which=20 > > solves our problem. > > Three people agreed with this approach but two people (I'm including > > Christian) are against it. So there doesn't seem to be concensus on=20 > > this. I believe the concern here was that the HA's caching of the=20 > > outer address and port was complex for the implementation. > >=20 > > 2. Karen suggested a way of running IKE without any changes=20 > (again see=20 > > the thread for details). In this approach DSMIPv6 BUs are=20 > secured with=20 > > ESP as usual. Normal traffic is sent over the DSMIPv6 port.=20 > However,=20 > > secure traffic is sent over the IKE port (4500). The result of this=20 > > approach is that it takes two messages to complete a handover, one=20 > > from DSMIPv6 (BU) and an update from IKE (for the secure=20 > traffic). The=20 > > concern that I had here in the discussion with Karen was=20 > the number of=20 > > messages and the delays associated for that. Of course IKE=20 > doesn't do=20 > > movement detection ...etc. So my concern is the discriminatory=20 > > experience of the handover for different parts of the traffic. > >=20 > > 3. The third class of solutions involves either modifying MIPv6=20 > > (adding new > > messages) or IKE or both. I'm only including this for=20 > completeness, no=20 > > one really wants this. > >=20 > > Please send your comments on the above. Basically the=20 > options are 1 or=20 > > 2. In theory we could do both but I think it's best to pick=20 > one method=20 > > for this to avoid interoperability issues and additional complexity. > >=20 > > Hesham > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 From aree@aliax.dk Mon Nov 05 01:47:18 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iovjy-00022I-OZ for nemo-archive@lists.ietf.org; Mon, 05 Nov 2007 01:47:18 -0500 Received: from host-84-222-246-126.cust-adsl.tiscali.it ([84.222.246.126]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iovjy-0005OO-4u for nemo-archive@lists.ietf.org; Mon, 05 Nov 2007 01:47:18 -0500 Received: from Arcuri ([132.165.118.131] helo=Arcuri) by [84.222.246.126] ( sendmail 8.13.3/8.13.1) with esmtpa id 1ODVvm-000CRV-rO for nemo-archive@lists.ietf.org; Mon, 5 Nov 2007 07:47:48 +0100 Message-ID: <000301c81f77$b2b51400$7ef6de54@Arcuri> From: "aree kosmicki" To: Subject: iyorduof Date: Mon, 5 Nov 2007 07:47:13 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C81F80.14797C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0004_01C81F80.14797C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello darling nemo-archive love your new size and use it fully when you take MANSTER http://www.hjdhf.com/ aree kosmicki ------=_NextPart_000_0004_01C81F80.14797C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello darling nemo-archive
love your new size and use it fully when you = take=20 MANSTER
http://www.hjdhf.com/
aree kosmicki
------=_NextPart_000_0004_01C81F80.14797C00-- From shannan68arash09@cen.quik.com Mon Nov 05 04:27:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoyEw-0003WH-Bq for nemo-archive@lists.ietf.org; Mon, 05 Nov 2007 04:27:26 -0500 Received: from host217-43-78-199.range217-43.btcentralplus.com ([217.43.78.199]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IoyEv-0000cy-Uj for nemo-archive@lists.ietf.org; Mon, 05 Nov 2007 04:27:26 -0500 Received: from [217.43.78.199] by eqsqv.cen.quik.com; Mon, 05 Nov 2007 09:28:36 +0000 Message-ID: <000601c81f8e$04275a9f$03dfb58a@xptxtce> From: "korey paddy" To: "Gary Pickett" Subject: Shop around for luxury items Date: Mon, 05 Nov 2007 07:41:13 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C81F8E.04268CA5" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C81F8E.04268CA5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Perfectly crafted luxury timepieces, all at affordable prices. Thousands = of different models to choose from! http://noicagio.com/ ------=_NextPart_000_0003_01C81F8E.04268CA5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Perfectly crafted luxury timepieces, all at affordable prices. Thousands = of different models to choose from!

http://noicagio.com/ ------=_NextPart_000_0003_01C81F8E.04268CA5-- From CathyconnectKatz@readwriteweb.com Mon Nov 05 06:23:24 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip03A-0003jh-PG; Mon, 05 Nov 2007 06:23:24 -0500 Received: from [75.128.55.90] (helo=banks) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ip03A-0003Cy-7J; Mon, 05 Nov 2007 06:23:24 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host63245205.readwriteweb.com (8.13.1/8.13.1) with SMTP id M0addjpz72.022779.S9d.bja.4924218449260 for ; Mon, 5 Nov 2007 03:22:59 +0800 Message-ID: <9df3701c81f9e$43f98920$6f1ea8c0@Banks> From: "Samantha Pierson" To: Subject: Your life Date: Mon, 5 Nov 2007 03:22:59 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_9DF33_01C81F9E.43F98920" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_9DF33_01C81F9E.43F98920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_9DF33_01C81F9E.43F98920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_9DF33_01C81F9E.43F98920-- From Forbismxco@DESTINY.CO.IN Mon Nov 05 07:43:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip1ID-0003nN-RV for nemo-archive@lists.ietf.org; Mon, 05 Nov 2007 07:43:01 -0500 Received: from host193-241-dynamic.20-87-r.retail.telecomitalia.it ([87.20.241.193] helo=host167-243-dynamic.16-87-r.retail.telecomitalia.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip1IC-0005cB-4s for nemo-archive@lists.ietf.org; Mon, 05 Nov 2007 07:43:01 -0500 Received: by 10.64.47.81 with SMTP id WBPOYJdudWySh; Mon, 5 Nov 2007 13:43:06 +0100 (GMT) Received: by 192.168.190.226 with SMTP id xKLpVPWWFftXfZ.7964321537956; Mon, 5 Nov 2007 13:43:04 +0100 (GMT) Message-ID: <7FCEE382.CFDD90B5@DESTINY.CO.IN> Date: Mon, 5 Nov 2007 13:43:01 +0100 From: "Veriton Forbis" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: ejtleviu Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.4 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea hello honey nemo-archive she might give you another chance if you improve you penis size :) http://www.jamadeo.com/ Veriton Forbis From nemo-bounces@ietf.org Mon Nov 05 14:02: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 1Ip7DC-0000la-NU; Mon, 05 Nov 2007 14:02:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip7DB-0000kq-EU; Mon, 05 Nov 2007 14:02:13 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip7DB-00089n-2K; Mon, 05 Nov 2007 14:02:13 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Nov 2007 11:02:11 -0800 Message-ID: <472F68B2.1060105@azairenet.com> Date: Mon, 05 Nov 2007 11:02:10 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Shinta Sugimoto References: <472AB4D9.30507@sfc.wide.ad.jp> In-Reply-To: <472AB4D9.30507@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2007 19:02:11.0440 (UTC) FILETIME=[5ED6DF00:01C81FDE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] Re: [Mip6] Please review and provide input to DSMIP6-IKEv2 discussion X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Shinta Sugimoto wrote: > However, I need one clarification on solution 1. How > would IKE run initially (at the bootstrap stage)? > In solution 1, it is assumed that IKE runs over MIPv6, > i.e., IKE chooses home address as an IKE/IPsec endpoint. > Then there is an obvious chicken-and-egg problem because > IKE relies on MIPv6 and MIPv6 relies on IPsec (i.e., IKE). > The implication is that IKE cannot be initiated in the > bootstrapping stage, unless some exceptional handling > is done. In bootstrapping, there is no MIPv6 home > registration made yet, thus there is no home address > available. I am not sure if such operation of IKE - > establishing IPsec SA whose endpoint is an IP address > which is not working/available at the point of IPsec > SA negotiation - is permitted or not. If not, then > solution 1 should be excluded from the candidate solution. > If yes, then the specification should address how IKE > negotiation is done in the bootstrapping stage. > Another implication of solution 1 is that MN cannot > bootstrap from IPv4 private networks because we don't > assume IKE to handle NAT. You would not be able to bootstrap the home address using IKEv2 with solution 1. Vijay From nemo-bounces@ietf.org Mon Nov 05 14:06:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip7H5-00040B-5o; Mon, 05 Nov 2007 14:06:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip7H3-0003yp-Cm; Mon, 05 Nov 2007 14:06:13 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip7H2-0008Fw-H5; Mon, 05 Nov 2007 14:06:13 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Nov 2007 11:06:11 -0800 Message-ID: <472F69A3.5090400@azairenet.com> Date: Mon, 05 Nov 2007 11:06:11 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2007 19:06:12.0017 (UTC) FILETIME=[EE3C0210:01C81FDE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj Patil X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Narayanan, Vidya wrote: > All, > After all these iterations we've had, Alternative #2 sounds the best to > me. Ok. > However, I think the recommended mode of operation to update a > tunnel mode SA should be to use MOBIKE. Disagree. If there is no NAT, the tunnel mode SAs can be updated based on just the BU/BAck exchange. > This way, the update is only > 1RT and can happen in parallel with the BU/BA update. Also, there is no > mandate to only use transport mode SA for BU/BA exchange - if a tunnel > mode SA is in use for that, the IKE SA will have to be first updated > before the BU/BA can even be exchanged from the new attachment point. There is no issue at all with a transport mode SA based on the IPv6 home address for protecting the BU. So why would we want to send it using a tunnel mode SA? > So, in all these cases, the use of MOBIKE is a better approach. Of > course, we wouldn't need to mandate MOBIKE - when it is not supported, a > transport mode SA for BU/BA, along with a sequential IKE update or a > parallel full IKEv2 exchange can be done. > > Also, one other point to note is that the MIP6 update is only needed > when there is unprotected data exchange. In a case where all the data > exchange is protected using IPsec, the MOBIKE update is sufficient. The > MIP6 update can happen later when required. So, in essence, the IKE SA > update is more time critical for protected traffic. In reverse, the > MIP6 update is more time critical for unprotected traffic, as has > already been pointed out. You should write this up in a separate draft as an alternative. :) > We also need to describe the process properly so that implementations > can accept the IPsec BU/BA that are not exchanged on port 4500 (apart > from running it by the IPsec community :)). Yes, we should add text on this. Vijay > > Regards, > Vidya > > > -----Original Message----- > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > Sent: Tuesday, October 30, 2007 9:33 PM > > To: ext Hesham Soliman; mip6@ietf.org; nemo@ietf.org > > Subject: [nemo] Please review and provide input to > > DSMIP6-IKEv2 discussion > > > > > > > > Hello, > > > > I would like to encourage more people on the MIP6 and NEMO > > lists to review the discussion related to DSMIP6 and IKEv2 > > and the issue that was raised earlier as well as the proposed > > solutions. > > Please provide your feedback to the ML. > > > > At the present time there are only a handful of people > > commenting and it is difficult to gauge consensus as a result. > > > > I have also requested a couple of IKE experts (Tero Kivinen > > and Pasi Eronen) to review and provide input. > > > > -Basavaraj > > > > > > On 10/25/07 9:01 AM, "ext Hesham Soliman" > > wrote: > > > > > Folks, > > > > > > This discussion has been going on for a while and I'm sure > > it wasn't > > > for easy to follow. > > > This email contains a summary of the discussion so far and > > a call for > > > comment/concensus. Please respond promptly because there is some > > > pressure from 3GPP to get this draft out very soon. > > > > > > The issue is how to run IKE in combination with DSMIPv6 in > > a private > > > IPv4-only network. If you want more detail about why this > > is a problem > > > please look at the thread "DSMIPv6 and IKE". > > > > > > There are three types of solutions that we discussed. A > > quick summary > > > of each below: > > > > > > 1. The Virtual link approach. In this case IKE runs over v6 > > only and > > > is completely unaware of the IPv4 network. As a result IKE's NAT > > > traversal is never invoked. Only DSMIPv6's NAT traversal is > > used. In > > > this approach, the > > > DSMIPv6 implementation in the HA is required to cache the > > outer IPv4 > > > address and source port of the IPv4 message that contains IKE, then > > > append them to the response from its own IKE daemon. This > > is basically > > > done to hide the > > > IPv4 network from IKE and effectively disable its NAT > > traversal, which > > > solves our problem. > > > Three people agreed with this approach but two people (I'm including > > > Christian) are against it. So there doesn't seem to be concensus on > > > this. I believe the concern here was that the HA's caching of the > > > outer address and port was complex for the implementation. > > > > > > 2. Karen suggested a way of running IKE without any changes > > (again see > > > the thread for details). In this approach DSMIPv6 BUs are > > secured with > > > ESP as usual. Normal traffic is sent over the DSMIPv6 port. > > However, > > > secure traffic is sent over the IKE port (4500). The result of this > > > approach is that it takes two messages to complete a handover, one > > > from DSMIPv6 (BU) and an update from IKE (for the secure > > traffic). The > > > concern that I had here in the discussion with Karen was > > the number of > > > messages and the delays associated for that. Of course IKE > > doesn't do > > > movement detection ...etc. So my concern is the discriminatory > > > experience of the handover for different parts of the traffic. > > > > > > 3. The third class of solutions involves either modifying MIPv6 > > > (adding new > > > messages) or IKE or both. I'm only including this for > > completeness, no > > > one really wants this. > > > > > > Please send your comments on the above. Basically the > > options are 1 or > > > 2. In theory we could do both but I think it's best to pick > > one method > > > for this to avoid interoperability issues and additional complexity. > > > > > > 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 RickeypennantSalazar@freedomship.com Mon Nov 05 16:12:16 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip9F1-00045H-UN; Mon, 05 Nov 2007 16:12:16 -0500 Received: from c-24-147-156-249.hsd1.ma.comcast.net ([24.147.156.249] helo=dbkyfg51.hsd1.ma.comcast.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ip9F0-0003W1-RU; Mon, 05 Nov 2007 16:12:14 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host28752229.freedomship.com (8.13.1/8.13.1) with SMTP id cW7oBqW880.258114.vLN.s0I.8165108501370 for ; Mon, 5 Nov 2007 16:11:40 +0500 Message-ID: From: "Cesar Santos" To: Subject: Your family Date: Mon, 5 Nov 2007 16:11:40 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_CF8C_01C81FF0.7FE36440" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_CF8C_01C81FF0.7FE36440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_CF8C_01C81FF0.7FE36440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_CF8C_01C81FF0.7FE36440-- From RalphdesecratePeterson@metacritic.com Mon Nov 05 17:44:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpAgk-0002l6-1O; Mon, 05 Nov 2007 17:44:58 -0500 Received: from static-200-105-204-194.acelerate.net ([200.105.204.194] helo=wssuper.lpz.spvs) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IpAgi-00067f-H4; Mon, 05 Nov 2007 17:44:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host50253925.metacritic.com (8.13.1/8.13.1) with SMTP id ae93FrDp91.690413.SNi.52P.2986510580254 for ; Mon, 5 Nov 2007 18:44:20 +0400 Message-ID: <1446701c81ffd$7a693000$b83ba8c0@WSSUPER> From: "Brandon Peterson" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_14463_01C81FFD.7A693000-- From ClevelandsongbookBond@haha.nu Mon Nov 05 17:55:09 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpAqb-0007jK-B0; Mon, 05 Nov 2007 17:55:09 -0500 Received: from [164.113.217.238] (helo=jimmy.bartonccc.edu) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IpAqb-0007Vi-1C; Mon, 05 Nov 2007 17:55:09 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host54542953.haha.nu (8.13.1/8.13.1) with SMTP id UPcrEeEc26.109695.bPU.IAX.5177131440628 for ; Mon, 5 Nov 2007 17:54:51 +0500 Message-ID: <2b50601c81ffe$ea39cd30$1c53500a@Jimmy> From: "Hans Gaines" To: Subject: Approval process Date: Mon, 5 Nov 2007 17:54:51 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_2B502_01C81FFE.EA39CD30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_2B502_01C81FFE.EA39CD30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_2B502_01C81FFE.EA39CD30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_2B502_01C81FFE.EA39CD30-- From MilestrolleyRoman@closer.com Mon Nov 05 21:19:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpE2R-0004HR-Vy; Mon, 05 Nov 2007 21:19:36 -0500 Received: from [201.234.98.39] (helo=pc) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IpE2R-0005B5-1y; Mon, 05 Nov 2007 21:19:35 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host78625062.closer.com (8.13.1/8.13.1) with SMTP id enWTzpWq92.310830.VUS.apD.3784325314950 for ; Mon, 5 Nov 2007 23:19:10 +0300 Message-ID: From: "Otto Acosta" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_ED68_01C8201B.801A1D20-- From ElenaslothfulBloom@nature.com Tue Nov 06 01:02:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpHWM-0003fv-1A; Tue, 06 Nov 2007 01:02:42 -0500 Received: from 11.80.242.24.cfl.res.rr.com ([24.242.80.11] helo=sergiopc) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IpHWL-0002Fe-BZ; Tue, 06 Nov 2007 01:02:41 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host17973147.nature.com (8.13.1/8.13.1) with SMTP id goreWWOG26.003628.iq3.UlS.5004438303032 for ; Tue, 6 Nov 2007 00:58:19 +0600 Message-ID: <2950801c82042$d0fe8290$0301a8c0@sergioPC> From: "Lora Starks" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_29504_01C82042.D0FE8290-- From Pellandxmnc@cccoutdoors.com Tue Nov 06 02:06:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpIW2-0004TD-Ac for nemo-archive@lists.ietf.org; Tue, 06 Nov 2007 02:06:26 -0500 Received: from acba207.neoplus.adsl.tpnet.pl ([83.9.98.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpIVx-00045l-7m for nemo-archive@lists.ietf.org; Tue, 06 Nov 2007 02:06:26 -0500 Received: from sp-05f5ac344592 ([157.133.43.37] helo=sp-05f5ac344592) by acba207.neoplus.adsl.tpnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1VAMrK-000GUW-Ju for nemo-archive@lists.ietf.org; Tue, 6 Nov 2007 08:11:48 +0100 Date: Tue, 6 Nov 2007 08:11:25 +0100 From: "kdsfj Pelland" Reply-To: "kdsfj Pelland" Message-ID: <309501931851.245538993051@cccoutdoors.com> To: Subject: mnomihci MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original X-Spam-Score: 3.9 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Nice to meet you nemo-archive more than often, having a big cock earns you points with the ladies http://www.iyouher.com/ kdsfj Pelland From mext-bounces@ietf.org Tue Nov 06 04:20:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpKb6-00060V-9e; Tue, 06 Nov 2007 04:19:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpKaB-0005Xd-GW; Tue, 06 Nov 2007 04:18:51 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpKaB-0007bP-4N; Tue, 06 Nov 2007 04:18:51 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id E32002800034D; Tue, 6 Nov 2007 10:18:49 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkNX6E0Fruc6; Tue, 6 Nov 2007 10:18:49 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id CFDF128000340; Tue, 6 Nov 2007 10:18:39 +0100 (CET) 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, 6 Nov 2007 10:18:39 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF316FB8@mx1.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nemo/Mext meeting at IETF-70? Thread-Index: AcggVgRN0c21g2c6RoWByH6zMpVPbQ== From: "Roberto Baldessari" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-Mailman-Approved-At: Tue, 06 Nov 2007 04:19:47 -0500 Cc: Subject: [MEXT] Nemo/Mext meeting at IETF-70? 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 all, According to the IETF draft agenda, no NEMO nor MEXT WG meeting has been = scheduled yet. Are there plans to have one at IETF-70? Concerning the activity on automotive requirements for NEMO RO, we are = in the process to update the doc according to the feedback we got at = IETF-69 and preparing it to include/unify requirements from both C2C-CC = and ISO CALM. Anyway, as (I guess) the contributions from CALM won't be ready in time = for IETF-70, I don't have anything against waiting until IETF-71 to = present a more complete document. Also, I hope that by then MEXT WG will = be actually in place. Best regards, Roberto =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Roberto Baldessari Research Scientist NEC Laboratories, Network Division, NEC Europe Ltd. Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-167 Fax: +49 (0)6221 4342-55 e-mail: roberto.baldessari@nw.neclab.eu=20 web: http://www.netlab.nec.de/ NEC Europe Limited | Registered Office:=20 NEC House, 1 Victoria Road, London W3 6BL=20 Registered in England 2832014=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From nemo-bounces@ietf.org Tue Nov 06 11:20: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 1IpRAc-0003Me-RG; Tue, 06 Nov 2007 11:20:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpRAc-0003Ls-4Q; Tue, 06 Nov 2007 11:20:54 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpRAY-0008Ix-Qv; Tue, 06 Nov 2007 11:20:54 -0500 Received: from [127.0.0.1] ([98.207.201.188]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 08:20:49 -0800 Message-ID: <47309460.5030303@azairenet.com> Date: Tue, 06 Nov 2007 08:20:48 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Roberto Baldessari References: <5F6519BF2DE0404D99B7C75607FF76FF316FB8@mx1.office> In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF316FB8@mx1.office> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2007 16:20:49.0947 (UTC) FILETIME=[FEA206B0:01C82090] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: nemo@ietf.org, mext@ietf.org Subject: [nemo] Re: [MEXT] Nemo/Mext meeting at IETF-70? X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org There are two slots each 2.5 hours for MIP6. These are for MEXT. Vijay Roberto Baldessari wrote: > > > Hi all, > > According to the IETF draft agenda, no NEMO nor MEXT WG meeting has been > scheduled yet. Are there plans to have one at IETF-70? > > Concerning the activity on automotive requirements for NEMO RO, we are > in the process to update the doc according to the feedback we got at > IETF-69 and preparing it to include/unify requirements from both C2C-CC > and ISO CALM. > > Anyway, as (I guess) the contributions from CALM won't be ready in time > for IETF-70, I don't have anything against waiting until IETF-71 to > present a more complete document. Also, I hope that by then MEXT WG will > be actually in place. > > Best regards, > > Roberto > > > ================================================ > Roberto Baldessari > Research Scientist > NEC Laboratories, Network Division, NEC Europe Ltd. > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-167 > Fax: +49 (0)6221 4342-55 > e-mail: roberto.baldessari@nw.neclab.eu > web: http://www.netlab.nec.de/ > > NEC Europe Limited | Registered Office: > NEC House, 1 Victoria Road, London W3 6BL > Registered in England 2832014 > ================================================ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > From mext-bounces@ietf.org Tue Nov 06 11:21:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpRAd-0003Mj-5B; Tue, 06 Nov 2007 11:20:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpRAc-0003Ls-4Q; Tue, 06 Nov 2007 11:20:54 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpRAY-0008Ix-Qv; Tue, 06 Nov 2007 11:20:54 -0500 Received: from [127.0.0.1] ([98.207.201.188]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 08:20:49 -0800 Message-ID: <47309460.5030303@azairenet.com> Date: Tue, 06 Nov 2007 08:20:48 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Roberto Baldessari Subject: Re: [MEXT] Nemo/Mext meeting at IETF-70? References: <5F6519BF2DE0404D99B7C75607FF76FF316FB8@mx1.office> In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF316FB8@mx1.office> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2007 16:20:49.0947 (UTC) FILETIME=[FEA206B0:01C82090] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: nemo@ietf.org, 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 are two slots each 2.5 hours for MIP6. These are for MEXT. Vijay Roberto Baldessari wrote: > > > Hi all, > > According to the IETF draft agenda, no NEMO nor MEXT WG meeting has been > scheduled yet. Are there plans to have one at IETF-70? > > Concerning the activity on automotive requirements for NEMO RO, we are > in the process to update the doc according to the feedback we got at > IETF-69 and preparing it to include/unify requirements from both C2C-CC > and ISO CALM. > > Anyway, as (I guess) the contributions from CALM won't be ready in time > for IETF-70, I don't have anything against waiting until IETF-71 to > present a more complete document. Also, I hope that by then MEXT WG will > be actually in place. > > Best regards, > > Roberto > > > ================================================ > Roberto Baldessari > Research Scientist > NEC Laboratories, Network Division, NEC Europe Ltd. > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-167 > Fax: +49 (0)6221 4342-55 > e-mail: roberto.baldessari@nw.neclab.eu > web: http://www.netlab.nec.de/ > > NEC Europe Limited | Registered Office: > NEC House, 1 Victoria Road, London W3 6BL > Registered in England 2832014 > ================================================ > > _______________________________________________ > 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 guhlkekjnhy@allstargenetics.com Tue Nov 06 14:33:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpUAg-0003Fu-DU for nemo-archive@lists.ietf.org; Tue, 06 Nov 2007 14:33:10 -0500 Received: from host-78-12-30-213.cust-adsl.tiscali.it ([78.12.30.213] helo=host-84-221-229-20.cust-adsl.tiscali.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpUAf-0000jG-QN for nemo-archive@lists.ietf.org; Tue, 06 Nov 2007 14:33:10 -0500 Received: from masterxp by allstargenetics.com with ASMTP id CBAF1D1F for ; Tue, 6 Nov 2007 20:36:04 +0100 Received: from masterxp ([142.189.172.3]) by allstargenetics.com with ESMTP id A1DB70BEC690 for ; Tue, 6 Nov 2007 20:36:04 +0100 Message-ID: <000b01c820ac$3e9d7770$14e5dd54@masterxp> From: "garriq guhlke" To: Subject: mis-entr Date: Tue, 6 Nov 2007 20:35:53 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C820B4.A061DF70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.3 (++++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0009_01C820B4.A061DF70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello you nemo-archive A lady can sence a confident man, and they like it. http://kumsc.com/ garriq guhlke ------=_NextPart_000_0009_01C820B4.A061DF70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello you nemo-archive
A lady can sence a confident man, and they = like=20 it.
http://kumsc.com/
garriq guhlke
------=_NextPart_000_0009_01C820B4.A061DF70-- From nemo-bounces@ietf.org Tue Nov 06 15:07: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 1IpUiL-0007u2-61; Tue, 06 Nov 2007 15:07:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpUiI-0007ss-Gd; Tue, 06 Nov 2007 15:07:54 -0500 Received: from [2001:14b8:400::130] (helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpUiI-0006BO-2F; Tue, 06 Nov 2007 15:07:54 -0500 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 658E51986C6; Tue, 6 Nov 2007 22:07:53 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 07ED019867C; Tue, 6 Nov 2007 22:07:53 +0200 (EET) Message-ID: <4730B613.9060909@piuha.net> Date: Tue, 06 Nov 2007 19:44:35 +0100 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] Re: [MEXT] Nemo/Mext meeting at IETF-70? References: <5F6519BF2DE0404D99B7C75607FF76FF316FB8@mx1.office> <47309460.5030303@azairenet.com> In-Reply-To: <47309460.5030303@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: nemo@ietf.org, Roberto Baldessari , mext@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Right. MEXT will have 5 hours of meeting time in Vancouver. The main hold up for the mext work to progress has been me; I haven't made the final chair decisions or done the charter edits that were left pending after IETF-69. Sorry, too many other things on my plate -- but the group should be operational in Vancouver. Jari Vijay Devarapalli kirjoitti: > There are two slots each 2.5 hours for MIP6. These are for MEXT. > > Vijay > > Roberto Baldessari wrote: >> >> >> Hi all, >> >> According to the IETF draft agenda, no NEMO nor MEXT WG meeting has >> been scheduled yet. Are there plans to have one at IETF-70? >> >> Concerning the activity on automotive requirements for NEMO RO, we >> are in the process to update the doc according to the feedback we got >> at IETF-69 and preparing it to include/unify requirements from both >> C2C-CC and ISO CALM. >> >> Anyway, as (I guess) the contributions from CALM won't be ready in >> time for IETF-70, I don't have anything against waiting until IETF-71 >> to present a more complete document. Also, I hope that by then MEXT >> WG will be actually in place. >> >> Best regards, >> >> Roberto >> >> >> ================================================ >> Roberto Baldessari >> Research Scientist >> NEC Laboratories, Network Division, NEC Europe Ltd. >> Kurfuerstenanlage 36, D-69115 Heidelberg >> Tel. +49 (0)6221 4342-167 >> Fax: +49 (0)6221 4342-55 >> e-mail: roberto.baldessari@nw.neclab.eu >> web: http://www.netlab.nec.de/ >> >> NEC Europe Limited | Registered Office: >> NEC House, 1 Victoria Road, London W3 6BL >> Registered in England 2832014 >> ================================================ >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext >> > > > > From mext-bounces@ietf.org Tue Nov 06 15:08:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpUiK-0007t5-Hq; Tue, 06 Nov 2007 15:07:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpUiI-0007ss-Gd; Tue, 06 Nov 2007 15:07:54 -0500 Received: from [2001:14b8:400::130] (helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpUiI-0006BO-2F; Tue, 06 Nov 2007 15:07:54 -0500 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 658E51986C6; Tue, 6 Nov 2007 22:07:53 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 07ED019867C; Tue, 6 Nov 2007 22:07:53 +0200 (EET) Message-ID: <4730B613.9060909@piuha.net> Date: Tue, 06 Nov 2007 19:44:35 +0100 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] Re: [MEXT] Nemo/Mext meeting at IETF-70? References: <5F6519BF2DE0404D99B7C75607FF76FF316FB8@mx1.office> <47309460.5030303@azairenet.com> In-Reply-To: <47309460.5030303@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: nemo@ietf.org, Roberto Baldessari , 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 Right. MEXT will have 5 hours of meeting time in Vancouver. The main hold up for the mext work to progress has been me; I haven't made the final chair decisions or done the charter edits that were left pending after IETF-69. Sorry, too many other things on my plate -- but the group should be operational in Vancouver. Jari Vijay Devarapalli kirjoitti: > There are two slots each 2.5 hours for MIP6. These are for MEXT. > > Vijay > > Roberto Baldessari wrote: >> >> >> Hi all, >> >> According to the IETF draft agenda, no NEMO nor MEXT WG meeting has >> been scheduled yet. Are there plans to have one at IETF-70? >> >> Concerning the activity on automotive requirements for NEMO RO, we >> are in the process to update the doc according to the feedback we got >> at IETF-69 and preparing it to include/unify requirements from both >> C2C-CC and ISO CALM. >> >> Anyway, as (I guess) the contributions from CALM won't be ready in >> time for IETF-70, I don't have anything against waiting until IETF-71 >> to present a more complete document. Also, I hope that by then MEXT >> WG will be actually in place. >> >> Best regards, >> >> Roberto >> >> >> ================================================ >> Roberto Baldessari >> Research Scientist >> NEC Laboratories, Network Division, NEC Europe Ltd. >> Kurfuerstenanlage 36, D-69115 Heidelberg >> Tel. +49 (0)6221 4342-167 >> Fax: +49 (0)6221 4342-55 >> e-mail: roberto.baldessari@nw.neclab.eu >> web: http://www.netlab.nec.de/ >> >> NEC Europe Limited | Registered Office: >> NEC House, 1 Victoria Road, London W3 6BL >> Registered in England 2832014 >> ================================================ >> >> _______________________________________________ >> 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 nemo-bounces@ietf.org Tue Nov 06 20:01: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 1IpZIW-0006wj-3k; Tue, 06 Nov 2007 20:01:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpZIU-0006tx-Dr; Tue, 06 Nov 2007 20:01:34 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpZIT-0003iu-Fi; Tue, 06 Nov 2007 20:01:34 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lA710M5R023606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Nov 2007 17:00:22 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lA710ATI005799; Tue, 6 Nov 2007 17:00:21 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 17:00:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion Date: Tue, 6 Nov 2007 17:00:19 -0800 Message-ID: In-Reply-To: <472F69A3.5090400@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion Thread-Index: Acgf3vpROArryX5BQVWxlfpVbhnTQgA+HKxw References: <472F69A3.5090400@azairenet.com> From: "Narayanan, Vidya" To: "Vijay Devarapalli" X-OriginalArrivalTime: 07 Nov 2007 01:00:20.0586 (UTC) FILETIME=[91C814A0:01C820D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj Patil X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org =20 > > However, I think the recommended mode of operation to=20 > update a tunnel=20 > > mode SA should be to use MOBIKE. >=20 > Disagree. If there is no NAT, the tunnel mode SAs can be=20 > updated based on just the BU/BAck exchange. >=20 Yes, but, the case under discussion here is the case when there is a NAT and in that case, the IKE_SA update is important for protected traffic. > > This way, the update is only > > 1RT and can happen in parallel with the BU/BA update. =20 > Also, there is=20 > > no mandate to only use transport mode SA for BU/BA exchange - if a=20 > > tunnel mode SA is in use for that, the IKE SA will have to be first=20 > > updated before the BU/BA can even be exchanged from the new=20 > attachment point. >=20 > There is no issue at all with a transport mode SA based on=20 > the IPv6 home address for protecting the BU. So why would we=20 > want to send it using a tunnel mode SA? >=20 I'm not talking theory here. The spec does not mandate a transport mode SA for BU/BA exchange. Hence, we do need to understand what happens when tunnel mode is used. And, tunnel mode can be used if someone wishes to protect MIP6 signaling and data, all with the same SA. No reason to have a separate transport mode SA for the signaling. =20 > > So, in all these cases, the use of MOBIKE is a better approach. Of=20 > > course, we wouldn't need to mandate MOBIKE - when it is not=20 > supported,=20 > > a transport mode SA for BU/BA, along with a sequential IKE=20 > update or a=20 > > parallel full IKEv2 exchange can be done. > >=20 > > Also, one other point to note is that the MIP6 update is=20 > only needed=20 > > when there is unprotected data exchange. In a case where=20 > all the data=20 > > exchange is protected using IPsec, the MOBIKE update is=20 > sufficient. =20 > > The > > MIP6 update can happen later when required. So, in=20 > essence, the IKE=20 > > SA update is more time critical for protected traffic. In reverse,=20 > > the > > MIP6 update is more time critical for unprotected traffic, as has=20 > > already been pointed out. >=20 > You should write this up in a separate draft as an alternative. :) >=20 Thanks for the suggestion (hint: I disagree :)). We are not mandating MOBIKE here - but, it would make sense to recommend it for updating tunnel mode SAs in the presence of NATs. So, I don't understand the issue of not making use of something that works and is available. You can always not support MOBIKE in your implementation if that's what you are concerned about.=20 Vidya From nemo-bounces@ietf.org Tue Nov 06 21:42: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 1IpasA-00036z-M9; Tue, 06 Nov 2007 21:42:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipas8-00035q-Bh; Tue, 06 Nov 2007 21:42:28 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ipas7-00087X-Lf; Tue, 06 Nov 2007 21:42:28 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 18:42:26 -0800 Message-ID: <47312611.5050205@azairenet.com> Date: Tue, 06 Nov 2007 18:42:25 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion References: <472F69A3.5090400@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2007 02:42:26.0208 (UTC) FILETIME=[D4EFD200:01C820E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj Patil X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Narayanan, Vidya wrote: > >>> However, I think the recommended mode of operation to >> update a tunnel >>> mode SA should be to use MOBIKE. >> Disagree. If there is no NAT, the tunnel mode SAs can be >> updated based on just the BU/BAck exchange. >> > > Yes, but, the case under discussion here is the case when there is a NAT > and in that case, the IKE_SA update is important for protected traffic. > > >>> This way, the update is only >>> 1RT and can happen in parallel with the BU/BA update. >> Also, there is >>> no mandate to only use transport mode SA for BU/BA exchange - if a >>> tunnel mode SA is in use for that, the IKE SA will have to be first >>> updated before the BU/BA can even be exchanged from the new >> attachment point. >> >> There is no issue at all with a transport mode SA based on >> the IPv6 home address for protecting the BU. So why would we >> want to send it using a tunnel mode SA? >> > > I'm not talking theory here. The spec does not mandate a transport mode > SA for BU/BA exchange. Hence, we do need to understand what happens > when tunnel mode is used. And, tunnel mode can be used if someone > wishes to protect MIP6 signaling and data, all with the same SA. No > reason to have a separate transport mode SA for the signaling. But the transport mode SA is not dependent on updating the IPsec or the IKEv2 SA. The BU/BAck exchange can be completed right away after a handover using the transport mode SA. I would not complicate that part. >> So, in all these cases, the use of MOBIKE is a better approach. Of >>> course, we wouldn't need to mandate MOBIKE - when it is not >> supported, >>> a transport mode SA for BU/BA, along with a sequential IKE >> update or a >>> parallel full IKEv2 exchange can be done. >>> >>> Also, one other point to note is that the MIP6 update is >> only needed >>> when there is unprotected data exchange. In a case where >> all the data >>> exchange is protected using IPsec, the MOBIKE update is >> sufficient. >>> The >>> MIP6 update can happen later when required. So, in >> essence, the IKE >>> SA update is more time critical for protected traffic. In reverse, >>> the >>> MIP6 update is more time critical for unprotected traffic, as has >>> already been pointed out. >> You should write this up in a separate draft as an alternative. :) >> > Thanks for the suggestion (hint: I disagree :)). We are not mandating > MOBIKE here - but, it would make sense to recommend it for updating > tunnel mode SAs in the presence of NATs. So, I don't understand the > issue of not making use of something that works and is available. You > can always not support MOBIKE in your implementation if that's what you > are concerned about. We need a mechanism that works without MOBIKE. Period. You are free to write up another document that describes how MOBIKE helps in improving the situation. Vijay From MinervalettuceXiong@williecrawford.com Wed Nov 07 00:14:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpdFM-0001r4-5k; Wed, 07 Nov 2007 00:14:36 -0500 Received: from firewall.dataflux.com.mx ([200.23.36.3] helo=fernandomoralesventasom) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IpdFL-0005Nz-TG; Wed, 07 Nov 2007 00:14:36 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host92636473.williecrawford.com (8.13.1/8.13.1) with SMTP id k3PcbUkw48.221994.zg6.pis.5060768676268 for ; Tue, 6 Nov 2007 23:13:54 +0600 Message-ID: <174f701c820fd$0e6b31e0$330ba8c0@FernandoMoralesVentasOM> From: "Greta Swenson" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_174F3_01C820FD.0E6B31E0-- From nemo-bounces@ietf.org Wed Nov 07 00:21: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 1IpdM8-0000c5-SA; Wed, 07 Nov 2007 00:21:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpdM7-0000b2-E2; Wed, 07 Nov 2007 00:21:35 -0500 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 1IpdM5-0000jY-G8; Wed, 07 Nov 2007 00:21:35 -0500 Received: from [IPv6:2001:380:633:2:20b:cdff:fefb:2a8] (unknown [IPv6:2001:380:633:2:20b:cdff:fefb:2a8]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 029014D895; Wed, 7 Nov 2007 14:21:28 +0900 (JST) Message-ID: <47314B51.80800@sfc.wide.ad.jp> Date: Wed, 07 Nov 2007 14:21:21 +0900 From: Shinta Sugimoto User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: nemo@ietf.org, mip6@ietf.org, 'Basavaraj Patil' Subject: [nemo] Re: [Mip6] Please review and provide input to DSMIP6-IKEv2 discussion X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hello Hesham, Sorry for the delay in my response. Please find my comments inline. Hesham Soliman wrote: > > > > However, I need one clarification on solution 1. How > > > > would IKE run initially (at the bootstrap stage)? > > > > In solution 1, it is assumed that IKE runs over MIPv6, > > > > i.e., IKE chooses home address as an IKE/IPsec endpoint. > > > > Then there is an obvious chicken-and-egg problem because > > > > IKE relies on MIPv6 and MIPv6 relies on IPsec (i.e., IKE). > > > > The implication is that IKE cannot be initiated in the > > > > bootstrapping stage, unless some exceptional handling > > > > is done. In bootstrapping, there is no MIPv6 home > > > > registration made yet, thus there is no home address > > > > available. > > > > > > => I think given that we're not allowed to use a mapped > > address as a CoA, it > > > should be understood that for DSMIPv6 to work there MUST > > be a home address > > > known to the MN. I think this is bad news for DSMIPv6 but > > there is nothing I > > > can do about it. > > > > Sorry, I don't follow. Could you please elaborate why the design > > choice made (to not use mapped address as a CoA) has an effect on > > the chicken-and-egg problem of IKE and DSMIPv6? > > => If I understood you correctly you were saying that when IKE is run, there > is no home registration and therefore there is no home address. Yes, you are right. > So I thought > you were saying that because of that reason IKE cannot run using the IPv6 > home address. Partially correct. There are two different use of IP address that we should look at: A) IKE endpoint and B) IPsec SA endpoint address. (Note that I am giving an example of establishing ESP transport mode SA pair) Under the scenario of solution 1, as for A), there is no possibility of using home address since it is not routable. The only possible option for A) is to choose a working IP address (could be care-of address, of course) to run IKE. On the other hand, as for B), the home address of the mobile node may be specified, even though the home address is not available yet. I examined feasibility of solution 1 and came to the following conclusion. In my understanding, the solution 1 should work (on MN) as below: (1) MN bootstraps. Neither home address assignment nor IPsec SA establishment is done yet. (2) IKEv2 is triggered somehow. (3) IKE_AUTH message exhcnage is made in which home address assignment is done by configuration payload. (4) IPsec SA (ESP transport mode) is established. (5) MIPv6 module sends the initial BU to the HA which is protected by the (6) IKE module updates the IKE endpoint with the home address subsequently, IKE runs on top of MIPv6, hence there is no need for updating the IKE endpoint nor IPsec SA endpoint addresses. IPsec SA for protecting user traffic (ESP in tunnel mode) may be established, if necessary. So, I don't think that there is no significant limitation in solution 1. Home address assignment can be done through IKEv2 as usual. The only prerequisite is that IKE runs without any help from MIPv6 at the beginning, and then migrate its endpoint (IKE endpoint) to the home address. Does this make sense? > So my answer is that we can't run IKE over an IPv6 CoA anyway > because we don't have one. In your statement above, which kind of address A) or B) are you talking about? > So we have to run it over the HoA, which implies > that a HoA has to be known to the MN already and not through IKE. I hope my explanation above replies to your comments. Regards, Shinta From nemo-bounces@ietf.org Wed Nov 07 00:37: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 1Ipdbc-0000OJ-9m; Wed, 07 Nov 2007 00:37:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipdba-0000Jj-Kk; Wed, 07 Nov 2007 00:37:34 -0500 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 1Ipdba-00019s-1E; Wed, 07 Nov 2007 00:37:34 -0500 Received: from [IPv6:2001:380:633:2:20b:cdff:fefb:2a8] (unknown [IPv6:2001:380:633:2:20b:cdff:fefb:2a8]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 096434D8AE; Wed, 7 Nov 2007 14:37:33 +0900 (JST) Message-ID: <47314F1B.5050104@sfc.wide.ad.jp> Date: Wed, 07 Nov 2007 14:37:31 +0900 From: Shinta Sugimoto User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli References: <472AB4D9.30507@sfc.wide.ad.jp> <472F68B2.1060105@azairenet.com> In-Reply-To: <472F68B2.1060105@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] Re: [Mip6] Please review and provide input to DSMIP6-IKEv2 discussion X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Vijay, Vijay Devarapalli wrote: > Shinta Sugimoto wrote: > >> However, I need one clarification on solution 1. How >> would IKE run initially (at the bootstrap stage)? >> In solution 1, it is assumed that IKE runs over MIPv6, >> i.e., IKE chooses home address as an IKE/IPsec endpoint. >> Then there is an obvious chicken-and-egg problem because >> IKE relies on MIPv6 and MIPv6 relies on IPsec (i.e., IKE). >> The implication is that IKE cannot be initiated in the >> bootstrapping stage, unless some exceptional handling >> is done. In bootstrapping, there is no MIPv6 home >> registration made yet, thus there is no home address >> available. I am not sure if such operation of IKE - >> establishing IPsec SA whose endpoint is an IP address >> which is not working/available at the point of IPsec >> SA negotiation - is permitted or not. If not, then >> solution 1 should be excluded from the candidate solution. >> If yes, then the specification should address how IKE >> negotiation is done in the bootstrapping stage. >> Another implication of solution 1 is that MN cannot >> bootstrap from IPv4 private networks because we don't >> assume IKE to handle NAT. > > > You would not be able to bootstrap the home address using IKEv2 with > solution 1. I am afraid the above is not true. Could you check my reponse to Hesham, and hear me if you can agree? Regards, Shinta From nemo-bounces@ietf.org Wed Nov 07 01:21:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpeHc-0007ML-QH; Wed, 07 Nov 2007 01:21:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpeHb-0007JJ-0H; Wed, 07 Nov 2007 01:20:59 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpeHa-0007kt-BT; Wed, 07 Nov 2007 01:20:58 -0500 Received: from [127.0.0.1] ([98.207.201.188]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 22:20:57 -0800 Message-ID: <4731592D.7060007@azairenet.com> Date: Tue, 06 Nov 2007 22:20:29 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Shinta Sugimoto References: <47314B51.80800@sfc.wide.ad.jp> In-Reply-To: <47314B51.80800@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2007 06:20:57.0452 (UTC) FILETIME=[5BD8E2C0:01C82106] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] Re: [Mip6] Please review and provide input to DSMIP6-IKEv2 discussion X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Shinta Sugimoto wrote: > Hello Hesham, > > Sorry for the delay in my response. Please find my comments inline. > > Hesham Soliman wrote: > > > > > However, I need one clarification on solution 1. How > > > > > would IKE run initially (at the bootstrap stage)? > > > > > In solution 1, it is assumed that IKE runs over MIPv6, > > > > > i.e., IKE chooses home address as an IKE/IPsec endpoint. > > > > > Then there is an obvious chicken-and-egg problem because > > > > > IKE relies on MIPv6 and MIPv6 relies on IPsec (i.e., IKE). > > > > > The implication is that IKE cannot be initiated in the > > > > > bootstrapping stage, unless some exceptional handling > > > > > is done. In bootstrapping, there is no MIPv6 home > > > > > registration made yet, thus there is no home address > > > > > available. > > > > > > > > => I think given that we're not allowed to use a mapped > > > address as a CoA, it > > > > should be understood that for DSMIPv6 to work there MUST > > > be a home address > > > > known to the MN. I think this is bad news for DSMIPv6 but > > > there is nothing I > > > > can do about it. > > > > > > Sorry, I don't follow. Could you please elaborate why the design > > > choice made (to not use mapped address as a CoA) has an effect on > > > the chicken-and-egg problem of IKE and DSMIPv6? > > > > => If I understood you correctly you were saying that when IKE is > run, there > > is no home registration and therefore there is no home address. > > Yes, you are right. > > > So I thought > > you were saying that because of that reason IKE cannot run using the IPv6 > > home address. > > Partially correct. There are two different use of IP address that > we should look at: A) IKE endpoint and B) IPsec SA endpoint address. > (Note that I am giving an example of establishing ESP transport mode > SA pair) Under the scenario of solution 1, as for A), there is no > possibility of using home address since it is not routable. The only > possible option for A) is to choose a working IP address (could be > care-of address, of course) to run IKE. On the other hand, as for B), > the home address of the mobile node may be specified, even though > the home address is not available yet. > > I examined feasibility of solution 1 and came to the following > conclusion. In my understanding, the solution 1 should work > (on MN) as below: > > (1) MN bootstraps. Neither home address assignment nor IPsec SA > establishment is done yet. > (2) IKEv2 is triggered somehow. > (3) IKE_AUTH message exhcnage is made in which home address > assignment is done by configuration payload. This is not possible. The way I understand solution 1, IKEv2 is run on top of the DS-MIPv6 tunnel using the home address of the mobile node as the IKEv2 end point. The resulting IKEv2 SA is based on the home address of the mobile node. Forget the IPsec SA. I don't see how you can request for the home address and at the same time base the IKEv2 SA on the home address. In regular MIPv6, the IKEv2 SA is always based on the care-of address of the mobile node. Or did I got solution 1 wrong? Vijay > (4) IPsec SA (ESP transport mode) is established. > (5) MIPv6 module sends the initial BU to the HA which is protected > by the > (6) IKE module updates the IKE endpoint with the home address > > subsequently, IKE runs on top of MIPv6, hence there is no need > for updating the IKE endpoint nor IPsec SA endpoint addresses. > IPsec SA for protecting user traffic (ESP in tunnel mode) may > be established, if necessary. > > So, I don't think that there is no significant limitation in > solution 1. Home address assignment can be done through IKEv2 > as usual. > > The only prerequisite is that IKE runs without any help from > MIPv6 at the beginning, and then migrate its endpoint (IKE > endpoint) to the home address. > > Does this make sense? > > > So my answer is that we can't run IKE over an IPv6 CoA anyway > > because we don't have one. > > In your statement above, which kind of address A) or B) are you > talking about? > > > So we have to run it over the HoA, which implies > > that a HoA has to be known to the MN already and not through IKE. > > I hope my explanation above replies to your comments. > > > Regards, > Shinta > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > From nemo-bounces@ietf.org Wed Nov 07 01:36:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpeW7-0007Vw-C0; Wed, 07 Nov 2007 01:35:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpeW4-0007N4-K1; Wed, 07 Nov 2007 01:35:56 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpeW1-000356-31; Wed, 07 Nov 2007 01:35:56 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lA76YotI018133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Nov 2007 22:34:52 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lA76Yn3q002048; Tue, 6 Nov 2007 22:34:49 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 22:34:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion Date: Tue, 6 Nov 2007 22:34:02 -0800 Message-ID: In-Reply-To: <47312611.5050205@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion Thread-Index: Acgg59lODAMDBJ13TZKMXz+2xr5dbwAH3cFA References: <472F69A3.5090400@azairenet.com> <47312611.5050205@azairenet.com> From: "Narayanan, Vidya" To: "Vijay Devarapalli" X-OriginalArrivalTime: 07 Nov 2007 06:34:04.0073 (UTC) FILETIME=[30B5B990:01C82108] X-Spam-Score: -4.0 (----) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj Patil X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > I'm not talking theory here. The spec does not mandate a transport=20 > > mode SA for BU/BA exchange. Hence, we do need to understand what=20 > > happens when tunnel mode is used. And, tunnel mode can be used if=20 > > someone wishes to protect MIP6 signaling and data, all with=20 > the same=20 > > SA. No reason to have a separate transport mode SA for the=20 > signaling. >=20 > But the transport mode SA is not dependent on updating the=20 > IPsec or the IKEv2 SA. The BU/BAck exchange can be completed=20 > right away after a handover using the transport mode SA. I=20 > would not complicate that part. >=20 Who said anything about complicating the transport mode operation? Are you reading things I didn't write? You asked about why someone would use a tunnel mode SA and I was giving an example. =20 > >> So, in all these cases, the use of MOBIKE is a better approach. Of > >>> course, we wouldn't need to mandate MOBIKE - when it is not > >> supported, > >>> a transport mode SA for BU/BA, along with a sequential IKE > >> update or a > >>> parallel full IKEv2 exchange can be done. > >>> Please re-read the above paragraph I wrote in my first email.=20 =20 > We need a mechanism that works without MOBIKE. Period. You=20 > are free to write up another document that describes how=20 > MOBIKE helps in improving the situation. Thanks for informing me what I'm free to do! Things work without MOBIKE as I've said above. It is just not as efficient. For more efficient operation, the IKE SA update needs to be done using MOBIKE. There is no reason for a separate document on this. You should really get past your now long-term hangup on using MOBIKE along with MIP6 - this is a perfectly viable use case for it and there is absolutely no good reason to prevent it.=20 Vidya From nemo-bounces@ietf.org Wed Nov 07 01:45:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipeer-0000DO-9S; Wed, 07 Nov 2007 01:45:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipeep-0000Bk-3r; Wed, 07 Nov 2007 01:44:59 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ipeeo-0000DG-J3; Wed, 07 Nov 2007 01:44:59 -0500 Received: from [127.0.0.1] ([98.207.201.188]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 22:44:57 -0800 Message-ID: <47315ED2.1060807@azairenet.com> Date: Tue, 06 Nov 2007 22:44:34 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion References: <472F69A3.5090400@azairenet.com> <47312611.5050205@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2007 06:44:57.0880 (UTC) FILETIME=[B668C180:01C82109] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj Patil X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Narayanan, Vidya wrote: >>> I'm not talking theory here. The spec does not mandate a transport >>> mode SA for BU/BA exchange. Hence, we do need to understand what >>> happens when tunnel mode is used. And, tunnel mode can be used if >>> someone wishes to protect MIP6 signaling and data, all with >> the same >>> SA. No reason to have a separate transport mode SA for the >> signaling. >> >> But the transport mode SA is not dependent on updating the >> IPsec or the IKEv2 SA. The BU/BAck exchange can be completed >> right away after a handover using the transport mode SA. I >> would not complicate that part. >> > > Who said anything about complicating the transport mode operation? Are > you reading things I didn't write? You asked about why someone would use > a tunnel mode SA and I was giving an example. > >>>> So, in all these cases, the use of MOBIKE is a better approach. Of >>>>> course, we wouldn't need to mandate MOBIKE - when it is not >>>> supported, >>>>> a transport mode SA for BU/BA, along with a sequential IKE >>>> update or a >>>>> parallel full IKEv2 exchange can be done. >>>>> > > Please re-read the above paragraph I wrote in my first email. > > > >> We need a mechanism that works without MOBIKE. Period. You >> are free to write up another document that describes how >> MOBIKE helps in improving the situation. > > Thanks for informing me what I'm free to do! Things work without MOBIKE > as I've said above. It is just not as efficient. You missed what I was saying. The default operation for the use of IKEv2 with DS-MIPv6 should not assume MOBIKE functionality being used at the same time. If you think it is efficient to do that please do that in a separate document. Not in the DS-MIPv6 document. For more efficient > operation, the IKE SA update needs to be done using MOBIKE. There is no > reason for a separate document on this. You should really get past your > now long-term hangup on using MOBIKE along with MIP6 - this is a > perfectly viable use case for it and there is absolutely no good reason > to prevent it. Until now the binding update was sufficient to update the IKEv2 SA. But with the presence of NAT, the BU is not sufficient. You need to either re-run IKEv2 or use MOBIKE to update the IKEv2 SA. I agree with that. There is also another solution I had proposed where the HA treats the handover as if the intermediate NAT box lost state or rebooted and allocated a new NATed IP address and source port and accepts the traffic for a configurable amount of time while waiting for the IKEv2 SA to be re-keyed. This solution was proposed for the IPsec tunneled payload traffic. Vijay From nemo-bounces@ietf.org Wed Nov 07 01:49: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 1IpejI-00043V-J1; Wed, 07 Nov 2007 01:49:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpejH-00041I-09; Wed, 07 Nov 2007 01:49:35 -0500 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 1IpejG-0003ZR-Cu; Wed, 07 Nov 2007 01:49:34 -0500 Received: from [IPv6:2001:380:633:2:20b:cdff:fefb:2a8] (unknown [IPv6:2001:380:633:2:20b:cdff:fefb:2a8]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 95F984D8AC; Wed, 7 Nov 2007 15:49:32 +0900 (JST) Message-ID: <47315FFC.6040506@sfc.wide.ad.jp> Date: Wed, 07 Nov 2007 15:49:32 +0900 From: Shinta Sugimoto User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli References: <47314B51.80800@sfc.wide.ad.jp> <4731592D.7060007@azairenet.com> In-Reply-To: <4731592D.7060007@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] Re: [Mip6] Please review and provide input to DSMIP6-IKEv2 discussion X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Vijay Devarapalli wrote: >> I examined feasibility of solution 1 and came to the following >> conclusion. In my understanding, the solution 1 should work >> (on MN) as below: >> >> (1) MN bootstraps. Neither home address assignment nor IPsec SA >> establishment is done yet. >> (2) IKEv2 is triggered somehow. >> (3) IKE_AUTH message exhcnage is made in which home address >> assignment is done by configuration payload. > > > This is not possible. I believe it is possible, but I do agree that such operation is not normal at present. > The way I understand solution 1, IKEv2 is > run on top of the DS-MIPv6 tunnel using the home address of the > mobile node as the IKEv2 end point. Yes. That's correct. > The resulting IKEv2 SA is > based on the home address of the mobile node. Forget the IPsec > SA. Sorry, what do you mean by "Forget the IPsec SA."? > I don't see how you can request for the home address and at > the same time base the IKEv2 SA on the home address. As I wrote above, it can be done by using different IP address for IKE endpoint and IPsec SA endpoint address in the initial IKE negotiation. Could you explain why you think it is impossible? Do you see any violation of specification of IPsec/IKE? Or is there any flaw? > In regular MIPv6, the IKEv2 SA is always based on the care-of > address of the mobile node. You mean IKE SA, right? Then, yes, the IKE SA endpoint on the side of mobile node is normally the care-of address. In solution 1, both IKE SA and IPsec SA endpoint address are home address. Exceptionally, IKE chooses different IP address than home address for IKE SA endpoint in the bootstrap stage. That's how I see it. Regards, Shinta From nemo-bounces@ietf.org Wed Nov 07 02:32:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpfOh-0006pl-Dr; Wed, 07 Nov 2007 02:32:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpfOf-0006pU-Sy; Wed, 07 Nov 2007 02:32:21 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpfOf-00023G-6S; Wed, 07 Nov 2007 02:32:21 -0500 Received: from [127.0.0.1] ([98.207.201.188]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 23:32:20 -0800 Message-ID: <473169EC.1030509@azairenet.com> Date: Tue, 06 Nov 2007 23:31:56 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Shinta Sugimoto References: <47314B51.80800@sfc.wide.ad.jp> <4731592D.7060007@azairenet.com> <47315FFC.6040506@sfc.wide.ad.jp> In-Reply-To: <47315FFC.6040506@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2007 07:32:20.0300 (UTC) FILETIME=[549FA0C0:01C82110] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] Re: [Mip6] Please review and provide input to DSMIP6-IKEv2 discussion X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Shinta Sugimoto wrote: > Vijay Devarapalli wrote: > >>> I examined feasibility of solution 1 and came to the following >>> conclusion. In my understanding, the solution 1 should work >>> (on MN) as below: >>> >>> (1) MN bootstraps. Neither home address assignment nor IPsec SA >>> establishment is done yet. >>> (2) IKEv2 is triggered somehow. >>> (3) IKE_AUTH message exhcnage is made in which home address >>> assignment is done by configuration payload. >> >> >> This is not possible. > > I believe it is possible, but I do agree that such operation > is not normal at present. > >> The way I understand solution 1, IKEv2 is >> run on top of the DS-MIPv6 tunnel using the home address of the >> mobile node as the IKEv2 end point. > > Yes. That's correct. > >> The resulting IKEv2 SA is >> based on the home address of the mobile node. Forget the IPsec >> SA. > > Sorry, what do you mean by "Forget the IPsec SA."? > >> I don't see how you can request for the home address and at >> the same time base the IKEv2 SA on the home address. > > As I wrote above, it can be done by using different IP address > for IKE endpoint and IPsec SA endpoint address in the initial > IKE negotiation. Could you explain why you think it is impossible? > Do you see any violation of specification of IPsec/IKE? > Or is there any flaw? > >> In regular MIPv6, the IKEv2 SA is always based on the care-of >> address of the mobile node. > > You mean IKE SA, right? Then, yes, the IKE SA endpoint on the > side of mobile node is normally the care-of address. > > In solution 1, both IKE SA and IPsec SA endpoint address are > home address. Exceptionally, IKE chooses different IP address > than home address for IKE SA endpoint in the bootstrap stage. > That's how I see it. What is this different IP address? Vijay From mext-bounces@ietf.org Wed Nov 07 03:06: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 1Ipfvq-000073-Pf; Wed, 07 Nov 2007 03:06:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipfvo-00005g-U9 for mext@ietf.org; Wed, 07 Nov 2007 03:06:36 -0500 Received: from hpsmtp-eml14.kpnxchange.com ([213.75.38.114]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipfvk-00068K-C5 for mext@ietf.org; Wed, 07 Nov 2007 03:06:36 -0500 Received: from hpsmtp-eml01.kpnxchange.com ([213.75.38.101]) by hpsmtp-eml14.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 09:06:31 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml01.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 09:06:31 +0100 From: "Teco Boot" To: Date: Wed, 7 Nov 2007 09:06:20 +0100 Message-ID: <006c01c82115$1510ee00$3f32ca00$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcghFRSq01PY3uXhQw+MYBCdnAtJsA== Content-Language: nl X-OriginalArrivalTime: 07 Nov 2007 08:06:31.0229 (UTC) FILETIME=[1B128ED0:01C82115] X-Spam-Score: -1.0 (-) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [MEXT] MIP6 - DSMIP6 related to boot-nemo4manet 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, I published an Autoconf solution, based on what we can do with existing protocols as much as possible. http://www.ietf.org/internet-drafts/draft-boot-autoconf-nemo4manet-00.txt I used NEMO for dynamic tunneling between MANET Routers and Border Routers. The MANET Routers act as Mobile Routers; the Border Routers act as Home Agents. Nested NEMO is used for session continuity when handover occurs. Issue related to MIP6: I want Border Routers advertize not only that they provide access to Internet, but optionally also the identity of the Service Provider. I used draft-korhonen-mip6-service-04.txt as a guideline, signaling Service Selection Identifiers. Issues related to DSMIP6: In want the NEMO tunnel to transport IPv4, utilize header compression and be protected by IPsec. Using DSMIP6 enables IPv4 and IPsec. DSMIP6 Header Compression is proposed in draft-haddad-mip6-tunneling-optimization-01.txt, but nothing more than "TBD". Building and maintaining security associations with guaranteed anonymity is to be analyzed. Issue related to MONAMI6: I propose using concurrent MANET Router - Border Router tunnels for seamless handover. Nothing special, except it is work in progress. Comments (and help:-) on my draft is welcome. I may post issues concerning DSMIP6, NEMO and MONAMI6 in Autoconf context. Regards, Teco _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From nemo-bounces@ietf.org Wed Nov 07 04:39: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 1IphNi-0001gW-0H; Wed, 07 Nov 2007 04:39:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IphNf-0001bf-KE; Wed, 07 Nov 2007 04:39:27 -0500 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 1IphNe-0000aB-SF; Wed, 07 Nov 2007 04:39:27 -0500 Received: from [IPv6:2001:380:633:2:20b:cdff:fefb:2a8] (unknown [IPv6:2001:380:633:2:20b:cdff:fefb:2a8]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 98D904D8B5; Wed, 7 Nov 2007 18:39:24 +0900 (JST) Message-ID: <473187CC.1060104@sfc.wide.ad.jp> Date: Wed, 07 Nov 2007 18:39:24 +0900 From: Shinta Sugimoto User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli References: <47314B51.80800@sfc.wide.ad.jp> <4731592D.7060007@azairenet.com> <47315FFC.6040506@sfc.wide.ad.jp> <473169EC.1030509@azairenet.com> In-Reply-To: <473169EC.1030509@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] Re: [Mip6] Please review and provide input to DSMIP6-IKEv2 discussion X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Vijay Devarapalli wrote: > Shinta Sugimoto wrote: > >> Vijay Devarapalli wrote: >> >>>> I examined feasibility of solution 1 and came to the following >>>> conclusion. In my understanding, the solution 1 should work >>>> (on MN) as below: >>>> >>>> (1) MN bootstraps. Neither home address assignment nor IPsec SA >>>> establishment is done yet. >>>> (2) IKEv2 is triggered somehow. >>>> (3) IKE_AUTH message exhcnage is made in which home address >>>> assignment is done by configuration payload. >>> >>> >>> >>> This is not possible. >> >> >> I believe it is possible, but I do agree that such operation >> is not normal at present. >> >>> The way I understand solution 1, IKEv2 is >>> run on top of the DS-MIPv6 tunnel using the home address of the >>> mobile node as the IKEv2 end point. >> >> >> Yes. That's correct. >> >>> The resulting IKEv2 SA is >>> based on the home address of the mobile node. Forget the IPsec >>> SA. >> >> >> Sorry, what do you mean by "Forget the IPsec SA."? >> >>> I don't see how you can request for the home address and at >>> the same time base the IKEv2 SA on the home address. >> >> >> As I wrote above, it can be done by using different IP address >> for IKE endpoint and IPsec SA endpoint address in the initial >> IKE negotiation. Could you explain why you think it is impossible? >> Do you see any violation of specification of IPsec/IKE? >> Or is there any flaw? >> >>> In regular MIPv6, the IKEv2 SA is always based on the care-of >>> address of the mobile node. >> >> >> You mean IKE SA, right? Then, yes, the IKE SA endpoint on the >> side of mobile node is normally the care-of address. >> >> In solution 1, both IKE SA and IPsec SA endpoint address are >> home address. Exceptionally, IKE chooses different IP address >> than home address for IKE SA endpoint in the bootstrap stage. >> That's how I see it. > > > What is this different IP address? Any IP address (globally-scoped unicast IP address) that can be used for transporting IKE messages to the peer. The address cannot be home address since home address is not available yet. Normally, the IP address would be the care-of address. Regards, Shinta From nemo-bounces@ietf.org Wed Nov 07 11:27: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 1Ipnl0-0005fU-1h; Wed, 07 Nov 2007 11:27:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipnkz-0005ew-6W; Wed, 07 Nov 2007 11:27:57 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ipnky-0006Ey-PT; Wed, 07 Nov 2007 11:27:57 -0500 Received: from [127.0.0.1] ([98.207.201.188]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Nov 2007 08:27:54 -0800 Message-ID: <4731E772.4030801@azairenet.com> Date: Wed, 07 Nov 2007 08:27:30 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Shinta Sugimoto References: <47314B51.80800@sfc.wide.ad.jp> <4731592D.7060007@azairenet.com> <47315FFC.6040506@sfc.wide.ad.jp> <473169EC.1030509@azairenet.com> <473187CC.1060104@sfc.wide.ad.jp> In-Reply-To: <473187CC.1060104@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2007 16:27:54.0081 (UTC) FILETIME=[25D97D10:01C8215B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: nemo@ietf.org, mip6@ietf.org Subject: [nemo] Re: [Mip6] Please review and provide input to DSMIP6-IKEv2 discussion X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Shinta Sugimoto wrote: >>>> I don't see how you can request for the home address and at >>>> the same time base the IKEv2 SA on the home address. >>> >>> >>> As I wrote above, it can be done by using different IP address >>> for IKE endpoint and IPsec SA endpoint address in the initial >>> IKE negotiation. Could you explain why you think it is impossible? >>> Do you see any violation of specification of IPsec/IKE? >>> Or is there any flaw? >>> >>>> In regular MIPv6, the IKEv2 SA is always based on the care-of >>>> address of the mobile node. >>> >>> >>> You mean IKE SA, right? Then, yes, the IKE SA endpoint on the >>> side of mobile node is normally the care-of address. >>> >>> In solution 1, both IKE SA and IPsec SA endpoint address are >>> home address. Exceptionally, IKE chooses different IP address >>> than home address for IKE SA endpoint in the bootstrap stage. >>> That's how I see it. >> >> >> What is this different IP address? > > Any IP address (globally-scoped unicast IP address) that can > be used for transporting IKE messages to the peer. The address > cannot be home address since home address is not available yet. > Normally, the IP address would be the care-of address. In this case, there is only an IPv4 CoA available to the mobile node. I am not sure from which prefix the mobile node would configure this temporary IPv6 address. This would result in a 2 stage approach where the mobile node would first use the temporary IPv6 address to run IKEv2 and acquire a home address. The mobile node would then run IKEv2 again to use home address as the source address of the IKEv2 exchange and create a new IKEv2 SA based on the home address. Vijay From nemo-bounces@ietf.org Wed Nov 07 13:29: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 1Ippey-0003IR-7L; Wed, 07 Nov 2007 13:29:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ippew-0003Gz-ED; Wed, 07 Nov 2007 13:29:50 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ippew-00032w-0p; Wed, 07 Nov 2007 13:29:50 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lA7ISLmt011768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Nov 2007 10:28:21 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lA7ISKYo011129; Wed, 7 Nov 2007 10:28:20 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Nov 2007 10:28:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion Date: Wed, 7 Nov 2007 10:28:18 -0800 Message-ID: In-Reply-To: <47315ED2.1060807@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion Thread-Index: AcghCcwHkf/2NgmdQyO6mv9bA2jHLgAYa/pg References: <472F69A3.5090400@azairenet.com> <47312611.5050205@azairenet.com> <47315ED2.1060807@azairenet.com> From: "Narayanan, Vidya" To: "Vijay Devarapalli" X-OriginalArrivalTime: 07 Nov 2007 18:28:19.0287 (UTC) FILETIME=[F8686E70:01C8216B] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj Patil X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > Thanks for informing me what I'm free to do! Things work without=20 > > MOBIKE as I've said above. It is just not as efficient. >=20 > You missed what I was saying. The default operation for the=20 > use of IKEv2 with DS-MIPv6 should not assume MOBIKE=20 > functionality being used at the same time. If you think it is=20 > efficient to do that please do that in a separate document.=20 > Not in the DS-MIPv6 document. >=20 I think I have made it sufficiently clear that this does not require a separate document. All that needs to be written is 2 lines for saying that the IKE SA can be udpated using MOBIKE, in parallel with the BU/BA exchange, when a tunnel mode SA is used. It is ridiculous to require a separate document for this. This is not preventing whatever else you want to do either. So, the objection makes no sense to me.=20 Vidya From nemo-bounces@ietf.org Wed Nov 07 13:34: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 1Ippjn-0008TI-73; Wed, 07 Nov 2007 13:34:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ippjl-0008Pj-0L; Wed, 07 Nov 2007 13:34:49 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ippjg-0003oh-Lr; Wed, 07 Nov 2007 13:34:48 -0500 Received: from [127.0.0.1] ([207.47.15.7]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Nov 2007 10:34:41 -0800 Message-ID: <47320540.2080205@azairenet.com> Date: Wed, 07 Nov 2007 10:34:40 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion References: <472F69A3.5090400@azairenet.com> <47312611.5050205@azairenet.com> <47315ED2.1060807@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2007 18:34:41.0483 (UTC) FILETIME=[DC36E9B0:01C8216C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj Patil X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Narayanan, Vidya wrote: >>> Thanks for informing me what I'm free to do! Things work without >>> MOBIKE as I've said above. It is just not as efficient. >> You missed what I was saying. The default operation for the >> use of IKEv2 with DS-MIPv6 should not assume MOBIKE >> functionality being used at the same time. If you think it is >> efficient to do that please do that in a separate document. >> Not in the DS-MIPv6 document. >> > > I think I have made it sufficiently clear that this does not require a > separate document. All that needs to be written is 2 lines for saying > that the IKE SA can be udpated using MOBIKE, in parallel with the BU/BA > exchange, when a tunnel mode SA is used. It is ridiculous to require a > separate document for this. This is not preventing whatever else you > want to do either. So, the objection makes no sense to me. It does not make sense to me because we can avoid updating the IKEv2 SA in the middle of a handover. If the IKEv2 SA is being updated after the handover, it does not matter if MOBIKE or a CREATE_CHILD_SA exchange is used. MOBIKE comes with its own baggage. BTW, you need to convince the WG to make the change. Not ask why I am objecting. :) Vijay From RogerbugabooCook@ferryhalim.com Wed Nov 07 15:45:56 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iprmd-0007DH-TL for nemo-archive@lists.ietf.org; Wed, 07 Nov 2007 15:45:55 -0500 Received: from [190.12.27.82] (helo=caja) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iprmc-0000Qe-O2 for nemo-archive@lists.ietf.org; Wed, 07 Nov 2007 15:45:55 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host37742417.ferryhalim.com (8.13.1/8.13.1) with SMTP id 0nutkHu430.822718.lEx.EJn.1747223926632 for ; Wed, 7 Nov 2007 15:44:19 +0500 Message-ID: <4a81a01c8217f$2eea0130$0100a8c0@CAJA> From: "Arthur Bell" To: Subject: Your health Date: Wed, 7 Nov 2007 15:44:19 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_4A816_01C8217F.2EEA0130" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_4A816_01C8217F.2EEA0130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_4A816_01C8217F.2EEA0130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_4A816_01C8217F.2EEA0130-- From mext-bounces@ietf.org Thu Nov 08 10:28: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 1Iq9I8-0003kX-FP; Thu, 08 Nov 2007 10:27:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq9I7-0003kO-BC for mext@ietf.org; Thu, 08 Nov 2007 10:27:35 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iq9I6-00020O-Op for mext@ietf.org; Thu, 08 Nov 2007 10:27:35 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1194535652!8305676!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 32263 invoked from network); 8 Nov 2007 15:27:32 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-153.messagelabs.com with SMTP; 8 Nov 2007 15:27:32 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lA8FRQQQ025650; Thu, 8 Nov 2007 08:27:32 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id lA8FRPBZ015110; Thu, 8 Nov 2007 09:27:26 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id lA8FRMct014983; Thu, 8 Nov 2007 09:27:24 -0600 (CST) Message-ID: <47332AD4.6010301@gmail.com> Date: Thu, 08 Nov 2007 16:27:16 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Teco Boot Subject: Re: [MEXT] MIP6 - MIP4 related to boot-nemo4manet (was: [MEXT] MIP6 - DSMIP6 related to boot-nemo4manet) References: <006c01c82115$1510ee00$3f32ca00$@nl> In-Reply-To: <006c01c82115$1510ee00$3f32ca00$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071106-0, 06/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 Teco Boot wrote: > Hi, > > I published an Autoconf solution, based on what we can do with existing > protocols as much as possible. > http://www.ietf.org/internet-drafts/draft-boot-autoconf-nemo4manet-00.txt > I used NEMO for dynamic tunneling between MANET Routers and Border Routers. Teco, can one use NEMOv4 to do this dynamic tunneling between IPv4 MANET Routers and IPv4 Border Routers? (NEMOv4 is an extension to Mobile IPv4 to do Mobile Routers, it's in draft state in MIP4 WG - end of advertisement). > The MANET Routers act as Mobile Routers; the Border Routers act as Home > Agents. Nested NEMO is used for session continuity when handover occurs. > > Issue related to MIP6: > I want Border Routers advertize not only that they provide access to > Internet, but optionally also the identity of the Service Provider. I used > draft-korhonen-mip6-service-04.txt as a guideline, signaling Service > Selection Identifiers. > > Issues related to DSMIP6: > In want the NEMO tunnel to transport IPv4, utilize header compression and be > protected by IPsec. > Using DSMIP6 enables IPv4 and IPsec. I think yes. I think an alternative to this is considering NEMOv4 to transport IPv4 and be protected by IPsec, with Header Compression too. > DSMIP6 Header Compression is proposed in > draft-haddad-mip6-tunneling-optimization-01.txt, but nothing more than > "TBD". I wouldn't call that _the_ "Header Compression", or I would make a distinction from ROHC "RObust Header Compression" so I can understand it better. I think draft-haddad is a smart way to avoid tunnelling. Alex > Building and maintaining security associations with guaranteed anonymity is > to be analyzed. > > Issue related to MONAMI6: > I propose using concurrent MANET Router - Border Router tunnels for seamless > handover. Nothing special, except it is work in progress. > > Comments (and help:-) on my draft is welcome. > I may post issues concerning DSMIP6, NEMO and MONAMI6 in Autoconf context. > > Regards, Teco > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From QuinngladiatorHuber@washingtonpost.com Thu Nov 08 19:56:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqIAt-0005Zy-2b; Thu, 08 Nov 2007 19:56:43 -0500 Received: from [89.129.156.240] (helo=jose0d04b6d3e2) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqIAs-0005KJ-IS; Thu, 08 Nov 2007 19:56:42 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host36135214.washingtonpost.com (8.13.1/8.13.1) with SMTP id MUSigCyO17.108995.SEB.qJr.2998796855736 for ; Fri, 9 Nov 2007 01:56:10 -0100 Message-ID: <1eaed01c8226b$6167b250$0401a8c0@jose0d04b6d3e2> From: "Quinn Hyde" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_1EAE9_01C8226B.6167B250-- From JoelnuisanceHicks@flickr.com Fri Nov 09 05:27:06 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqR4s-00013c-JZ; Fri, 09 Nov 2007 05:27:06 -0500 Received: from [77.194.185.129] (helo=acer9deb84ebb9) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqR4r-0005Xh-Ku; Fri, 09 Nov 2007 05:27:06 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host50913256.flickr.com (8.13.1/8.13.1) with SMTP id TLPQB3Xf85.309421.VCe.Qca.7218221029418 for ; Fri, 9 Nov 2007 11:27:00 -0100 Message-ID: From: "Jacob Murray" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_B82D1_01C822BB.2225A3E0-- From DylaninflammationShaffer@flickr.com Fri Nov 09 09:10:16 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqUYp-0000Tv-Tp; Fri, 09 Nov 2007 09:10:15 -0500 Received: from pool-72-87-84-13.prvdri.fios.verizon.net ([72.87.84.13] helo=d32fgpb1.home) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqUYp-0003UT-Kn; Fri, 09 Nov 2007 09:10:15 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host87131841.flickr.com (8.13.1/8.13.1) with SMTP id 0sIoKdzR66.703701.8A3.Luv.5956751392912 for ; Fri, 9 Nov 2007 08:55:29 +0500 Message-ID: <2d63f01c822d8$c0174550$0201a8c0@D32FGPB1> From: "Elton Dyer" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_2D63B_01C822D8.C0174550-- From TaramaxMcdermott@britneyspears.ac Fri Nov 09 14:28:32 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZWq-0002fw-2W; Fri, 09 Nov 2007 14:28:32 -0500 Received: from [71.178.12.139] (helo=acerc28991bd48.mshome.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqZWp-0000Xw-Mi; Fri, 09 Nov 2007 14:28:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host27060340.britneyspears.ac (8.13.1/8.13.1) with SMTP id feoe3yai67.800014.voc.a9s.8768001563323 for ; Wed, 14 Nov 2007 14:28:09 +0500 Message-ID: <113f7001c826f4$8e681280$4101a8c0@acerc28991bd48> From: "Tara Quinones" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_113F6C_01C826F4.8E681280-- From mayordomo@ucia55.com Fri Nov 09 14:42:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZkL-0000UG-Dm for nemo-archive@lists.ietf.org; Fri, 09 Nov 2007 14:42:29 -0500 Received: from [91.164.39.47] (helo=dyn-83-152-226-166.ppp.tiscali.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqZkK-0001Kd-Jx for nemo-archive@lists.ietf.org; Fri, 09 Nov 2007 14:42:29 -0500 Received: from olivie ([141.180.58.110]:28362 "EHLO olivie" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by dyn-83-152-226-166.ppp.tiscali.fr with ESMTP id S22OBOVISTLLEJPL (ORCPT ); Fri, 9 Nov 2007 20:42:57 +0100 Message-ID: <73E529BD.A76BDC42@ucia55.com> Date: Fri, 9 Nov 2007 20:42:28 +0100 From: "MARCO mayordomo" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: gnilwoll Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea http://www.oslime.com/ Hey Mr. here is how to score all the women... gnileps gniwas-d gnitepmo gnitteud From nemo-bounces@ietf.org Fri Nov 09 17:33: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 1IqcPr-0000LA-TM; Fri, 09 Nov 2007 17:33:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqcPq-0000HR-1D; Fri, 09 Nov 2007 17:33:30 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqcPp-00089P-Bl; Fri, 09 Nov 2007 17:33:29 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lA9MXB5l004440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Nov 2007 14:33:11 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lA9MX9I3007687; Fri, 9 Nov 2007 14:33:09 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Nov 2007 14:32:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion Date: Fri, 9 Nov 2007 14:32:50 -0800 Message-ID: In-Reply-To: <47320540.2080205@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion Thread-Index: AcghbOQ1AWPJJmi0Rx6LFtanb5kttgBsUPcQ References: <472F69A3.5090400@azairenet.com> <47312611.5050205@azairenet.com> <47315ED2.1060807@azairenet.com> <47320540.2080205@azairenet.com> From: "Narayanan, Vidya" To: "Vijay Devarapalli" X-OriginalArrivalTime: 09 Nov 2007 22:32:53.0508 (UTC) FILETIME=[77C05C40:01C82320] X-Spam-Score: -4.0 (----) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj Patil X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > It does not make sense to me because we can avoid updating the > IKEv2 SA in the middle of a handover. If the IKEv2 SA is=20 > being updated after the handover, it does not matter if=20 > MOBIKE or a CREATE_CHILD_SA exchange is used. >=20 You seem to keep going back to losing focus on the problem under discussion. We are talking about the case where the IKE SA update must happen at the time of handover, due to the SA being a tunnel mode one and due to NATs being present. That is the environment in which MOBIKE brings advantages and, before we forget again, it would be an *optional* mechanism to use. It is not helping to say that in other cases, it is not needed, because that's just using an irrelevant point to lose focus on the relevant one. To remove any ambiguity in what I'm saying, it is not even a point of debate that it is not needed in other cases, because no one is saying it is.=20 > MOBIKE comes with its own baggage. >=20 You have made this claim many times without qualifying it. It is time to either qualify it or drop it.=20 > BTW, you need to convince the WG to make the change. Not ask=20 > why I am objecting. :) >=20 I don't see anyone else objecting (or saying anything for that matter) on this topic.=20 Vidya > Vijay >=20 From MolliegraphMcmullen@rotax-owner.com Fri Nov 09 17:55:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqckz-0001Kl-6f; Fri, 09 Nov 2007 17:55:21 -0500 Received: from [190.56.207.230] (helo=clon.lan) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iqcky-0000PQ-Gj; Fri, 09 Nov 2007 17:55:21 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host06538887.rotax-owner.com (8.13.1/8.13.1) with SMTP id Kd6eWbvu20.142372.XqH.TKG.4885790768470 for ; Fri, 9 Nov 2007 04:01:48 -0100 Message-ID: <60fdd01c8227c$efaa65b0$0501a8c0@CLON> From: "Elise Stacy" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_60FD9_01C8227C.EFAA65B0-- From nemo-bounces@ietf.org Fri Nov 09 18:06:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqcvz-0004LB-Gg; Fri, 09 Nov 2007 18:06:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqcvy-0004K6-BZ; Fri, 09 Nov 2007 18:06:42 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iqcvu-0002xH-QE; Fri, 09 Nov 2007 18:06:42 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Nov 2007 15:06:36 -0800 Message-ID: <4734E7FB.1080100@azairenet.com> Date: Fri, 09 Nov 2007 15:06:35 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion References: <472F69A3.5090400@azairenet.com> <47312611.5050205@azairenet.com> <47315ED2.1060807@azairenet.com> <47320540.2080205@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2007 23:06:36.0370 (UTC) FILETIME=[2D789B20:01C82325] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj Patil X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Narayanan, Vidya wrote: >> It does not make sense to me because we can avoid updating the >> IKEv2 SA in the middle of a handover. If the IKEv2 SA is >> being updated after the handover, it does not matter if >> MOBIKE or a CREATE_CHILD_SA exchange is used. >> > > You seem to keep going back to losing focus on the problem under > discussion. We are talking about the case where the IKE SA update must > happen at the time of handover, due to the SA being a tunnel mode one > and due to NATs being present. I had proposed a solution for the tunnel mode too. http://www1.ietf.org/mail-archive/web/mip6/current/msg06910.html Did you miss the email or just dismiss it? The solution in the mail at the above URL was the basis for what I wrote in the previous email. > That is the environment in which MOBIKE > brings advantages and, before we forget again, it would be an *optional* > mechanism to use. It is not helping to say that in other cases, it is > not needed, because that's just using an irrelevant point to lose focus > on the relevant one. To remove any ambiguity in what I'm saying, it is > not even a point of debate that it is not needed in other cases, because > no one is saying it is. > >> MOBIKE comes with its own baggage. >> > > You have made this claim many times without qualifying it. It is time > to either qualify it or drop it. For example, movement detection and two round trips for the MOBIKE update. >> BTW, you need to convince the WG to make the change. Not ask >> why I am objecting. :) >> > > I don't see anyone else objecting (or saying anything for that matter) > on this topic. Nobody is supporting it. Vijay From nemo-bounces@ietf.org Fri Nov 09 20:39: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 1IqfJo-0008HI-2t; Fri, 09 Nov 2007 20:39:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqfJm-00089K-PJ; Fri, 09 Nov 2007 20:39:26 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqfJi-0007Lg-5N; Fri, 09 Nov 2007 20:39:26 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lAA1dH9X023839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Nov 2007 17:39:17 -0800 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lAA1dFHe017301; Fri, 9 Nov 2007 17:39:16 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Nov 2007 17:39:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion Date: Fri, 9 Nov 2007 17:39:08 -0800 Message-ID: In-Reply-To: <4734E7FB.1080100@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion Thread-Index: AcgjJTiEKpnbNwglS/yVqPJDJZzELQAE1+LA References: <472F69A3.5090400@azairenet.com> <47312611.5050205@azairenet.com> <47315ED2.1060807@azairenet.com> <47320540.2080205@azairenet.com> <4734E7FB.1080100@azairenet.com> From: "Narayanan, Vidya" To: "Vijay Devarapalli" X-OriginalArrivalTime: 10 Nov 2007 01:39:15.0620 (UTC) FILETIME=[80CF3E40:01C8233A] X-Spam-Score: -4.0 (----) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj Patil X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org >=20 > I had proposed a solution for the tunnel mode too. > http://www1.ietf.org/mail-archive/web/mip6/current/msg06910.html >=20 > Did you miss the email or just dismiss it? The solution in=20 > the mail at the above URL was the basis for what I wrote in=20 > the previous email. >=20 Ok, this discussion is tiring and unproductive and this will be my last email on this topic. For the last time, I was NOT proposing MOBIKE to be the *only* mechanism for this scenario - all I was saying was that it doesn't involve tentative binding cache entries or sequential roundtrips and hence, needs to be permitted and documented as such as an *option*. We haven't been discussing your other email, since I never objected to allowing a non-MOBIKE approach for the problem also.=20 >=20 > For example, movement detection and two round trips for the=20 > MOBIKE update. >=20 We already said that two roundtrips are unavoidable for updating a tunnel mode SA in the presence of NATs. With MOBIKE, the updates are happening in parallel and hence, there isn't a latency impact. With sequential updates required for handover, there is a latency impact and with the solution you proposed, there is a window of time where the insecure binding cache updates need to be accepted. With MOBIKE, neither of these drawbacks apply. So, I don't understand the logic where we deliberately disallow a no-drawback solution and only propose to use the ones with drawbacks.=20 > >> BTW, you need to convince the WG to make the change. Not=20 > ask why I am=20 > >> objecting. :) > >> > >=20 > > I don't see anyone else objecting (or saying anything for=20 > that matter)=20 > > on this topic. >=20 > Nobody is supporting it. >=20 Not the point, since you said the WG needs convincing; nobody is asking to be convinced and you are the only one objecting it. =20 Vidya=20 From nemo-bounces@ietf.org Sat Nov 10 00:09:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqiav-0003LX-6T; Sat, 10 Nov 2007 00:09:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqiat-0003Gv-NI; Sat, 10 Nov 2007 00:09:19 -0500 Received: from mail-4.anritsu.com ([212.140.169.24] helo=lut-exc-003.main.intgin.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iqiao-0003XE-Hj; Sat, 10 Nov 2007 00:09:19 -0500 Received: from isp-exc-001.main.intgin.net ([172.26.5.164]) by lut-exc-003.main.intgin.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 10 Nov 2007 05:09:13 +0000 Received: from mail pickup service by isp-exc-001.main.intgin.net with Microsoft SMTPSVC; Sat, 10 Nov 2007 00:06:05 -0500 Received: from megatron.ietf.org ([156.154.16.145]) by isp-exc-001.main.intgin.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Nov 2007 19:02:11 -0500 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqcPr-0000KL-NR; Fri, 09 Nov 2007 17:33:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqcPq-0000HR-1D; Fri, 09 Nov 2007 17:33:30 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqcPp-00089P-Bl; Fri, 09 Nov 2007 17:33:29 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lA9MXB5l004440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Nov 2007 14:33:11 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lA9MX9I3007687; Fri, 9 Nov 2007 14:33:09 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Nov 2007 14:32:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion Date: Fri, 9 Nov 2007 14:32:50 -0800 Message-ID: In-Reply-To: <47320540.2080205@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion Thread-Index: AcghbOQ1AWPJJmi0Rx6LFtanb5kttgBsUPcQ References: <472F69A3.5090400@azairenet.com> <47312611.5050205@azairenet.com> <47315ED2.1060807@azairenet.com> <47320540.2080205@azairenet.com> From: "Narayanan, Vidya" To: "Vijay Devarapalli" X-OriginalArrivalTime: 09 Nov 2007 22:32:53.0508 (UTC) FILETIME=[77C05C40:01C82320] X-Spam-Score: -4.0 (----) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > It does not make sense to me because we can avoid updating the > IKEv2 SA in the middle of a handover. If the IKEv2 SA is=20 > being updated after the handover, it does not matter if=20 > MOBIKE or a CREATE_CHILD_SA exchange is used. >=20 You seem to keep going back to losing focus on the problem under discussion. We are talking about the case where the IKE SA update must happen at the time of handover, due to the SA being a tunnel mode one and due to NATs being present. That is the environment in which MOBIKE brings advantages and, before we forget again, it would be an *optional* mechanism to use. It is not helping to say that in other cases, it is not needed, because that's just using an irrelevant point to lose focus on the relevant one. To remove any ambiguity in what I'm saying, it is not even a point of debate that it is not needed in other cases, because no one is saying it is.=20 > MOBIKE comes with its own baggage. >=20 You have made this claim many times without qualifying it. It is time to either qualify it or drop it.=20 > BTW, you need to convince the WG to make the change. Not ask=20 > why I am objecting. :) >=20 I don't see anyone else objecting (or saying anything for that matter) on this topic.=20 Vidya > Vijay >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From nemo-bounces@ietf.org Sat Nov 10 00:09: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 1Iqib5-0003fd-7x; Sat, 10 Nov 2007 00:09:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqib3-0003bp-Tq; Sat, 10 Nov 2007 00:09:29 -0500 Received: from mail-4.anritsu.com ([212.140.169.24] helo=lut-exc-003.main.intgin.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iqib3-0002rq-9H; Sat, 10 Nov 2007 00:09:29 -0500 Received: from isp-exc-001.main.intgin.net ([172.26.5.164]) by lut-exc-003.main.intgin.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 10 Nov 2007 05:09:27 +0000 Received: from mail pickup service by isp-exc-001.main.intgin.net with Microsoft SMTPSVC; Sat, 10 Nov 2007 00:06:05 -0500 Received: from megatron.ietf.org ([156.154.16.145]) by isp-exc-001.main.intgin.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Nov 2007 19:02:11 -0500 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqcvz-0004Ks-BX; Fri, 09 Nov 2007 18:06:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqcvy-0004K6-BZ; Fri, 09 Nov 2007 18:06:42 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iqcvu-0002xH-QE; Fri, 09 Nov 2007 18:06:42 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Nov 2007 15:06:36 -0800 Message-ID: <4734E7FB.1080100@azairenet.com> Date: Fri, 09 Nov 2007 15:06:35 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion References: <472F69A3.5090400@azairenet.com> <47312611.5050205@azairenet.com> <47315ED2.1060807@azairenet.com> <47320540.2080205@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2007 23:06:36.0370 (UTC) FILETIME=[2D789B20:01C82325] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Narayanan, Vidya wrote: >> It does not make sense to me because we can avoid updating the >> IKEv2 SA in the middle of a handover. If the IKEv2 SA is >> being updated after the handover, it does not matter if >> MOBIKE or a CREATE_CHILD_SA exchange is used. >> > > You seem to keep going back to losing focus on the problem under > discussion. We are talking about the case where the IKE SA update must > happen at the time of handover, due to the SA being a tunnel mode one > and due to NATs being present. I had proposed a solution for the tunnel mode too. http://www1.ietf.org/mail-archive/web/mip6/current/msg06910.html Did you miss the email or just dismiss it? The solution in the mail at the above URL was the basis for what I wrote in the previous email. > That is the environment in which MOBIKE > brings advantages and, before we forget again, it would be an *optional* > mechanism to use. It is not helping to say that in other cases, it is > not needed, because that's just using an irrelevant point to lose focus > on the relevant one. To remove any ambiguity in what I'm saying, it is > not even a point of debate that it is not needed in other cases, because > no one is saying it is. > >> MOBIKE comes with its own baggage. >> > > You have made this claim many times without qualifying it. It is time > to either qualify it or drop it. For example, movement detection and two round trips for the MOBIKE update. >> BTW, you need to convince the WG to make the change. Not ask >> why I am objecting. :) >> > > I don't see anyone else objecting (or saying anything for that matter) > on this topic. Nobody is supporting it. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From DiegothiaminGallegos@toolkit.com Sat Nov 10 02:15:41 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqkZB-0001CT-Qd; Sat, 10 Nov 2007 02:15:41 -0500 Received: from pool-71-241-78-170.scr.east.verizon.net ([71.241.78.170] helo=vukaj.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqkZB-00064K-FA; Sat, 10 Nov 2007 02:15:41 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host63757233.toolkit.com (8.13.1/8.13.1) with SMTP id pJCqLKOa41.979867.psU.OY9.4292518991509 for ; Sat, 10 Nov 2007 02:15:14 +0500 Message-ID: <45b5201c82369$800fda80$2f01a8c0@VUKAJ> From: "Rusty Hobbs" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_45B4E_01C82369.800FDA80-- From LymanavocadoRosales@closer.com Sat Nov 10 04:38:11 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqmn5-000283-7J; Sat, 10 Nov 2007 04:38:11 -0500 Received: from 145.red-88-23-173.staticip.rima-tde.net ([88.23.173.145] helo=24a672982ded4c3) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iqmn4-0001k8-GE; Sat, 10 Nov 2007 04:38:11 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host57574438.closer.com (8.13.1/8.13.1) with SMTP id Ft8cS0xu07.413437.JU3.5Mn.5161719161500 for ; Sat, 10 Nov 2007 10:37:42 -0100 Message-ID: <21d93401c8237d$6a30db10$2101a8c0@24a672982ded4c3> From: "Lyman Stanton" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_21D930_01C8237D.6A30DB10-- From AudreyhatchetWoodruff@canadiandriver.com Sat Nov 10 06:54:39 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqov9-0006pC-Aq; Sat, 10 Nov 2007 06:54:39 -0500 Received: from pool-71-185-28-129.phlapa.fios.verizon.net ([71.185.28.129] helo=schneiders.home) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iqov8-0005vb-UF; Sat, 10 Nov 2007 06:54:39 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host24609793.canadiandriver.com (8.13.1/8.13.1) with SMTP id F1Dt7TdG53.395484.cb1.Kaj.8133606399282 for ; Sat, 10 Nov 2007 06:51:16 +0500 Message-ID: <11305801c82390$9fa395e0$0401a8c0@Schneiders> From: "Sally John" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_113054_01C82390.9FA395E0-- From LoralectureHolliday@williebird.com Sat Nov 10 08:54:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqqn3-0004aU-Vz; Sat, 10 Nov 2007 08:54:26 -0500 Received: from pool-72-88-67-94.bflony.east.verizon.net ([72.88.67.94] helo=d131wk91.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iqqn3-0000zs-68; Sat, 10 Nov 2007 08:54:25 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host30813048.williebird.com (8.13.1/8.13.1) with SMTP id 6T7yPCyj07.394940.XZ2.K27.6322210660164 for ; Sat, 10 Nov 2007 08:53:33 +0500 Message-ID: <1b7a01c823a1$2df77cc0$2f01a8c0@D131WK91> From: "Kendra Bloom" To: Subject: Your family Date: Sat, 10 Nov 2007 08:53:33 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1B76_01C823A1.2DF77CC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_1B76_01C823A1.2DF77CC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_1B76_01C823A1.2DF77CC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_1B76_01C823A1.2DF77CC0-- From FloydplunderHudson@htmlhelp.com Sat Nov 10 11:28:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqtC7-0001Mr-Rd; Sat, 10 Nov 2007 11:28:27 -0500 Received: from [190.49.40.61] (helo=edicioneab6490) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqtC7-0006An-7m; Sat, 10 Nov 2007 11:28:27 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host73711865.htmlhelp.com (8.13.1/8.13.1) with SMTP id Xo1tgVFy32.813387.GCR.42o.1587603723667 for ; Sat, 10 Nov 2007 13:28:13 +0300 Message-ID: <27af901c823b6$bd1fd860$6501a8c0@edicioneab6490> From: "Leon Matthews" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_27AF5_01C823B6.BD1FD860-- From marsolg@omegamentalhealth.com Sat Nov 10 14:55:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqwQT-0006rr-MZ for nemo-archive@lists.ietf.org; Sat, 10 Nov 2007 14:55:29 -0500 Received: from host200-42-dynamic.60-82-r.retail.telecomitalia.it ([82.60.42.200]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqwQT-0005OC-3f for nemo-archive@lists.ietf.org; Sat, 10 Nov 2007 14:55:29 -0500 Received: from wohnzimmer ([104.100.15.89] helo=wohnzimmer) by host200-42-dynamic.60-82-r.retail.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1MjTky-000IEG-ym for nemo-archive@lists.ietf.org; Mon, 29 Oct 2007 20:56:27 +0100 Message-ID: <000901c81a65$b8511600$c82a3c52@wohnzimmer> From: "becca mar" To: Subject: amikkrok Date: Mon, 29 Oct 2007 20:55:56 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C81A6E.1A157E00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 071110-0, 10.11.2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.2 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0003_01C81A6E.1A157E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://sabuul.com/ My peni*s grew 2" after 5 months of use alpdruck amarenan ammaliam "amhcseg ------=_NextPart_000_0003_01C81A6E.1A157E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://sabuul.com/
My peni*s grew 2" after 5 months of = use
alpdruck amarenan
ammaliam "amhcseg
------=_NextPart_000_0003_01C81A6E.1A157E00-- From NickolasexorcismWeiss@townofthompson.com Sat Nov 10 15:38:46 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqx6L-0000ND-Ny; Sat, 10 Nov 2007 15:38:45 -0500 Received: from [200.89.251.173] (helo=adriname.dinanet.net.co) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iqx6I-0006kv-2S; Sat, 10 Nov 2007 15:38:45 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host35509448.townofthompson.com (8.13.1/8.13.1) with SMTP id 78EA5BMK49.048940.TUz.Oxq.2450725092895 for ; Sat, 10 Nov 2007 15:38:20 +0500 Message-ID: <213c001c823d9$b2b71f00$adfb59c8@adriname> From: "Sebastian Kent" To: Subject: Your order approved Date: Sat, 10 Nov 2007 15:38:20 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_213BC_01C823D9.B2B71F00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_213BC_01C823D9.B2B71F00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_213BC_01C823D9.B2B71F00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_213BC_01C823D9.B2B71F00-- From CyrilappriseRollins@europa.eu Sat Nov 10 20:18:41 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ir1TF-0003CT-1X; Sat, 10 Nov 2007 20:18:41 -0500 Received: from [190.1.237.179] (helo=home3bc1e3793e) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ir1TE-0005eG-5A; Sat, 10 Nov 2007 20:18:40 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host38402293.europa.eu (8.13.1/8.13.1) with SMTP id GVSdjnLD84.570061.UOl.O6k.8481877667659 for ; Sat, 10 Nov 2007 20:18:17 +0500 Message-ID: <4dbc01c82400$d027d350$0a01a8c0@home3bc1e3793e> From: "Gale Donaldson" To: Subject: Your life Date: Sat, 10 Nov 2007 20:18:17 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_4DB8_01C82400.D027D350" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 This is a multi-part message in MIME format. ------=_NextPart_000_4DB8_01C82400.D027D350 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_4DB8_01C82400.D027D350 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_4DB8_01C82400.D027D350-- From NoralibrettoStroud@nonfictionphoto.com Sat Nov 10 20:36:39 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ir1kd-00028x-Az; Sat, 10 Nov 2007 20:36:39 -0500 Received: from [201.229.135.28] (helo=mgsecre.metalgas.local) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ir1kb-000641-Vh; Sat, 10 Nov 2007 20:36:39 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host88522878.nonfictionphoto.com (8.13.1/8.13.1) with SMTP id rzFLergC40.698949.Ajm.JDF.8926715725759 for ; Sat, 10 Nov 2007 21:39:55 +0400 Message-ID: From: "Brandy Poe" To: Subject: Your life Date: Sat, 10 Nov 2007 21:39:55 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_BE64B_01C82403.CFEB1110" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_BE64B_01C82403.CFEB1110 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_BE64B_01C82403.CFEB1110 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_BE64B_01C82403.CFEB1110-- From LaurabilinearProctor@gasupreme.us Sat Nov 10 22:20:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ir3Mz-00068n-HH; Sat, 10 Nov 2007 22:20:21 -0500 Received: from pc-19-193-44-190.cm.vtr.net ([190.44.193.19] helo=pc0) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ir3My-0000MU-Vo; Sat, 10 Nov 2007 22:20:21 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host78376117.gasupreme.us (8.13.1/8.13.1) with SMTP id mideQ5Wi72.595778.iGM.1Qb.1508905457602 for ; Sun, 11 Nov 2007 00:20:37 +0400 Message-ID: From: "Michelle Proctor" To: Subject: Your order Date: Sun, 11 Nov 2007 00:20:37 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_F85F_01C82411.E61BE190" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_F85F_01C82411.E61BE190 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_F85F_01C82411.E61BE190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_F85F_01C82411.E61BE190-- From JeniferhandmaidenMcwilliams@43people.com Sun Nov 11 02:55:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ir7ep-0004jm-14; Sun, 11 Nov 2007 02:55:03 -0500 Received: from [189.159.59.171] (helo=nora6ae9a430da.domain.invalid) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ir7eo-0000B7-5f; Sun, 11 Nov 2007 02:55:02 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host56663171.43people.com (8.13.1/8.13.1) with SMTP id H57XKs4i44.110779.NgZ.Rct.8169512815303 for ; Sun, 11 Nov 2007 01:54:28 +0600 Message-ID: <5161401c82438$2896f750$01fea8c0@nora6ae9a430da> From: "Christa Redmond" To: Subject: Your order Date: Sun, 11 Nov 2007 01:54:28 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_51610_01C82438.2896F750" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Antivirus: avast! (VPS 071110-0, 10/11/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_51610_01C82438.2896F750 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_51610_01C82438.2896F750 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_51610_01C82438.2896F750-- From mext-bounces@ietf.org Sun Nov 11 04:46: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 1Ir9OR-00079l-80; Sun, 11 Nov 2007 04:46:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ir9OP-00077c-Im for mext@ietf.org; Sun, 11 Nov 2007 04:46:13 -0500 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ir9OL-0004AS-BE for mext@ietf.org; Sun, 11 Nov 2007 04:46:13 -0500 Received: from oaamta01sl.mx.bigpond.com ([124.190.106.219]) by omta04sl.mx.bigpond.com with ESMTP id <20071111094605.TITO1805.omta04sl.mx.bigpond.com@oaamta01sl.mx.bigpond.com> for ; Sun, 11 Nov 2007 09:46:05 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta01sl.mx.bigpond.com with ESMTP id <20071111094605.MMCO1391.oaamta01sl.mx.bigpond.com@PC20005>; Sun, 11 Nov 2007 09:46:05 +0000 From: "Hesham Soliman" To: "'Narayanan, Vidya'" Date: Sun, 11 Nov 2007 20:45:53 +1000 Message-ID: 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.3198 Thread-Index: AcgjJTiEKpnbNwglS/yVqPJDJZzELQAE1+LAAEWuWRA= In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mext@ietf.org Subject: [MEXT] RE: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion 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 Vidya, (cleaned up the cc list and moved to mext) Let me know if I understand what you're asking for correctly. Effectively you're saying that if we follow something like alternative 2, which allows IPsec tunnel mode over port 4500 for normal traffic, then we should be able to use MOBIKE to update that SA. Is my understanding correct? I believe there are two ways of updating the IKE SA in the presence of NATs, one is the "implicit mode" where IKE in the HA just sees that the addresses/ports have changed and it updates the SA accordingly. The other is obviously the explicit MOBIKE. So if I understand this correctly you're saying that we don't need to say "MOBIKE MUST be used", you're saying it should be possible to use MOBIKE. Is this a correct understanding? If I understood you correctly then I don't see how we can stop people from using MOBIKE. But of course if you want to mandate MOBIKE then it's a different discussion. Let me know if I got it right. Hesham > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Saturday, November 10, 2007 11:39 AM > To: Vijay Devarapalli > Cc: Basavaraj Patil; ext Hesham Soliman; mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] RE: [nemo] Please review and provide > input to DSMIP6-IKEv2discussion > > > > > I had proposed a solution for the tunnel mode too. > > http://www1.ietf.org/mail-archive/web/mip6/current/msg06910.html > > > > Did you miss the email or just dismiss it? The solution in > > the mail at the above URL was the basis for what I wrote in > > the previous email. > > > > Ok, this discussion is tiring and unproductive and this will > be my last > email on this topic. For the last time, I was NOT proposing > MOBIKE to > be the *only* mechanism for this scenario - all I was saying > was that it > doesn't involve tentative binding cache entries or > sequential roundtrips > and hence, needs to be permitted and documented as such as > an *option*. > We haven't been discussing your other email, since I never > objected to > allowing a non-MOBIKE approach for the problem also. > > > > > For example, movement detection and two round trips for the > > MOBIKE update. > > > > We already said that two roundtrips are unavoidable for updating a > tunnel mode SA in the presence of NATs. With MOBIKE, the updates are > happening in parallel and hence, there isn't a latency impact. With > sequential updates required for handover, there is a latency > impact and > with the solution you proposed, there is a window of time where the > insecure binding cache updates need to be accepted. With MOBIKE, > neither of these drawbacks apply. So, I don't understand the logic > where we deliberately disallow a no-drawback solution and > only propose > to use the ones with drawbacks. > > > >> BTW, you need to convince the WG to make the change. Not > > ask why I am > > >> objecting. :) > > >> > > > > > > I don't see anyone else objecting (or saying anything for > > that matter) > > > on this topic. > > > > Nobody is supporting it. > > > > Not the point, since you said the WG needs convincing; > nobody is asking > to be convinced and you are the only one objecting it. > > Vidya > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From BryanfsFisher@rotax-owner.com Sun Nov 11 07:24:23 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrBrT-0006yB-Il; Sun, 11 Nov 2007 07:24:23 -0500 Received: from s01060013d4ca274f.ca.shawcable.net ([70.77.101.162] helo=brandi.ca.shawcable.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IrBrT-000698-3s; Sun, 11 Nov 2007 07:24:23 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host71702574.rotax-owner.com (8.13.1/8.13.1) with SMTP id wX0XeYul21.974399.2Dy.t9S.0786578148172 for ; Sun, 11 Nov 2007 04:24:10 +0000 Message-ID: From: "Allen Graham" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_EDAC2_01C8241A.C7C4C410-- From KayquakeressHo@sony.fr Sun Nov 11 13:17:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrHMn-00018k-MJ; Sun, 11 Nov 2007 13:17:05 -0500 Received: from [200.26.151.135] (helo=9223df965c44424) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IrHMn-0003Am-9a; Sun, 11 Nov 2007 13:17:05 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host13288655.sony.fr (8.13.1/8.13.1) with SMTP id yTZ1s73a01.701287.pyD.sde.3002149564262 for ; Sun, 11 Nov 2007 19:16:31 -0100 Message-ID: <25e0401c8248f$07106f60$1703a8c0@9223df965c44424> From: "Nina Teague" To: Subject: Hi Date: Sun, 11 Nov 2007 19:16:31 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_25E00_01C8248F.07106F60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_25E00_01C8248F.07106F60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_25E00_01C8248F.07106F60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_25E00_01C8248F.07106F60-- From Lourina@biognostik.com Sun Nov 11 15:27:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrJOg-0008Bj-Q9 for nemo-archive@lists.ietf.org; Sun, 11 Nov 2007 15:27:10 -0500 Received: from 201008235139.user.veloxzone.com.br ([201.8.235.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrJOg-0000D6-6s for nemo-archive@lists.ietf.org; Sun, 11 Nov 2007 15:27:10 -0500 Received: from aline ([126.101.16.143] helo=aline) by 201008235139.user.veloxzone.com.br ( sendmail 8.13.3/8.13.1) with esmtpa id 1mDOFy-000FGN-Pv for nemo-archive@lists.ietf.org; Sun, 11 Nov 2007 17:26:16 -0200 Date: Sun, 11 Nov 2007 17:25:51 -0200 From: "Lourina Gerson" Reply-To: "Lourina Gerson" Message-ID: <717785078064.010503818779@biognostik.com> To: Subject: iaregage MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Spam-Score: 3.9 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea http://tatkins.com/ get rid of that low self-esteem once and for all. iappiies iaresopo iawias iaton From ErickasanchezCrenshaw@engadget.com Sun Nov 11 17:12:59 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrL35-0001NC-3J; Sun, 11 Nov 2007 17:12:59 -0500 Received: from cpc1-cove4-0-0-cust372.sol2.cable.ntl.com ([86.20.37.117] helo=df28sm2j.belkin) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IrL34-0003x9-Hl; Sun, 11 Nov 2007 17:12:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host34289876.engadget.com (8.13.1/8.13.1) with SMTP id 2nofA4rw92.385201.ed8.sg8.4081573283927 for ; Sun, 11 Nov 2007 22:13:13 +0000 Message-ID: <2cf9a01c824b0$183eec00$0302a8c0@DF28SM2J> From: "Lenore Medeiros" To: Subject: Approval process Date: Sun, 11 Nov 2007 22:13:13 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_2CF96_01C824B0.183EEC00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_2CF96_01C824B0.183EEC00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_2CF96_01C824B0.183EEC00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_2CF96_01C824B0.183EEC00-- From TracytortureObrien@itsgettinghotinhere.org Sun Nov 11 21:43:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrPGY-0002yW-0G; Sun, 11 Nov 2007 21:43:10 -0500 Received: from [58.48.110.26] (helo=dianban01) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IrPGX-0004d6-DA; Sun, 11 Nov 2007 21:43:09 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host97951202.itsgettinghotinhere.org (8.13.1/8.13.1) with SMTP id L4IwpmOA45.190405.MCC.vDQ.3366443529903 for ; Mon, 12 Nov 2007 10:45:42 -0800 Message-ID: <139a01c824d6$32384950$0c6da8c0@DIANBAN01> From: "Rene Holt" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_1396_01C824D6.32384950-- From JakenobMccarthy@rivals.com Mon Nov 12 02:26:56 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrTh9-00025O-Sm; Mon, 12 Nov 2007 02:26:55 -0500 Received: from cpc1-mfld8-0-0-cust534.nott.cable.ntl.com ([81.103.178.23] helo=jcmpc) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IrTh9-0007VT-9T; Mon, 12 Nov 2007 02:26:55 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host02919446.rivals.com (8.13.1/8.13.1) with SMTP id nIJYgP2Y45.347305.Apn.NfV.0273860527748 for ; Mon, 12 Nov 2007 07:26:00 +0000 Message-ID: <052301c824fd$578c7dd0$17b26751@jcmpc> From: "Guadalupe Moody" To: Subject: Your health Date: Mon, 12 Nov 2007 07:26:00 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_051F_01C824FD.578C7DD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_051F_01C824FD.578C7DD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_051F_01C824FD.578C7DD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_051F_01C824FD.578C7DD0-- From margalit50karl@budostuff.com Mon Nov 12 03:05:57 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrUIv-0008FI-Lw for nemo-archive@lists.ietf.org; Mon, 12 Nov 2007 03:05:57 -0500 Received: from acdw14.neoplus.adsl.tpnet.pl ([83.9.172.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrUIp-0001Wg-8P for nemo-archive@lists.ietf.org; Mon, 12 Nov 2007 03:05:57 -0500 Received: from [83.9.172.14] by pwtaf.budostuff.com; Mon, 12 Nov 2007 08:05:47 +0000 Message-ID: <000501c82502$061f3634$c9bd0696@yyagku> From: "hobie spencer" To: "Eula Winter" Subject: Reasonable price Date: Mon, 12 Nov 2007 06:18:25 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C82502.061E6EBA" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 2.9 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C82502.061E6EBA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We currently carry over 3136 different replica watches!!! We Are The = Largest Replica Dealer on The Globe! http://moistrave.net/ ------=_NextPart_000_0002_01C82502.061E6EBA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We currently carry over 3136 different replica watches!!! We Are The = Largest Replica Dealer on The Globe!

http://moistrave.net/ ------=_NextPart_000_0002_01C82502.061E6EBA-- From mext-bounces@ietf.org Mon Nov 12 04:43: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 1IrVol-0006yK-Ip; Mon, 12 Nov 2007 04:42:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrVoe-0006pr-55; Mon, 12 Nov 2007 04:42:48 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrVoc-0005qL-PR; Mon, 12 Nov 2007 04:42:48 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRE004Y00B8E5@szxga01-in.huawei.com>; Mon, 12 Nov 2007 17:42:44 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRE00FY50B5FG@szxga01-in.huawei.com>; Mon, 12 Nov 2007 17:42:44 +0800 (CST) Received: from z49950 ([10.121.33.161]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRE008SW0B1DF@szxml04-in.huawei.com>; Mon, 12 Nov 2007 17:42:41 +0800 (CST) Date: Mon, 12 Nov 2007 17:42:37 +0800 From: "John.zhao" Subject: [MEXT][Netlmm] Problem statement about nemo and the combined scenario of nemo and pmip To: mext@ietf.org Message-id: <01f401c82510$5c0a1c10$a864a8c0@china.huawei.com> Organization: Huawei Technologies Co., LTD. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcglEFu95RBeTlsDQ623NZHyOji2YQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: ad7e0fb6ea8793357f585d335bde5ef0 Cc: netlmm@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: john.zhao@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2114495820==" Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============2114495820== Content-type: multipart/alternative; boundary="Boundary_(ID_nAW1FKgCi93zlQjTUzeAZw)" This is a multi-part message in MIME format. --Boundary_(ID_nAW1FKgCi93zlQjTUzeAZw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hello,guys Following is a problem statement about the nemo and the combined scenario of nemo and pmip. http://www.ietf.org/internet-drafts/draft-zhao-nemo-limitations-ps-00.txt Your responses and comments is very appreciated to me. Mean while , can I request a slot to presente this in IETF-70 meeting?mext or netlmm,which one is the best? A new version of I-D, draft-zhao-nemo-limitations-ps-00.txt has been successfuly submitted by Yuankui Zhao and posted to the IETF repository. Filename: draft-zhao-nemo-limitations-ps Revision: 00 Title: Limitations exist in IP mobility support applications Creation_date: 2007-11-12 WG ID: Independent Submission Number_of_pages: 16 Abstract: There already exist several mobility support solutions and each solution uses its own method to achieve specific goals.But different solutions may not work properly when they are combined in an integrated application environment because network entities have little information about each other.Specially when PMIP meet with the Nemo network environment something need to be considered more. This document describes several limitations on NEMO application and provides a possible solution. John.zhao Huawei technologies Co.,LTD 2007-11-12 --Boundary_(ID_nAW1FKgCi93zlQjTUzeAZw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hello,guys

     &= nbsp;   Following is a problem statement about the nemo and the combined scenario of nemo = and pmip.

http://www.ietf.org/internet-drafts/draft-zhao-nemo-limitations= -ps-00.txt

     &= nbsp;   Your responses and comments is very appreciated to = me.

     &= nbsp;   Mean while , can I request a slot to presente this in IETF-70 meeting?mext or = netlmm,which one is the best?

A new version of I-D, draft-zhao-nemo-limitations-ps-00.txt has been = successfuly submitted by Yuankui Zhao and posted to the IETF = repository.

 

Filename:=20 draft-zhao-nemo-limitations-ps

Revision:=20 00

Title:       =20 Limitations exist in IP mobility support = applications

Creation_date:    =20 2007-11-12

WG ID:       =20 Independent Submission

Number_of_pages: 16

 

Abstract:

There already exist several mobility support solutions and each solution uses = its own method to achieve specific goals.But different solutions may not work = properly when they are combined in an integrated application environment because = network entities have little information about each other.Specially when PMIP = meet with the Nemo network environment something need to be considered more. = This document describes several limitations on NEMO application = and provides a possible solution.

           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;        

John.zhao

Huawei technologies Co.,LTD

2007-11-12

 =

 <= /o:p>

--Boundary_(ID_nAW1FKgCi93zlQjTUzeAZw)-- --===============2114495820== 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 --===============2114495820==-- From nemo-bounces@ietf.org Mon Nov 12 04:59: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 1IrW4U-0007rE-7Y; Mon, 12 Nov 2007 04:59:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrW4T-0007qw-JX; Mon, 12 Nov 2007 04:59:09 -0500 Received: from mail1.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrW4T-0006fk-4W; Mon, 12 Nov 2007 04:59:09 -0500 X-AuditID: c26e2f18-000013bc00001cd0-7b-473823d94ff6 Received: from stingray.eu.tieto.com ([192.176.143.13]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Nov 2007 11:58:49 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Nov 2007 10:59:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] RE: [nemo] Please review and provide input toDSMIP6-IKEv2discussion Date: Mon, 12 Nov 2007 10:59:06 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: [nemo] Please review and provide input toDSMIP6-IKEv2discussion Thread-Index: AcghbOQ1AWPJJmi0Rx6LFtanb5kttgBsUPcQAHzpo2A= References: <472F69A3.5090400@azairenet.com><47312611.5050205@azairenet.com><47315ED2.1060807@azairenet.com><47320540.2080205@azairenet.com> From: To: , X-OriginalArrivalTime: 12 Nov 2007 09:59:06.0776 (UTC) FILETIME=[A9C1F980:01C82512] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, > You seem to keep going back to losing focus on the problem under > discussion. We are talking about the case where the IKE SA=20 > update must > happen at the time of handover, due to the SA being a tunnel mode one > and due to NATs being present. That is the environment in=20 > which MOBIKE > brings advantages and, before we forget again, it would be an=20 > *optional* > mechanism to use. It is not helping to say that in other cases, it is > not needed, because that's just using an irrelevant point to=20 > lose focus > on the relevant one. To remove any ambiguity in what I'm=20 > saying, it is > not even a point of debate that it is not needed in other=20 > cases, because > no one is saying it is.=20 >=20 > > MOBIKE comes with its own baggage. > >=20 >=20 > You have made this claim many times without qualifying it. It is time > to either qualify it or drop it.=20 >=20 > > BTW, you need to convince the WG to make the change. Not ask=20 > > why I am objecting. :) > >=20 >=20 > I don't see anyone else objecting (or saying anything for that matter) > on this topic.=20 >=20 I don't see any technical reasons for us not considering optional usage of MOBIKE for this situation. MOBIKE do implement what is requried. It does however require us to describe exactly how to communicate optional usage of MOBIKE. The usage of MOBIKE must be OPTIONAL, in my opinion, as we have ways to do this without requirering MOBIKE support in the implementations. But a question that comes to mind then, though, is whether it really make sense to use MOBIKE when moving in Ipv4 foreign networks (with or without NAT - ?) but standard MIP-IKE interactions for DSMIP in IPV6 foreign networks as well as for standard MIPv6. BR, Karen > Vidya >=20 > > Vijay > >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 From LupemalevolentLe@interfax.ru Mon Nov 12 07:13:51 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYAo-0005z3-T9; Mon, 12 Nov 2007 07:13:50 -0500 Received: from c-68-37-218-231.hsd1.nj.comcast.net ([68.37.218.231] helo=adam) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IrYAo-0003jF-LB; Mon, 12 Nov 2007 07:13:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host00517824.interfax.ru (8.13.1/8.13.1) with SMTP id fmPlbVIK71.756210.yRW.udO.6585320399456 for ; Mon, 12 Nov 2007 07:16:46 +0500 Message-ID: <1d860701c82525$f8396db0$0401a8c0@adam> From: "Jonah Hewitt" To: Subject: Hi Date: Mon, 12 Nov 2007 07:16:46 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1D8603_01C82525.F8396DB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_1D8603_01C82525.F8396DB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_1D8603_01C82525.F8396DB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_1D8603_01C82525.F8396DB0-- From AllisontadRoe@washingtonpost.com Mon Nov 12 09:20:37 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ira9V-0003UA-Lo; Mon, 12 Nov 2007 09:20:37 -0500 Received: from adsl190-28-62-133.epm.net.co ([190.28.62.133] helo=final1c9ed6606.lan) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ira9T-0001Vp-8G; Mon, 12 Nov 2007 09:20:37 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host49166317.washingtonpost.com (8.13.1/8.13.1) with SMTP id BgNUwn2267.685519.C7J.Iai.3169800834443 for ; Mon, 12 Nov 2007 09:19:54 +0500 Message-ID: <13af101c82537$2ef44ad0$4001a8c0@final1c9ed6606> From: "Tamara Tuttle" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_13AED_01C82537.2EF44AD0-- From BenitaearthmoverCoon@linuxtoday.com Mon Nov 12 10:05:56 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrarM-0007oZ-8u; Mon, 12 Nov 2007 10:05:56 -0500 Received: from dyn-83-153-17-66.ppp.tiscali.fr ([83.153.17.66] helo=home6elr0isdgu) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IrarL-00032j-PZ; Mon, 12 Nov 2007 10:05:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host78389472.linuxtoday.com (8.13.1/8.13.1) with SMTP id tx5kmkcY93.877946.pKK.dwF.2459221840303 for ; Mon, 12 Nov 2007 16:05:32 -0100 Message-ID: <1c3701c8253d$856942c0$0a01a8c0@home6elr0isdgu> From: "Penelope Coon" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_1C33_01C8253D.856942C0-- From nemo-bounces@ietf.org Mon Nov 12 13:43:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IreFn-0008O3-Kb; Mon, 12 Nov 2007 13:43:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IreFl-0008MS-Ld; Mon, 12 Nov 2007 13:43:21 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IreFi-0008DD-1b; Mon, 12 Nov 2007 13:43:21 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Nov 2007 10:43:17 -0800 Message-ID: <47389EC4.4010800@azairenet.com> Date: Mon, 12 Nov 2007 10:43:16 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion References: <472F69A3.5090400@azairenet.com> <47312611.5050205@azairenet.com> <47315ED2.1060807@azairenet.com> <47320540.2080205@azairenet.com> <4734E7FB.1080100@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Nov 2007 18:43:17.0165 (UTC) FILETIME=[E3A67DD0:01C8255B] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj Patil X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Narayanan, Vidya wrote: >> I had proposed a solution for the tunnel mode too. >> http://www1.ietf.org/mail-archive/web/mip6/current/msg06910.html >> >> Did you miss the email or just dismiss it? The solution in >> the mail at the above URL was the basis for what I wrote in >> the previous email. >> > > Ok, this discussion is tiring and unproductive and this will be my last > email on this topic. For the last time, I was NOT proposing MOBIKE to > be the *only* mechanism for this scenario - all I was saying was that it > doesn't involve tentative binding cache entries or sequential roundtrips > and hence, needs to be permitted and documented as such as an *option*. Ok. But I am still objecting to specifying the use of MOBIKE as one of the solutions in the DS-MIPv6 document. There are multiple reason. It may require two round trips during the handover. And You will have two mobility management protocols running at the same time. I do agree with Hesham that we can't really prevent if someone wants to use MOBIKE at the same time. I suggest a separate document on this if you still want MOBIKE to be an alternative. Vijay > We haven't been discussing your other email, since I never objected to > allowing a non-MOBIKE approach for the problem also. > >> For example, movement detection and two round trips for the >> MOBIKE update. >> > > We already said that two roundtrips are unavoidable for updating a > tunnel mode SA in the presence of NATs. With MOBIKE, the updates are > happening in parallel and hence, there isn't a latency impact. With > sequential updates required for handover, there is a latency impact and > with the solution you proposed, there is a window of time where the > insecure binding cache updates need to be accepted. With MOBIKE, > neither of these drawbacks apply. So, I don't understand the logic > where we deliberately disallow a no-drawback solution and only propose > to use the ones with drawbacks. > >>>> BTW, you need to convince the WG to make the change. Not >> ask why I am >>>> objecting. :) >>>> >>> I don't see anyone else objecting (or saying anything for >> that matter) >>> on this topic. >> Nobody is supporting it. >> > > Not the point, since you said the WG needs convincing; nobody is asking > to be convinced and you are the only one objecting it. > > Vidya From nemo-bounces@ietf.org Mon Nov 12 13:45:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IreHb-0003XD-In; Mon, 12 Nov 2007 13:45:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IreHa-0003X2-RX; Mon, 12 Nov 2007 13:45:14 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IreHa-00050c-DD; Mon, 12 Nov 2007 13:45:14 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Nov 2007 10:45:12 -0800 Message-ID: <47389F38.3020407@azairenet.com> Date: Mon, 12 Nov 2007 10:45:12 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karen.Nielsen@tietoenator.com Subject: Re: [Mip6] RE: [nemo] Please review and provide input toDSMIP6-IKEv2discussion References: <472F69A3.5090400@azairenet.com><47312611.5050205@azairenet.com><47315ED2.1060807@azairenet.com><47320540.2080205@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Nov 2007 18:45:12.0976 (UTC) FILETIME=[28ADD900:01C8255C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Karen.Nielsen@tietoenator.com wrote: > Hi, > > >> You seem to keep going back to losing focus on the problem under >> discussion. We are talking about the case where the IKE SA >> update must >> happen at the time of handover, due to the SA being a tunnel mode one >> and due to NATs being present. That is the environment in >> which MOBIKE >> brings advantages and, before we forget again, it would be an >> *optional* >> mechanism to use. It is not helping to say that in other cases, it is >> not needed, because that's just using an irrelevant point to >> lose focus >> on the relevant one. To remove any ambiguity in what I'm >> saying, it is >> not even a point of debate that it is not needed in other >> cases, because >> no one is saying it is. >> >>> MOBIKE comes with its own baggage. >>> >> You have made this claim many times without qualifying it. It is time >> to either qualify it or drop it. >> >>> BTW, you need to convince the WG to make the change. Not ask >>> why I am objecting. :) >>> >> I don't see anyone else objecting (or saying anything for that matter) >> on this topic. > > I don't see any technical reasons for us not considering optional usage > of MOBIKE for > this situation. MOBIKE do implement what is requried. It does however > require us to describe exactly > how to communicate optional usage of MOBIKE. The usage of MOBIKE must be > OPTIONAL, > in my opinion, as we have ways to do this without requirering MOBIKE > support in the implementations. > > But a question that comes to mind then, though, is whether it really > make sense to use MOBIKE when > moving in Ipv4 foreign networks (with or without NAT - ?) but standard > MIP-IKE interactions for DSMIP > in IPV6 foreign networks as well as for standard MIPv6. IMO, it does not. If you are using MOBIKE to update the IKEv2 SA (and the tunnel IPsec SAs) after a handover, you might as well use it all the time, even when the mobile node is attached to IPv6 access networks. :) Vijay From nemo-bounces@ietf.org Mon Nov 12 13:55:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IreRW-0004Cz-3E; Mon, 12 Nov 2007 13:55:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IreRV-0004Cl-3K; Mon, 12 Nov 2007 13:55:29 -0500 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IreRS-0000DP-DT; Mon, 12 Nov 2007 13:55:29 -0500 Received: from localhost ([127.0.0.1]:34472 helo=chardonnay.local ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IreRP-0007hf-1Z; Mon, 12 Nov 2007 19:55:23 +0100 Message-ID: <4738A19A.2030506@levkowetz.com> Date: Mon, 12 Nov 2007 19:55:22 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion References: <472F69A3.5090400@azairenet.com> <47312611.5050205@azairenet.com> <47315ED2.1060807@azairenet.com> <47320540.2080205@azairenet.com> <4734E7FB.1080100@azairenet.com> <47389EC4.4010800@azairenet.com> In-Reply-To: <47389EC4.4010800@azairenet.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: vijay.devarapalli@azairenet.com, vidyan@qualcomm.com, nemo@ietf.org, mip6@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -1.4 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org On 2007-11-12 19:43 Vijay Devarapalli said the following: > Narayanan, Vidya wrote: ... >> Ok, this discussion is tiring and unproductive and this will be my last >> email on this topic. For the last time, I was NOT proposing MOBIKE to >> be the *only* mechanism for this scenario - all I was saying was that it >> doesn't involve tentative binding cache entries or sequential roundtrips >> and hence, needs to be permitted and documented as such as an *option*. > > Ok. But I am still objecting to specifying the use of MOBIKE as one > of the solutions in the DS-MIPv6 document. There are multiple reason. > It may require two round trips during the handover. And You will > have two mobility management protocols running at the same time. > > I do agree with Hesham that we can't really prevent if someone wants > to use MOBIKE at the same time. > > I suggest a separate document on this if you still want MOBIKE to be > an alternative. I agree with Vijay's viewpoints above. Henrik From JulianoffloadWade@aktanker.com Mon Nov 12 14:16:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ireln-0005tI-Is; Mon, 12 Nov 2007 14:16:27 -0500 Received: from 123-192-72-180.dynamic.kbronet.com.tw ([123.192.72.180] helo=chan) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Irelm-0006FB-QZ; Mon, 12 Nov 2007 14:16:27 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host09775867.aktanker.com (8.13.1/8.13.1) with SMTP id icXwJD0c48.509109.UVK.9qZ.5338935938310 for ; Tue, 13 Nov 2007 03:15:55 -0800 Message-ID: <2919601c82560$7ee51690$6402a8c0@Chan> From: "Bob Davidson" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_29192_01C82560.7EE51690-- From nemo-bounces@ietf.org Mon Nov 12 18:24:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iridg-0007vf-W8; Mon, 12 Nov 2007 18:24:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iridf-0007p9-Tj; Mon, 12 Nov 2007 18:24:19 -0500 Received: from deimos.multihop.net ([74.0.36.190] helo=multihop.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iridf-0000MH-5R; Mon, 12 Nov 2007 18:24:19 -0500 Received: by deimos.multihop.net (Postfix, from userid 1013) id 1DA4FA0A957; Mon, 12 Nov 2007 15:24:17 -0800 (PST) X-Spam-Score: -2.6 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on deimos.multihop.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.3 Received: from [192.103.16.145] (tj-desktop.nokia.net [192.103.16.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 35319A0A956; Mon, 12 Nov 2007 15:24:16 -0800 (PST) Message-ID: <4738E0CE.9010107@kniveton.com> Date: Mon, 12 Nov 2007 15:25:02 -0800 From: "T.J. Kniveton" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Henrik Levkowetz Subject: Re: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion References: <472F69A3.5090400@azairenet.com> <47312611.5050205@azairenet.com> <47315ED2.1060807@azairenet.com> <47320540.2080205@azairenet.com> <4734E7FB.1080100@azairenet.com> <47389EC4.4010800@azairenet.com> <4738A19A.2030506@levkowetz.com> In-Reply-To: <4738A19A.2030506@levkowetz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: nemo@ietf.org, mip6@ietf.org, Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Henrik Levkowetz wrote: > On 2007-11-12 19:43 Vijay Devarapalli said the following: > >> Narayanan, Vidya wrote: >> > ... > >>> Ok, this discussion is tiring and unproductive and this will be my last >>> email on this topic. For the last time, I was NOT proposing MOBIKE to >>> be the *only* mechanism for this scenario - all I was saying was that it >>> doesn't involve tentative binding cache entries or sequential roundtrips >>> and hence, needs to be permitted and documented as such as an *option*. >>> >> Ok. But I am still objecting to specifying the use of MOBIKE as one >> of the solutions in the DS-MIPv6 document. There are multiple reason. >> It may require two round trips during the handover. And You will >> have two mobility management protocols running at the same time. >> >> I do agree with Hesham that we can't really prevent if someone wants >> to use MOBIKE at the same time. >> >> I suggest a separate document on this if you still want MOBIKE to be >> an alternative. >> > > I agree with Vijay's viewpoints above. > > > Henrik > > > Same here. The potential reduction in latency for updates when traversing a NAT doesn't seem like a good tradeoff for the additional complexity of running two mobility management protocols. TJ From mext-bounces@ietf.org Mon Nov 12 20:33: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 1IrkeT-00080Q-Tv; Mon, 12 Nov 2007 20:33:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrkeT-00080G-5E for mext@ietf.org; Mon, 12 Nov 2007 20:33:17 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrkeS-0004aE-CP for mext@ietf.org; Mon, 12 Nov 2007 20:33:16 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lAD1XCaM023575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Nov 2007 17:33:12 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lAD1XCAN016978; Mon, 12 Nov 2007 17:33:12 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Nov 2007 17:33:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Nov 2007 17:33:12 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion Thread-Index: AcgjJTiEKpnbNwglS/yVqPJDJZzELQAE1+LAAEWuWRAAUVrKsA== References: From: "Narayanan, Vidya" To: "Hesham Soliman" X-OriginalArrivalTime: 13 Nov 2007 01:33:11.0866 (UTC) FILETIME=[273C09A0:01C82595] X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: mext@ietf.org Subject: [MEXT] RE: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion 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 Hesham, Yes, your observations are correct. It's not a question of stopping someone from using MOBIKE - I was more saying that the document should record that it is an option and have some notes on how that can be done. I see that a few of the people are opting for not including that, but, IMHO, that would be wrong. I haven't seen any good technical reasons why that is complex (as seems to be what is being hinted) other than the philosophy of using two mobility management protocols. We are not in a competition here between MOBIKE and MIP6 - the goal is to try and use the best technical solution.=20 Thanks, Vidya=20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Sunday, November 11, 2007 2:46 AM > To: Narayanan, Vidya > Cc: mext@ietf.org > Subject: RE: [Mip6] RE: [nemo] Please review and provide=20 > input to DSMIP6-IKEv2discussion >=20 > Vidya, (cleaned up the cc list and moved to mext) >=20 > Let me know if I understand what you're asking for correctly.=20 > Effectively you're saying that if we follow something like=20 > alternative 2, which allows IPsec tunnel mode over port 4500=20 > for normal traffic, then we should be able to use MOBIKE to=20 > update that SA. Is my understanding correct? >=20 >=20 > I believe there are two ways of updating the IKE SA in the=20 > presence of NATs, one is the "implicit mode" where IKE in the=20 > HA just sees that the addresses/ports have changed and it=20 > updates the SA accordingly. The other is obviously the=20 > explicit MOBIKE.=20 > So if I understand this correctly you're saying that we don't=20 > need to say "MOBIKE MUST be used", you're saying it should be=20 > possible to use MOBIKE. Is this a correct understanding?=20 >=20 > If I understood you correctly then I don't see how we can=20 > stop people from using MOBIKE. But of course if you want to=20 > mandate MOBIKE then it's a different discussion. Let me know=20 > if I got it right.=20 >=20 > Hesham=20 >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >=20 > Sent: Saturday, November 10, 2007 11:39 AM > To: Vijay=20 > Devarapalli > Cc: Basavaraj Patil; ext Hesham Soliman;=20 > mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] RE:=20 > [nemo] Please review and provide > input to=20 > DSMIP6-IKEv2discussion > > > > > I had proposed a solution=20 > for the tunnel mode too. > > > http://www1.ietf.org/mail-archive/web/mip6/current/msg06910.html > > > > > > Did you miss the email or just dismiss it? The solution=20 > in > > the mail at the above URL was the basis for what I=20 > wrote in > > the previous email. > > > > > > > Ok, this discussion is tiring and unproductive and this=20 > will > be my last > email on this topic. For the last=20 > time, I was NOT proposing > MOBIKE to > be the *only*=20 > mechanism for this scenario - all I was saying > was that it=20 > > doesn't involve tentative binding cache entries or >=20 > sequential roundtrips > and hence, needs to be permitted and=20 > documented as such as > an *option*. > > We haven't been discussing your other email, since I never=20 > > objected to > allowing a non-MOBIKE approach for the=20 > problem also.=20 > > > > > > > > For example, movement detection and two round trips for=20 > the > > MOBIKE update. > > > > > > > We already said that two roundtrips are unavoidable for=20 > updating a > tunnel mode SA in the presence of NATs. With=20 > MOBIKE, the updates are > happening in parallel and hence,=20 > there isn't a latency impact. With > sequential updates=20 > required for handover, there is a latency > impact and >=20 > with the solution you proposed, there is a window of time=20 > where the > insecure binding cache updates need to be=20 > accepted. With MOBIKE, > neither of these drawbacks apply. =20 > So, I don't understand the logic > where we deliberately=20 > disallow a no-drawback solution and > only propose > to use=20 > the ones with drawbacks.=20 > > > > > >> BTW, you need to convince the WG to make the change.=20 > Not > > ask why I am > > >> objecting. :) > > >> > > > >=20 > > > I don't see anyone else objecting (or saying anything for=20 > > > that matter) > > > on this topic. > > > > > > Nobody is supporting it. > > > > > > > Not the point, since you said the WG needs convincing; >=20 > nobody is asking > to be convinced and you are the only one=20 > objecting it. =20 > > > > Vidya > >=20 >=20 >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 12 20: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 1Irkjz-0007Xc-NA; Mon, 12 Nov 2007 20:39:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irkjy-0007XS-Ss for mext@ietf.org; Mon, 12 Nov 2007 20:38:58 -0500 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irkju-00068t-8P for mext@ietf.org; Mon, 12 Nov 2007 20:38:58 -0500 Received: from oaamta04sl.mx.bigpond.com ([124.190.106.219]) by omta05sl.mx.bigpond.com with ESMTP id <20071113013850.GLFH14987.omta05sl.mx.bigpond.com@oaamta04sl.mx.bigpond.com> for ; Tue, 13 Nov 2007 01:38:50 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta04sl.mx.bigpond.com with ESMTP id <20071113013850.HXLU11084.oaamta04sl.mx.bigpond.com@PC20005>; Tue, 13 Nov 2007 01:38:50 +0000 From: "Hesham Soliman" To: "'Narayanan, Vidya'" Date: Tue, 13 Nov 2007 12:38:38 +1000 Message-ID: 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.3198 Thread-Index: AcgjJTiEKpnbNwglS/yVqPJDJZzELQAE1+LAAEWuWRAAUVrKsAACSZFw In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: mext@ietf.org Subject: [MEXT] RE: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion 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 agree of course the MOBIKE is one of the solutions for this. I don't have a problem mentioning that in the draft but let's see the balance of opinions on this. I hope everyone provides technical reasons regardless of which way they prefer. Hesham > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Tuesday, November 13, 2007 11:33 AM > To: Hesham Soliman > Cc: mext@ietf.org > Subject: RE: [Mip6] RE: [nemo] Please review and provide > input to DSMIP6-IKEv2discussion > > Hi Hesham, > Yes, your observations are correct. It's not a question of stopping > someone from using MOBIKE - I was more saying that the > document should > record that it is an option and have some notes on how that > can be done. > I see that a few of the people are opting for not including > that, but, > IMHO, that would be wrong. I haven't seen any good technical reasons > why that is complex (as seems to be what is being hinted) > other than the > philosophy of using two mobility management protocols. We > are not in a > competition here between MOBIKE and MIP6 - the goal is to try and use > the best technical solution. > > Thanks, > Vidya > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Sunday, November 11, 2007 2:46 AM > > To: Narayanan, Vidya > > Cc: mext@ietf.org > > Subject: RE: [Mip6] RE: [nemo] Please review and provide > > input to DSMIP6-IKEv2discussion > > > > Vidya, (cleaned up the cc list and moved to mext) > > > > Let me know if I understand what you're asking for correctly. > > Effectively you're saying that if we follow something like > > alternative 2, which allows IPsec tunnel mode over port 4500 > > for normal traffic, then we should be able to use MOBIKE to > > update that SA. Is my understanding correct? > > > > > > I believe there are two ways of updating the IKE SA in the > > presence of NATs, one is the "implicit mode" where IKE in the > > HA just sees that the addresses/ports have changed and it > > updates the SA accordingly. The other is obviously the > > explicit MOBIKE. > > So if I understand this correctly you're saying that we don't > > need to say "MOBIKE MUST be used", you're saying it should be > > possible to use MOBIKE. Is this a correct understanding? > > > > If I understood you correctly then I don't see how we can > > stop people from using MOBIKE. But of course if you want to > > mandate MOBIKE then it's a different discussion. Let me know > > if I got it right. > > > > Hesham > > > > > -----Original Message----- > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > Sent: Saturday, November 10, 2007 11:39 AM > To: Vijay > > Devarapalli > Cc: Basavaraj Patil; ext Hesham Soliman; > > mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] RE: > > [nemo] Please review and provide > input to > > DSMIP6-IKEv2discussion > > > > > I had proposed a solution > > for the tunnel mode too. > > > > > http://www1.ietf.org/mail-archive/web/mip6/current/msg06910.html > > > > > > > > Did you miss the email or just dismiss it? The solution > > in > > the mail at the above URL was the basis for what I > > wrote in > > the previous email. > > > > > > > > > > Ok, this discussion is tiring and unproductive and this > > will > be my last > email on this topic. For the last > > time, I was NOT proposing > MOBIKE to > be the *only* > > mechanism for this scenario - all I was saying > was that it > > > doesn't involve tentative binding cache entries or > > > sequential roundtrips > and hence, needs to be permitted and > > documented as such as > an *option*. > > > We haven't been discussing your other email, since I never > > > objected to > allowing a non-MOBIKE approach for the > > problem also. > > > > > > > > > > > For example, movement detection and two round trips for > > the > > MOBIKE update. > > > > > > > > > > We already said that two roundtrips are unavoidable for > > updating a > tunnel mode SA in the presence of NATs. With > > MOBIKE, the updates are > happening in parallel and hence, > > there isn't a latency impact. With > sequential updates > > required for handover, there is a latency > impact and > > > with the solution you proposed, there is a window of time > > where the > insecure binding cache updates need to be > > accepted. With MOBIKE, > neither of these drawbacks apply. > > So, I don't understand the logic > where we deliberately > > disallow a no-drawback solution and > only propose > to use > > the ones with drawbacks. > > > > > > > >> BTW, you need to convince the WG to make the change. > > Not > > ask why I am > > >> objecting. :) > > >> > > > > > > > > I don't see anyone else objecting (or saying anything for > > > > that matter) > > > on this topic. > > > > > > > > Nobody is supporting it. > > > > > > > > > > Not the point, since you said the WG needs convincing; > > > nobody is asking > to be convinced and you are the only one > > objecting it. > > > > > > Vidya > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From JoycelandslideGoss@sportstravel.com Mon Nov 12 20:43:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrkoJ-0005k8-1N; Mon, 12 Nov 2007 20:43:27 -0500 Received: from [200.122.195.235] (helo=central.intercable.net.co) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IrkoI-0004rD-D7; Mon, 12 Nov 2007 20:43:26 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host79057363.sportstravel.com (8.13.1/8.13.1) with SMTP id 6r4X8oNt97.585272.Dys.6Mk.9613044658462 for ; Mon, 12 Nov 2007 20:43:03 +0500 Message-ID: <6ed6001c82596$93144380$ebc37ac8@CENTRAL> From: "Doris Mackey" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_6ED5C_01C82596.93144380-- From Gianantonio242@azazello.org Mon Nov 12 23:32:09 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrnRZ-0004rK-FP for nemo-archive@lists.ietf.org; Mon, 12 Nov 2007 23:32:09 -0500 Received: from [80.191.128.153] (helo=[80.191.128.198]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrnRY-0001ky-HS for nemo-archive@lists.ietf.org; Mon, 12 Nov 2007 23:32:09 -0500 Received: from post-2c37384050 ([162.185.141.184] helo=post-2c37384050) by [80.191.128.198] ( sendmail 8.13.3/8.13.1) with esmtpa id 1mdQJT-000OZK-gu for nemo-archive@lists.ietf.org; Tue, 13 Nov 2007 07:00:59 +03-30 Message-ID: <000901c825a5$8bf722c0$c680bf50@post2c37384050> From: "Gianantonio Cassibo" To: Subject: anasa Date: Tue, 13 Nov 2007 07:00:32 +03-30 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C825C2.E2268EC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.6 (+++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0007_01C825C2.E2268EC0 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable small feet, small meat... aint it the truth JOHNaNTHONY Marchiori http://ugopoci.com/ ------=_NextPart_000_0007_01C825C2.E2268EC0 Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
small feet, small meat... aint it the = truth
JOHNaNTHONY Marchiori
http://ugopoci.com/
<= /HTML> ------=_NextPart_000_0007_01C825C2.E2268EC0-- From JackiespurtMilton@canadiandriver.com Tue Nov 13 02:00:46 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrplO-0006Zp-If; Tue, 13 Nov 2007 02:00:46 -0500 Received: from [89.129.172.42] (helo=jose0d04b6d3e2) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IrplO-0005gD-1d; Tue, 13 Nov 2007 02:00:46 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host06722578.canadiandriver.com (8.13.1/8.13.1) with SMTP id 92SzJgxd58.164599.dTz.n5y.2210145355399 for ; Tue, 13 Nov 2007 08:00:10 -0100 Message-ID: <1b19ed01c825c2$e68a8520$0401a8c0@jose0d04b6d3e2> From: "Lillie Arthur" To: Subject: Hi Date: Tue, 13 Nov 2007 08:00:10 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1B19E9_01C825C2.E68A8520" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_1B19E9_01C825C2.E68A8520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_1B19E9_01C825C2.E68A8520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_1B19E9_01C825C2.E68A8520-- From nemo-bounces@ietf.org Tue Nov 13 03:46: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 1IrrPi-0006m6-Lj; Tue, 13 Nov 2007 03:46:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrrPf-0006ks-Ij; Tue, 13 Nov 2007 03:46:28 -0500 Received: from datnt07.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrrPf-00013k-6U; Tue, 13 Nov 2007 03:46:27 -0500 X-AuditID: c26e2f18-00001504000020a8-10-4739644f03eb Received: from stingray.eu.tieto.com ([192.176.143.13]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 10:46:07 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 09:46:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] RE: [nemo] Please review and provideinput to DSMIP6-IKEv2discussion Date: Tue, 13 Nov 2007 09:46:23 +0100 Message-ID: In-Reply-To: <4738E0CE.9010107@kniveton.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: [nemo] Please review and provideinput to DSMIP6-IKEv2discussion Thread-Index: AcglgzGk/9txQgjSR8eKn1hB7n7G+AATa4eA References: <472F69A3.5090400@azairenet.com> <47312611.5050205@azairenet.com> <47315ED2.1060807@azairenet.com> <47320540.2080205@azairenet.com> <4734E7FB.1080100@azairenet.com> <47389EC4.4010800@azairenet.com><4738A19A.2030506@levkowetz.com> <4738E0CE.9010107@kniveton.com> From: To: , X-OriginalArrivalTime: 13 Nov 2007 08:46:24.0823 (UTC) FILETIME=[AC3E8470:01C825D1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org =20 > >> > >> I do agree with Hesham that we can't really prevent if=20 > someone wants > >> to use MOBIKE at the same time. > >> > >> I suggest a separate document on this if you still want=20 > MOBIKE to be > >> an alternative. > >> =20 > > > > I agree with Vijay's viewpoints above. > > > > > > Henrik > > > > > > =20 > Same here. The potential reduction in latency for updates when=20 > traversing a NAT doesn't seem like a good tradeoff for the additional=20 > complexity of running two mobility management protocols. >=20 > TJ >=20 Doing this in a separate document sounds like the best approach. Especially so, given that the potential usage of MOBIKE is not particular to DSMIP (read also relevant for MIPv6). Karen > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 From mext-bounces@ietf.org Tue Nov 13 04:30: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 1Irs63-0000um-5V; Tue, 13 Nov 2007 04:30:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irs61-0000rb-NX for mext@ietf.org; Tue, 13 Nov 2007 04:30:13 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Irs5z-0002X0-5a for mext@ietf.org; Tue, 13 Nov 2007 04:30:13 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1194946209!32926039!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 31413 invoked from network); 13 Nov 2007 09:30:10 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-4.tower-119.messagelabs.com with SMTP; 13 Nov 2007 09:30:10 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lAD9U9Eb012294 for ; Tue, 13 Nov 2007 02:30:09 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lAD9U9D0018673 for ; Tue, 13 Nov 2007 03:30:09 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id lAD9U77J018566 for ; Tue, 13 Nov 2007 03:30:08 -0600 (CST) Message-ID: <47396E95.4030907@gmail.com> Date: Tue, 13 Nov 2007 10:29:57 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: mext@ietf.org Content-Type: multipart/mixed; boundary="------------070700040807080003010104" X-Antivirus: avast! (VPS 071112-0, 12/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Subject: [MEXT] [Fwd: RFC Errata] 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 This is a multi-part message in MIME format. --------------070700040807080003010104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This new errata tool could be used for (at least) RFC3775 and RFC3963. http://www.rfc-editor.org/errata.php Where is the rfc3775 list of issues? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ --------------070700040807080003010104 Content-Type: message/rfc822; name="RFC Errata.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="RFC Errata.eml" Received: from zuk35exf60.ds.mot.com ([10.178.4.12]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Mon, 12 Nov 2007 23:44:28 +0000 Received: from az33exr04.mot.com ([10.64.251.234]) by zuk35exf60.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Mon, 12 Nov 2007 23:44:27 +0000 Received: from motgate2.mot.com (motgate2.mot.com [144.189.100.101]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id lACNiKjk011545 for ; Mon, 12 Nov 2007 17:44:21 -0600 (CST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by motgate2.mot.com (8.12.11/Motorola) with SMTP id lACNiJju025013 for ; Mon, 12 Nov 2007 16:44:20 -0700 (MST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu+caf_=alexandru.petrescu=motorola.com@gma il.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1194911057!10558577!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.85.134.190] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP Received: (qmail 30701 invoked from network); 12 Nov 2007 23:44:18 -0000 Received: from mu-out-0910.google.com (HELO mu-out-0910.google.com) (209.85.134.190) by server-10.tower-128.messagelabs.com with SMTP; 12 Nov 2007 23:44:18 -0000 Received: by mu-out-0910.google.com with SMTP id i10so1624999mue for ; Mon, 12 Nov 2007 15:44:17 -0800 (PST) Received: by 10.82.160.19 with SMTP id i19mr13179092bue.1194911056720; Mon, 12 Nov 2007 15:44:16 -0800 (PST) X-Forwarded-To: alexandru.petrescu@motorola.com X-Forwarded-For: alexandru.petrescu@gmail.com alexandru.petrescu@motorola.com Delivered-To: alexandru.petrescu@gmail.com Received: by 10.82.100.3 with SMTP id x3cs551989bub; Mon, 12 Nov 2007 15:44:16 -0800 (PST) Received: by 10.100.206.11 with SMTP id d11mr8518792ang.1194911055121; Mon, 12 Nov 2007 15:44:15 -0800 (PST) Received: from megatron.ietf.org (megatron.ietf.ORG [156.154.16.145]) by mx.google.com with ESMTP id r28si5303856ele.2007.11.12.15.44.11; Mon, 12 Nov 2007 15:44:15 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of ietf-announce-bounces@ietf.org designates 156.154.16.145 as permitted sender) client-ip=156.154.16.145; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of ietf-announce-bounces@ietf.org designates 156.154.16.145 as permitted sender) smtp.mail=ietf-announce-bounces@ietf.org Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iriwm-0004jH-DU; Mon, 12 Nov 2007 18:44:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iriwl-0004j5-83 for ietf-announce@ietf.org; Mon, 12 Nov 2007 18:44:03 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iriwi-0002pj-TV for ietf-announce@ietf.org; Mon, 12 Nov 2007 18:44:03 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lACNhEFH007576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Nov 2007 15:43:14 -0800 (PST) Received: (from rfc-ed@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id lACNhEb9007575; Mon, 12 Nov 2007 15:43:14 -0800 (PST) Date: Mon, 12 Nov 2007 15:43:14 -0800 From: RFC Editor To: , Message-ID: <20071112234314.GA10357@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@boreas.isi.edu X-Spam-Score: -15.0 (---------------) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: , RFC Editor Subject: RFC Errata X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org Return-Path: alexandru.petrescu+caf_=alexandru.petrescu=motorola.com@gmail.com X-OriginalArrivalTime: 12 Nov 2007 23:44:28.0108 (UTC) FILETIME=[F6C590C0:01C82585] X-Antivirus: avast! (VPS 071112-0, 12/11/2007), Inbound message X-Antivirus-Status: Clean Greetings, The RFC Editor has transitioned to a new errata system, which has been updated to include all reports from the pending file (ftp://ftp.rfc-editor.org/in-notes/pending-errata/pending-errata.msgs). This new system allows users to report errata online. http://www.rfc-editor.org/errata.php For more information, please see: How to Report Errata http://www.rfc-editor.org/how_to_report.html Reporting errata online triggers the following: 1) The errata are marked "Reported" (i.e., the errata have not yet been verified), and are publicly posted for review and verification. 2) Email is sent to the authors of the RFC and the verifying party, as determined by the stream that produced the RFC: Stream --> SSP (stream specific party) ----------------------------------------------------------- IAB --> IAB IETF --> IESG IRTF --> IRSG Independent --> RFC Editor & the RFC Editorial Board Submission 3) SSPs can edit, verify, or reject posted errata using the errata verification system that is now available. Please let us know if you have any questions or concerns. Feedback is encouraged, as your feedback is important to shaping the system. Please send comments to the RFC-Interest list: rfc-interest@rfc-editor.org Thank you. The RFC Editor Team _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --------------070700040807080003010104 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 --------------070700040807080003010104-- From ReubenpeanutSmall@gsifirearms.com Tue Nov 13 09:16:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrwYv-0007td-Cy; Tue, 13 Nov 2007 09:16:21 -0500 Received: from 41.red-88-18-142.staticip.rima-tde.net ([88.18.142.41] helo=winxpgos4c0o1u) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IrwYu-0005E1-Nl; Tue, 13 Nov 2007 09:16:21 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host16639707.gsifirearms.com (8.13.1/8.13.1) with SMTP id sJ410sgw03.458989.ZJ4.wEr.3439720209700 for ; Tue, 13 Nov 2007 15:15:51 -0100 Message-ID: <1499901c825ff$bf09ae30$2101a8c0@winxpgos4c0o1u> From: "Chase Dyer" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_14995_01C825FF.BF09AE30-- From Mellgren@africol.net Tue Nov 13 11:27:12 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrybY-00023U-De for nemo-archive@lists.ietf.org; Tue, 13 Nov 2007 11:27:12 -0500 Received: from [82.84.179.125] (helo=ppp-82-84-179-125.cust-adsl.tiscali.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrybX-0004kw-RN for nemo-archive@lists.ietf.org; Tue, 13 Nov 2007 11:27:12 -0500 Received: from anna-3ac8c304b3 ([144.112.184.130]:30344 "EHLO anna-3ac8c304b3" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by ppp-82-84-179-125.cust-adsl.tiscali.it with ESMTP id S22WYFCAYVRYYZCG (ORCPT ); Tue, 13 Nov 2007 17:27:30 +0100 Message-ID: <000201c82612$04d58cb0$7db35452@anna3ac8c304b3> From: "Loredana Mellgren" To: Subject: schaut Date: Tue, 13 Nov 2007 17:27:01 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C8261A.6699F4B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0008_01C8261A.6699F4B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Did you know.. 88% of ladies want a man that is big, they say its more = fulfilling Damari Blackwell http://www.wwwjxdy.com/ ------=_NextPart_000_0008_01C8261A.6699F4B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Did you know.. 88% of ladies want a man that = is big,=20 they say its more fulfilling
Damari Blackwell
http://www.wwwjxdy.com/
= ------=_NextPart_000_0008_01C8261A.6699F4B0-- From mext-bounces@ietf.org Tue Nov 13 13:44:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is0kE-0008AG-1L; Tue, 13 Nov 2007 13:44:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is0kC-00089y-Jk for mext@ietf.org; Tue, 13 Nov 2007 13:44:16 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is0kA-0007SD-Al for mext@ietf.org; Tue, 13 Nov 2007 13:44:16 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Nov 2007 10:44:13 -0800 Message-ID: <4739F07D.7080806@azairenet.com> Date: Tue, 13 Nov 2007 10:44:13 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [MEXT] [Fwd: RFC Errata] References: <47396E95.4030907@gmail.com> In-Reply-To: <47396E95.4030907@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2007 18:44:13.0592 (UTC) FILETIME=[2FB25180:01C82625] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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 Alexandru Petrescu wrote: > This new errata tool could be used for (at least) RFC3775 and RFC3963. > > http://www.rfc-editor.org/errata.php > > Where is the rfc3775 list of issues? The errata should not contain issues that we need to fix. They will be handled in 3775bis. I guess the errata should only contain some obvious errors we made in the draft. Vijay > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > ------------------------------------------------------------------------ > > Subject: > RFC Errata > From: > RFC Editor > Date: > Mon, 12 Nov 2007 15:43:14 -0800 > To: > , > > To: > , > CC: > , RFC Editor > > > Greetings, > > The RFC Editor has transitioned to a new errata system, which has > been updated to include all reports from the pending file > (ftp://ftp.rfc-editor.org/in-notes/pending-errata/pending-errata.msgs). > > > This new system allows users to report errata online. > > http://www.rfc-editor.org/errata.php > > For more information, please see: > > How to Report Errata > http://www.rfc-editor.org/how_to_report.html > > > Reporting errata online triggers the following: > > 1) The errata are marked "Reported" (i.e., the errata have not yet > been verified), and are publicly posted for review and verification. > > 2) Email is sent to the authors of the RFC and the verifying party, > as determined by the stream that produced the RFC: > > Stream --> SSP (stream specific party) > ----------------------------------------------------------- > IAB --> IAB > IETF --> IESG > IRTF --> IRSG > Independent --> RFC Editor & the RFC Editorial Board > Submission > > 3) SSPs can edit, verify, or reject posted errata using the errata > verification system that is now available. > > Please let us know if you have any questions or concerns. > Feedback is encouraged, as your feedback is important to shaping the > system. Please send comments to the RFC-Interest list: > > rfc-interest@rfc-editor.org > > Thank you. > > The RFC Editor Team > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 nemo-bounces@ietf.org Tue Nov 13 16:06: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 1Is2xT-0006Wo-NO; Tue, 13 Nov 2007 16:06:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is2xS-0006UV-Dh; Tue, 13 Nov 2007 16:06:06 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is2xR-0008Rd-Qt; Tue, 13 Nov 2007 16:06:06 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lADL5ZOL021641; Tue, 13 Nov 2007 23:05:51 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 23:05:43 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 15:05:03 -0600 Received: from 172.19.244.166 ([172.19.244.166]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 13 Nov 2007 21:05:02 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 13 Nov 2007 15:06:00 -0600 Subject: Re: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion From: Basavaraj Patil To: Levkowetz , Vijay Devarapalli Message-ID: Thread-Topic: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion Thread-Index: AcgmOP3pPGFEIZIsEdy1dQARJNUNiA== In-Reply-To: <4738A19A.2030506@levkowetz.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Nov 2007 21:05:03.0097 (UTC) FILETIME=[DBFE7690:01C82638] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I agree that the MIP6/DS-MIP6 protocol need not have a normative dependency on Mobike. I agree that it is one way of solving the issue but there are other solutions proposed as well that do not rely on Mobike. Requiring Mobike capability for MIP/DS-MIP6 is not essential. -Raj On 11/12/07 12:55 PM, "ext Henrik Levkowetz" wrote: > > > On 2007-11-12 19:43 Vijay Devarapalli said the following: >> Narayanan, Vidya wrote: > ... >>> Ok, this discussion is tiring and unproductive and this will be my last >>> email on this topic. For the last time, I was NOT proposing MOBIKE to >>> be the *only* mechanism for this scenario - all I was saying was that it >>> doesn't involve tentative binding cache entries or sequential roundtrips >>> and hence, needs to be permitted and documented as such as an *option*. >> >> Ok. But I am still objecting to specifying the use of MOBIKE as one >> of the solutions in the DS-MIPv6 document. There are multiple reason. >> It may require two round trips during the handover. And You will >> have two mobility management protocols running at the same time. >> >> I do agree with Hesham that we can't really prevent if someone wants >> to use MOBIKE at the same time. >> >> I suggest a separate document on this if you still want MOBIKE to be >> an alternative. > > I agree with Vijay's viewpoints above. > > > Henrik > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 From MyrapummelBrewster@reuters.com Tue Nov 13 16:19:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is3A6-0004Kn-6I; Tue, 13 Nov 2007 16:19:10 -0500 Received: from 85.136.177.247.dyn.user.ono.com ([85.136.177.247] helo=microsofb79f7e) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Is3A5-0000H4-EH; Tue, 13 Nov 2007 16:19:10 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host39428459.reuters.com (8.13.1/8.13.1) with SMTP id iCyOU6FD00.780094.lBn.RYa.1862952005647 for ; Tue, 13 Nov 2007 22:23:15 -0100 Message-ID: <24c3e01c8263b$72d07850$f7b18855@microsofb79f7e> From: "Pat Crowder" To: Subject: Your health Date: Tue, 13 Nov 2007 22:23:15 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_24C3A_01C8263B.72D07850" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_24C3A_01C8263B.72D07850 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_24C3A_01C8263B.72D07850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_24C3A_01C8263B.72D07850-- From nemo-bounces@ietf.org Tue Nov 13 18:52: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 1Is5Yu-0000E5-O2; Tue, 13 Nov 2007 18:52:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is5Yt-0000DK-IZ; Tue, 13 Nov 2007 18:52:55 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is5Ys-000459-U6; Tue, 13 Nov 2007 18:52:55 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lADNqkSp017096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Nov 2007 15:52:47 -0800 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lADNqiAf008859; Tue, 13 Nov 2007 15:52:45 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Nov 2007 15:52:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] RE: [nemo] Please review and provide input toDSMIP6-IKEv2discussion Date: Tue, 13 Nov 2007 15:52:41 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: [nemo] Please review and provide input toDSMIP6-IKEv2discussion Thread-Index: AcgmOP3pPGFEIZIsEdy1dQARJNUNiAAFlYqw References: <4738A19A.2030506@levkowetz.com> From: "Narayanan, Vidya" To: "Basavaraj Patil" , "Levkowetz" , "Vijay Devarapalli" X-OriginalArrivalTime: 13 Nov 2007 23:52:45.0143 (UTC) FILETIME=[4970D670:01C82650] X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I don't understand why an optional feature would introduce a normative dependency. Also, I'm not understanding the rationale behind keeping this out of the DSMIP6 spec - MOBIKE is a fully specified solution and all we need is a description of how it works with DSMIP6 (much like what we would write for regular IKEv2, probably even less), especially when that is technically the most optimal solution for this particular scenario being discussed. =20 I'm not talking about replacing MIP6 mobility management with MOBIKE mobility management for all cases - I'm only talking about handling IPv4 tunnel mode NAT-T with MOBIKE. The two solutions that are being proposed for this case in the base spec are both sub-optimal and we have an optimal solution fully baked and available. I'm puzzled by the conclusion that is being reached at here.=20 Vidya > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Tuesday, November 13, 2007 1:06 PM > To: Levkowetz; Vijay Devarapalli > Cc: nemo@ietf.org; mip6@ietf.org > Subject: Re: [Mip6] RE: [nemo] Please review and provide=20 > input toDSMIP6-IKEv2discussion >=20 >=20 > I agree that the MIP6/DS-MIP6 protocol need not have a=20 > normative dependency on Mobike. I agree that it is one way of=20 > solving the issue but there are other solutions proposed as=20 > well that do not rely on Mobike. > Requiring Mobike capability for MIP/DS-MIP6 is not essential. >=20 > -Raj >=20 >=20 > On 11/12/07 12:55 PM, "ext Henrik Levkowetz"=20 > wrote: >=20 > >=20 > >=20 > > On 2007-11-12 19:43 Vijay Devarapalli said the following: > >> Narayanan, Vidya wrote: > > ... > >>> Ok, this discussion is tiring and unproductive and this=20 > will be my=20 > >>> last email on this topic. For the last time, I was NOT proposing=20 > >>> MOBIKE to be the *only* mechanism for this scenario - all I was=20 > >>> saying was that it doesn't involve tentative binding=20 > cache entries=20 > >>> or sequential roundtrips and hence, needs to be permitted=20 > and documented as such as an *option*. > >>=20 > >> Ok. But I am still objecting to specifying the use of=20 > MOBIKE as one=20 > >> of the solutions in the DS-MIPv6 document. There are=20 > multiple reason. > >> It may require two round trips during the handover. And=20 > You will have=20 > >> two mobility management protocols running at the same time. > >>=20 > >> I do agree with Hesham that we can't really prevent if=20 > someone wants=20 > >> to use MOBIKE at the same time. > >>=20 > >> I suggest a separate document on this if you still want=20 > MOBIKE to be=20 > >> an alternative. > >=20 > > I agree with Vijay's viewpoints above. > >=20 > >=20 > > Henrik > >=20 > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 From SherriepathwayCassidy@williepbennett.com Tue Nov 13 21:03:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is7bD-0005ga-AS; Tue, 13 Nov 2007 21:03:27 -0500 Received: from [200.121.145.54] (helo=pc5) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Is7bC-0007FQ-Rm; Tue, 13 Nov 2007 21:03:27 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host87353451.williepbennett.com (8.13.1/8.13.1) with SMTP id XenIlfvW65.591845.xNF.uza.6434178597785 for ; Tue, 13 Nov 2007 21:02:51 +0500 Message-ID: <13e9401c82662$8835b210$0601a8c0@PC5> From: "Francine Davison" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_13E90_01C82662.8835B210-- From KathrinewiltPendleton@switchboard.com Tue Nov 13 23:36:08 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is9yy-0000RI-LA; Tue, 13 Nov 2007 23:36:08 -0500 Received: from pool-96-234-73-177.nwrknj.fios.verizon.net ([96.234.73.177] helo=cobra.home) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Is9yy-0001pY-Bb; Tue, 13 Nov 2007 23:36:08 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host90525928.switchboard.com (8.13.1/8.13.1) with SMTP id op54XyAm86.904240.nHc.wHf.9188376841666 for ; Tue, 13 Nov 2007 23:35:48 +0500 Message-ID: <43a3501c82677$e52d15c0$0401a8c0@COBRA> From: "Charmaine Ashby" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_43A31_01C82677.E52D15C0-- From nemo-bounces@ietf.org Wed Nov 14 00:50: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 1IsB9A-0006Zj-1y; Wed, 14 Nov 2007 00:50:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsB98-0006Xr-GF; Wed, 14 Nov 2007 00:50:42 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsB97-0003kh-ON; Wed, 14 Nov 2007 00:50:42 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lAE5nxPC014397; Wed, 14 Nov 2007 07:50:28 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 07:50:20 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 23:50:17 -0600 Received: from 10.241.59.70 ([10.241.59.70]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 14 Nov 2007 05:50:17 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 13 Nov 2007 23:51:16 -0600 Subject: Re: [Mip6] RE: [nemo] Please review and provide input toDSMIP6-IKEv2discussion From: Basavaraj Patil To: "ext Narayanan, Vidya" , Levkowetz , Vijay Devarapalli Message-ID: Thread-Topic: [Mip6] RE: [nemo] Please review and provide input toDSMIP6-IKEv2discussion Thread-Index: AcgmOP3pPGFEIZIsEdy1dQARJNUNiAAFlYqwAAzCtjY= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Nov 2007 05:50:17.0950 (UTC) FILETIME=[3C4F67E0:01C82682] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Vidya, The scope of the current discussion is of course limited to the usage of IKEv2 in the presence of NATs when the MN moves to a v4 network. What you are suggesting is that the issue can be solved if the MN has Mobike capability. This IMO makes it normative. However I have no problems if this is mentioned as an option for hosts which have Mobike capability. A DS-MIP6 host however does not need Mobike capability. To solve the IKEv2 issue, we need a solution that may be suboptimal (as you say). The few opinions that have been expressed indicate a preference for having usage of Mobike in the context of MIP6 specified in a separate I-D. I have not seen any support for using Mobike to solve the current problem even though it has been acknowledged that it is "a" solution. Hence I would recommend that the WG focus on specifying a non-Mobike solution to address the issue. -Raj On 11/13/07 5:52 PM, "ext Narayanan, Vidya" wrote: > I don't understand why an optional feature would introduce a normative > dependency. Also, I'm not understanding the rationale behind keeping > this out of the DSMIP6 spec - MOBIKE is a fully specified solution and > all we need is a description of how it works with DSMIP6 (much like what > we would write for regular IKEv2, probably even less), especially when > that is technically the most optimal solution for this particular > scenario being discussed. > > I'm not talking about replacing MIP6 mobility management with MOBIKE > mobility management for all cases - I'm only talking about handling IPv4 > tunnel mode NAT-T with MOBIKE. The two solutions that are being > proposed for this case in the base spec are both sub-optimal and we have > an optimal solution fully baked and available. I'm puzzled by the > conclusion that is being reached at here. > > Vidya > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Tuesday, November 13, 2007 1:06 PM >> To: Levkowetz; Vijay Devarapalli >> Cc: nemo@ietf.org; mip6@ietf.org >> Subject: Re: [Mip6] RE: [nemo] Please review and provide >> input toDSMIP6-IKEv2discussion >> >> >> I agree that the MIP6/DS-MIP6 protocol need not have a >> normative dependency on Mobike. I agree that it is one way of >> solving the issue but there are other solutions proposed as >> well that do not rely on Mobike. >> Requiring Mobike capability for MIP/DS-MIP6 is not essential. >> >> -Raj >> >> >> On 11/12/07 12:55 PM, "ext Henrik Levkowetz" >> wrote: >> >>> >>> >>> On 2007-11-12 19:43 Vijay Devarapalli said the following: >>>> Narayanan, Vidya wrote: >>> ... >>>>> Ok, this discussion is tiring and unproductive and this >> will be my >>>>> last email on this topic. For the last time, I was NOT proposing >>>>> MOBIKE to be the *only* mechanism for this scenario - all I was >>>>> saying was that it doesn't involve tentative binding >> cache entries >>>>> or sequential roundtrips and hence, needs to be permitted >> and documented as such as an *option*. >>>> >>>> Ok. But I am still objecting to specifying the use of >> MOBIKE as one >>>> of the solutions in the DS-MIPv6 document. There are >> multiple reason. >>>> It may require two round trips during the handover. And >> You will have >>>> two mobility management protocols running at the same time. >>>> >>>> I do agree with Hesham that we can't really prevent if >> someone wants >>>> to use MOBIKE at the same time. >>>> >>>> I suggest a separate document on this if you still want >> MOBIKE to be >>>> an alternative. >>> >>> I agree with Vijay's viewpoints above. >>> >>> >>> Henrik >>> >>> >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >> >> From GeneendicottLane@flickr.com Wed Nov 14 02:45:50 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsCwY-0008Dd-ET; Wed, 14 Nov 2007 02:45:50 -0500 Received: from a186-116.adsl.paltel.net ([213.6.186.116] helo=yoseef) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsCwW-0006uh-Cv; Wed, 14 Nov 2007 02:45:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host12124833.flickr.com (8.13.1/8.13.1) with SMTP id 9qECSRLa28.032010.1kF.vg5.6772224913270 for ; Wed, 14 Nov 2007 10:45:10 -0300 Message-ID: <48fa01c82692$5be0a9b0$0d00000a@yoseef> From: "Gilbert Riley" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_48F6_01C82692.5BE0A9B0-- From nemo-bounces@ietf.org Wed Nov 14 03:42:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsDpI-00047s-Ip; Wed, 14 Nov 2007 03:42:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsDpH-00047h-OJ for nemo@ietf.org; Wed, 14 Nov 2007 03:42:23 -0500 Received: from rv-out-0910.google.com ([209.85.198.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsDpG-0000Cd-WC for nemo@ietf.org; Wed, 14 Nov 2007 03:42:23 -0500 Received: by rv-out-0910.google.com with SMTP id l15so88246rvb for ; Wed, 14 Nov 2007 00:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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; bh=TT9b2e3nUpxEpCxjHdOxWXFjOkxO6GCKgiKL1Syc/ns=; b=UhdNlEIUz2BaqpRu9HfYxwYfNOq4smX49n8nEhxha0v1NFoSDIcqE0AH6xw57AfF8YdH7liPx5fY1hGS5ESo3UsVLbTBbnytACzgkWC0b87QNLKC0BeStTqULenED9MuvapIeJtMdHvJkJlQguqAjsz3jFv+32g9FHBTUf7RTP8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.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=Bgiou0Y+Q+YwyI8DqSSi05b4om7JojTQChNC47NwWzQnjqSyNz7Vk+lZ6wkAm1mTb78RPND1nPBrg+53nUf3GCb2n/+Vh1hD8zLlifXUz8tW8PcwGqG6ZLo+Ev8WZU0qzIpeaeXSlm+5ZchQFvGBsJWTp2wNdvBcA3fYgUgjGio= Received: by 10.141.20.7 with SMTP id x7mr3317542rvi.1195029741991; Wed, 14 Nov 2007 00:42:21 -0800 (PST) Received: by 10.141.177.11 with HTTP; Wed, 14 Nov 2007 00:42:16 -0800 (PST) Message-ID: Date: Wed, 14 Nov 2007 09:42:16 +0100 From: "George Tsirtsis" To: "Basavaraj Patil" Subject: Re: [Mip6] RE: [nemo] Please review and provide input toDSMIP6-IKEv2discussion In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: nemo@ietf.org, mip6@ietf.org, Levkowetz , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Raj et.al.,, My understanding is that we already have two solutions (sub-optimal and optimal) that do not require changes to IKEv2 and/or MOBIKE. The "sub-optimal" solution is what Hesham called solution 2 in an earlier thread: i.e., "Karen suggested a way of running IKE without any changes (again see the thread for details). In this approach DSMIPv6 BUs are secured with ESP as usual. Normal traffic is sent over the DSMIPv6 port. However, secure traffic is sent over the IKE port (4500)." The sub-optimality comes from the fact that the solution causes additional delay to cyphered traffic. We also have an optimal solution which is the same as the above except that MOBIKE is also used so that the additional delay for cyphered traffic is removed. Why don't we document both. The first being mandatory and the second optional? Thanks George On Nov 14, 2007 6:51 AM, Basavaraj Patil wrote: > > Hi Vidya, > > The scope of the current discussion is of course limited to the usage of > IKEv2 in the presence of NATs when the MN moves to a v4 network. > > What you are suggesting is that the issue can be solved if the MN has Mobike > capability. This IMO makes it normative. > However I have no problems if this is mentioned as an option for hosts which > have Mobike capability. > A DS-MIP6 host however does not need Mobike capability. To solve the IKEv2 > issue, we need a solution that may be suboptimal (as you say). > > The few opinions that have been expressed indicate a preference for having > usage of Mobike in the context of MIP6 specified in a separate I-D. I have > not seen any support for using Mobike to solve the current problem even > though it has been acknowledged that it is "a" solution. > > Hence I would recommend that the WG focus on specifying a non-Mobike > solution to address the issue. > > -Raj > > > > On 11/13/07 5:52 PM, "ext Narayanan, Vidya" wrote: > > > I don't understand why an optional feature would introduce a normative > > dependency. Also, I'm not understanding the rationale behind keeping > > this out of the DSMIP6 spec - MOBIKE is a fully specified solution and > > all we need is a description of how it works with DSMIP6 (much like what > > we would write for regular IKEv2, probably even less), especially when > > that is technically the most optimal solution for this particular > > scenario being discussed. > > > > I'm not talking about replacing MIP6 mobility management with MOBIKE > > mobility management for all cases - I'm only talking about handling IPv4 > > tunnel mode NAT-T with MOBIKE. The two solutions that are being > > proposed for this case in the base spec are both sub-optimal and we have > > an optimal solution fully baked and available. I'm puzzled by the > > conclusion that is being reached at here. > > > > Vidya > > > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >> Sent: Tuesday, November 13, 2007 1:06 PM > >> To: Levkowetz; Vijay Devarapalli > >> Cc: nemo@ietf.org; mip6@ietf.org > >> Subject: Re: [Mip6] RE: [nemo] Please review and provide > >> input toDSMIP6-IKEv2discussion > >> > >> > >> I agree that the MIP6/DS-MIP6 protocol need not have a > >> normative dependency on Mobike. I agree that it is one way of > >> solving the issue but there are other solutions proposed as > >> well that do not rely on Mobike. > >> Requiring Mobike capability for MIP/DS-MIP6 is not essential. > >> > >> -Raj > >> > >> > >> On 11/12/07 12:55 PM, "ext Henrik Levkowetz" > >> wrote: > >> > >>> > >>> > >>> On 2007-11-12 19:43 Vijay Devarapalli said the following: > >>>> Narayanan, Vidya wrote: > >>> ... > >>>>> Ok, this discussion is tiring and unproductive and this > >> will be my > >>>>> last email on this topic. For the last time, I was NOT proposing > >>>>> MOBIKE to be the *only* mechanism for this scenario - all I was > >>>>> saying was that it doesn't involve tentative binding > >> cache entries > >>>>> or sequential roundtrips and hence, needs to be permitted > >> and documented as such as an *option*. > >>>> > >>>> Ok. But I am still objecting to specifying the use of > >> MOBIKE as one > >>>> of the solutions in the DS-MIPv6 document. There are > >> multiple reason. > >>>> It may require two round trips during the handover. And > >> You will have > >>>> two mobility management protocols running at the same time. > >>>> > >>>> I do agree with Hesham that we can't really prevent if > >> someone wants > >>>> to use MOBIKE at the same time. > >>>> > >>>> I suggest a separate document on this if you still want > >> MOBIKE to be > >>>> an alternative. > >>> > >>> I agree with Vijay's viewpoints above. > >>> > >>> > >>> Henrik > >>> > >>> > >>> > >>> _______________________________________________ > >>> Mip6 mailing list > >>> Mip6@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mip6 > >> > >> > > > From nemo-bounces@ietf.org Wed Nov 14 03:55: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 1IsE21-0000ZF-G5; Wed, 14 Nov 2007 03:55:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsE20-0000Um-5r; Wed, 14 Nov 2007 03:55:32 -0500 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsE1y-0000Yr-4E; Wed, 14 Nov 2007 03:55:31 -0500 Received: from oaamta04ps.mx.bigpond.com ([124.190.106.219]) by omta01ps.mx.bigpond.com with ESMTP id <20071114085526.CJAU16290.omta01ps.mx.bigpond.com@oaamta04ps.mx.bigpond.com>; Wed, 14 Nov 2007 08:55:26 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta04ps.mx.bigpond.com with ESMTP id <20071114085526.BIBO9364.oaamta04ps.mx.bigpond.com@PC20005>; Wed, 14 Nov 2007 08:55:26 +0000 From: "Hesham Soliman" To: "'George Tsirtsis'" , "'Basavaraj Patil'" Subject: RE: [Mip6] RE: [nemo] Please review and provide inputtoDSMIP6-IKEv2discussion Date: Wed, 14 Nov 2007 19:55:14 +1000 Message-ID: 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.3198 Thread-Index: Acgmmlj/iDpeIsWHQZWyW2ruZ/R5zwACM5GA In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: nemo@ietf.org, mip6@ietf.org, 'Levkowetz' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org George, I don't know if this is an accurate categorisation but from my understanding, this is what we have: Solution 1, which is suboptimal from an implementation point of view Solution 2, which is suboptimal because of the reasons you mentioned below and I mentioned earlier. Solution Mobike, which is also suboptimal compared to 1 (in terms of messages) but more optimal compared to solution 2, which essentially needs IKE to re-establish the SA unless IKE dynamic updates are supported and we hope they are! So yes Mobike is faster than 2 (assuming IKE dynamic updates are not used) I think but not optimal. Hesham > -----Original Message----- > From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > Sent: Wednesday, November 14, 2007 6:42 PM > To: Basavaraj Patil > Cc: nemo@ietf.org; mip6@ietf.org; Levkowetz > Subject: Re: [Mip6] RE: [nemo] Please review and provide > inputtoDSMIP6-IKEv2discussion > > Hi Raj et.al.,, > > My understanding is that we already have two solutions (sub-optimal > and optimal) that do not require changes to IKEv2 and/or MOBIKE. > > The "sub-optimal" solution is what Hesham called solution 2 in an > earlier thread: i.e., > "Karen suggested a way of running IKE without any changes (again see > the thread for details). In this approach DSMIPv6 BUs are > secured with > ESP as usual. Normal traffic is sent over the DSMIPv6 port. However, > secure traffic is sent over the IKE port (4500)." The sub-optimality > comes from the fact that the solution causes additional delay to > cyphered traffic. > > We also have an optimal solution which is the same as the > above except > that MOBIKE is also used so that the additional delay for cyphered > traffic is removed. > > Why don't we document both. The first being mandatory and > the second optional? > > Thanks > George > > On Nov 14, 2007 6:51 AM, Basavaraj Patil > wrote: > > > > Hi Vidya, > > > > The scope of the current discussion is of course limited > to the usage of > > IKEv2 in the presence of NATs when the MN moves to a v4 network. > > > > What you are suggesting is that the issue can be solved if > the MN has Mobike > > capability. This IMO makes it normative. > > However I have no problems if this is mentioned as an > option for hosts which > > have Mobike capability. > > A DS-MIP6 host however does not need Mobike capability. To > solve the IKEv2 > > issue, we need a solution that may be suboptimal (as you say). > > > > The few opinions that have been expressed indicate a > preference for having > > usage of Mobike in the context of MIP6 specified in a > separate I-D. I have > > not seen any support for using Mobike to solve the current > problem even > > though it has been acknowledged that it is "a" solution. > > > > Hence I would recommend that the WG focus on specifying a > non-Mobike > > solution to address the issue. > > > > -Raj > > > > > > > > On 11/13/07 5:52 PM, "ext Narayanan, Vidya" > wrote: > > > > > I don't understand why an optional feature would > introduce a normative > > > dependency. Also, I'm not understanding the rationale > behind keeping > > > this out of the DSMIP6 spec - MOBIKE is a fully > specified solution and > > > all we need is a description of how it works with DSMIP6 > (much like what > > > we would write for regular IKEv2, probably even less), > especially when > > > that is technically the most optimal solution for this particular > > > scenario being discussed. > > > > > > I'm not talking about replacing MIP6 mobility management > with MOBIKE > > > mobility management for all cases - I'm only talking > about handling IPv4 > > > tunnel mode NAT-T with MOBIKE. The two solutions that are being > > > proposed for this case in the base spec are both > sub-optimal and we have > > > an optimal solution fully baked and available. I'm > puzzled by the > > > conclusion that is being reached at here. > > > > > > Vidya > > > > > >> -----Original Message----- > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > >> Sent: Tuesday, November 13, 2007 1:06 PM > > >> To: Levkowetz; Vijay Devarapalli > > >> Cc: nemo@ietf.org; mip6@ietf.org > > >> Subject: Re: [Mip6] RE: [nemo] Please review and provide > > >> input toDSMIP6-IKEv2discussion > > >> > > >> > > >> I agree that the MIP6/DS-MIP6 protocol need not have a > > >> normative dependency on Mobike. I agree that it is one way of > > >> solving the issue but there are other solutions proposed as > > >> well that do not rely on Mobike. > > >> Requiring Mobike capability for MIP/DS-MIP6 is not essential. > > >> > > >> -Raj > > >> > > >> > > >> On 11/12/07 12:55 PM, "ext Henrik Levkowetz" > > >> wrote: > > >> > > >>> > > >>> > > >>> On 2007-11-12 19:43 Vijay Devarapalli said the following: > > >>>> Narayanan, Vidya wrote: > > >>> ... > > >>>>> Ok, this discussion is tiring and unproductive and this > > >> will be my > > >>>>> last email on this topic. For the last time, I was > NOT proposing > > >>>>> MOBIKE to be the *only* mechanism for this scenario > - all I was > > >>>>> saying was that it doesn't involve tentative binding > > >> cache entries > > >>>>> or sequential roundtrips and hence, needs to be permitted > > >> and documented as such as an *option*. > > >>>> > > >>>> Ok. But I am still objecting to specifying the use of > > >> MOBIKE as one > > >>>> of the solutions in the DS-MIPv6 document. There are > > >> multiple reason. > > >>>> It may require two round trips during the handover. And > > >> You will have > > >>>> two mobility management protocols running at the same time. > > >>>> > > >>>> I do agree with Hesham that we can't really prevent if > > >> someone wants > > >>>> to use MOBIKE at the same time. > > >>>> > > >>>> I suggest a separate document on this if you still want > > >> MOBIKE to be > > >>>> an alternative. > > >>> > > >>> I agree with Vijay's viewpoints above. > > >>> > > >>> > > >>> Henrik > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> Mip6 mailing list > > >>> Mip6@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/mip6 > > >> > > >> > > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > From nemo-bounces@ietf.org Wed Nov 14 04:01: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 1IsE89-00083G-HF; Wed, 14 Nov 2007 04:01:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsE88-00080E-3O for nemo@ietf.org; Wed, 14 Nov 2007 04:01:52 -0500 Received: from rv-out-0910.google.com ([209.85.198.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsE86-0002A6-Te for nemo@ietf.org; Wed, 14 Nov 2007 04:01:52 -0500 Received: by rv-out-0910.google.com with SMTP id l15so91602rvb for ; Wed, 14 Nov 2007 01:01:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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; bh=x5XwMQ0OYjBlVRnlawlyKdabPuUk6j4s8RpyfPDsphU=; b=R2l5RPYQGg5FJ0huNgAnt0gjnWK6qqBppiD7dPsWICDvhnCAAsVk5V3tfV0KJAUHd5Xb7vOZmMguX19Ectbypiemqyp+DQ1JN+5yW5/OhApO85E3qqzQncy4Xt9N5hbVlchEuRUhYEw34+k6JIGUWIpvuaERcf6wtLQtcY1Qtvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.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=gfbsENphWnYz7P+BC+Y9JqNHkIW4NQZ+FpbhcL86Cbemp3kPqtx/yVyqU5kBMx+I8mS+M9WLWG8uA00iVf8Z6oE6ssYssIZB2C8cS4Y2S01P8St/4NT6KpPGVC3vJhPIqgFnE4KB4TpOdpHf4IygKrFXX8mbZvf5fjk/KRWDV7g= Received: by 10.141.153.16 with SMTP id f16mr655976rvo.1195030910314; Wed, 14 Nov 2007 01:01:50 -0800 (PST) Received: by 10.141.177.11 with HTTP; Wed, 14 Nov 2007 01:01:50 -0800 (PST) Message-ID: Date: Wed, 14 Nov 2007 10:01:50 +0100 From: "George Tsirtsis" To: "Hesham Soliman" Subject: Re: [Mip6] RE: [nemo] Please review and provide inputtoDSMIP6-IKEv2discussion In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: nemo@ietf.org, mip6@ietf.org, Levkowetz , Basavaraj Patil X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org OK, lets not get stack on the definition of the word "optimal" :-) My proposal is to make "Solution 2" mandatory, since it is fully implementable using just IKEv2 and DSMIPv6 and "Solution Mobike" optional, since it results in better performance than "Solution 1" but requires MOBIKE support in HA and MN.. George On Nov 14, 2007 10:55 AM, Hesham Soliman wrote: > George, > > I don't know if this is an accurate categorisation but from my > understanding, this is what we have: > > Solution 1, which is suboptimal from an implementation point of view > Solution 2, which is suboptimal because of the reasons you mentioned below > and I mentioned earlier. > Solution Mobike, which is also suboptimal compared to 1 (in terms of > messages) but more optimal compared to solution 2, which essentially needs > IKE to re-establish the SA unless IKE dynamic updates are supported and we > hope they are! > > So yes Mobike is faster than 2 (assuming IKE dynamic updates are not used) I > think but not optimal. > > Hesham > > > > -----Original Message----- > > From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > > Sent: Wednesday, November 14, 2007 6:42 PM > > To: Basavaraj Patil > > Cc: nemo@ietf.org; mip6@ietf.org; Levkowetz > > Subject: Re: [Mip6] RE: [nemo] Please review and provide > > inputtoDSMIP6-IKEv2discussion > > > > Hi Raj et.al.,, > > > > My understanding is that we already have two solutions (sub-optimal > > and optimal) that do not require changes to IKEv2 and/or MOBIKE. > > > > The "sub-optimal" solution is what Hesham called solution 2 in an > > earlier thread: i.e., > > "Karen suggested a way of running IKE without any changes (again see > > the thread for details). In this approach DSMIPv6 BUs are > > secured with > > ESP as usual. Normal traffic is sent over the DSMIPv6 port. However, > > secure traffic is sent over the IKE port (4500)." The sub-optimality > > comes from the fact that the solution causes additional delay to > > cyphered traffic. > > > > We also have an optimal solution which is the same as the > > above except > > that MOBIKE is also used so that the additional delay for cyphered > > traffic is removed. > > > > Why don't we document both. The first being mandatory and > > the second optional? > > > > Thanks > > George > > > > On Nov 14, 2007 6:51 AM, Basavaraj Patil > > wrote: > > > > > > Hi Vidya, > > > > > > The scope of the current discussion is of course limited > > to the usage of > > > IKEv2 in the presence of NATs when the MN moves to a v4 network. > > > > > > What you are suggesting is that the issue can be solved if > > the MN has Mobike > > > capability. This IMO makes it normative. > > > However I have no problems if this is mentioned as an > > option for hosts which > > > have Mobike capability. > > > A DS-MIP6 host however does not need Mobike capability. To > > solve the IKEv2 > > > issue, we need a solution that may be suboptimal (as you say). > > > > > > The few opinions that have been expressed indicate a > > preference for having > > > usage of Mobike in the context of MIP6 specified in a > > separate I-D. I have > > > not seen any support for using Mobike to solve the current > > problem even > > > though it has been acknowledged that it is "a" solution. > > > > > > Hence I would recommend that the WG focus on specifying a > > non-Mobike > > > solution to address the issue. > > > > > > -Raj > > > > > > > > > > > > On 11/13/07 5:52 PM, "ext Narayanan, Vidya" > > wrote: > > > > > > > I don't understand why an optional feature would > > introduce a normative > > > > dependency. Also, I'm not understanding the rationale > > behind keeping > > > > this out of the DSMIP6 spec - MOBIKE is a fully > > specified solution and > > > > all we need is a description of how it works with DSMIP6 > > (much like what > > > > we would write for regular IKEv2, probably even less), > > especially when > > > > that is technically the most optimal solution for this particular > > > > scenario being discussed. > > > > > > > > I'm not talking about replacing MIP6 mobility management > > with MOBIKE > > > > mobility management for all cases - I'm only talking > > about handling IPv4 > > > > tunnel mode NAT-T with MOBIKE. The two solutions that are being > > > > proposed for this case in the base spec are both > > sub-optimal and we have > > > > an optimal solution fully baked and available. I'm > > puzzled by the > > > > conclusion that is being reached at here. > > > > > > > > Vidya > > > > > > > >> -----Original Message----- > > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > >> Sent: Tuesday, November 13, 2007 1:06 PM > > > >> To: Levkowetz; Vijay Devarapalli > > > >> Cc: nemo@ietf.org; mip6@ietf.org > > > >> Subject: Re: [Mip6] RE: [nemo] Please review and provide > > > >> input toDSMIP6-IKEv2discussion > > > >> > > > >> > > > >> I agree that the MIP6/DS-MIP6 protocol need not have a > > > >> normative dependency on Mobike. I agree that it is one way of > > > >> solving the issue but there are other solutions proposed as > > > >> well that do not rely on Mobike. > > > >> Requiring Mobike capability for MIP/DS-MIP6 is not essential. > > > >> > > > >> -Raj > > > >> > > > >> > > > >> On 11/12/07 12:55 PM, "ext Henrik Levkowetz" > > > >> wrote: > > > >> > > > >>> > > > >>> > > > >>> On 2007-11-12 19:43 Vijay Devarapalli said the following: > > > >>>> Narayanan, Vidya wrote: > > > >>> ... > > > >>>>> Ok, this discussion is tiring and unproductive and this > > > >> will be my > > > >>>>> last email on this topic. For the last time, I was > > NOT proposing > > > >>>>> MOBIKE to be the *only* mechanism for this scenario > > - all I was > > > >>>>> saying was that it doesn't involve tentative binding > > > >> cache entries > > > >>>>> or sequential roundtrips and hence, needs to be permitted > > > >> and documented as such as an *option*. > > > >>>> > > > >>>> Ok. But I am still objecting to specifying the use of > > > >> MOBIKE as one > > > >>>> of the solutions in the DS-MIPv6 document. There are > > > >> multiple reason. > > > >>>> It may require two round trips during the handover. And > > > >> You will have > > > >>>> two mobility management protocols running at the same time. > > > >>>> > > > >>>> I do agree with Hesham that we can't really prevent if > > > >> someone wants > > > >>>> to use MOBIKE at the same time. > > > >>>> > > > >>>> I suggest a separate document on this if you still want > > > >> MOBIKE to be > > > >>>> an alternative. > > > >>> > > > >>> I agree with Vijay's viewpoints above. > > > >>> > > > >>> > > > >>> Henrik > > > >>> > > > >>> > > > >>> > > > >>> _______________________________________________ > > > >>> Mip6 mailing list > > > >>> Mip6@ietf.org > > > >>> https://www1.ietf.org/mailman/listinfo/mip6 > > > >> > > > >> > > > > > > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > From nemo-bounces@ietf.org Wed Nov 14 04:29:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEZJ-0006iM-Tq; Wed, 14 Nov 2007 04:29:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEZI-0006d9-4T; Wed, 14 Nov 2007 04:29:56 -0500 Received: from omta04ps.mx.bigpond.com ([144.140.83.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsEZD-0002zp-65; Wed, 14 Nov 2007 04:29:56 -0500 Received: from oaamta04ps.mx.bigpond.com ([124.190.106.219]) by omta04ps.mx.bigpond.com with ESMTP id <20071114092947.TRNF22884.omta04ps.mx.bigpond.com@oaamta04ps.mx.bigpond.com>; Wed, 14 Nov 2007 09:29:47 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta04ps.mx.bigpond.com with ESMTP id <20071114092946.BQNJ9364.oaamta04ps.mx.bigpond.com@PC20005>; Wed, 14 Nov 2007 09:29:46 +0000 From: "Hesham Soliman" To: "'George Tsirtsis'" Subject: RE: [Mip6] RE: [nemo] Please review and provide inputtoDSMIP6-IKEv2discussion Date: Wed, 14 Nov 2007 20:29:35 +1000 Message-ID: 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.3198 Thread-Index: AcgmnQSpDHdPafkkQ1yQssKFTJSZ7AAC9Ybw In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: nemo@ietf.org, mip6@ietf.org, 'Levkowetz' , 'Basavaraj Patil' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > OK, lets not get stack on the definition of the word "optimal" :-) => ok :) > > My proposal is to make "Solution 2" mandatory, since it is fully > implementable using just IKEv2 and DSMIPv6 and "Solution Mobike" > optional, since it results in better performance than > "Solution 1" but > requires MOBIKE support in HA and MN.. => It doesn't perform better than 1, it performs better than 2 if there is no support for dynamic updates. I.e. if the IKE daemon on the HA doesn't support dynamic updates solution 2 would need to re-run IKE to setup a new SA. But if dynamic updates are supported then both perform the same way AFAICS. I don't have a problem with mentioning Mobike as an option but several people seem to be against it. Frankly, I don't know why it's so bad to mention it as an option. Hesham > > George > > On Nov 14, 2007 10:55 AM, Hesham Soliman > wrote: > > George, > > > > I don't know if this is an accurate categorisation but from my > > understanding, this is what we have: > > > > Solution 1, which is suboptimal from an implementation > point of view > > Solution 2, which is suboptimal because of the reasons you > mentioned below > > and I mentioned earlier. > > Solution Mobike, which is also suboptimal compared to 1 > (in terms of > > messages) but more optimal compared to solution 2, which > essentially needs > > IKE to re-establish the SA unless IKE dynamic updates are > supported and we > > hope they are! > > > > So yes Mobike is faster than 2 (assuming IKE dynamic > updates are not used) I > > think but not optimal. > > > > Hesham > > > > > > > -----Original Message----- > > > From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > > > Sent: Wednesday, November 14, 2007 6:42 PM > > > To: Basavaraj Patil > > > Cc: nemo@ietf.org; mip6@ietf.org; Levkowetz > > > Subject: Re: [Mip6] RE: [nemo] Please review and provide > > > inputtoDSMIP6-IKEv2discussion > > > > > > Hi Raj et.al.,, > > > > > > My understanding is that we already have two solutions > (sub-optimal > > > and optimal) that do not require changes to IKEv2 and/or MOBIKE. > > > > > > The "sub-optimal" solution is what Hesham called > solution 2 in an > > > earlier thread: i.e., > > > "Karen suggested a way of running IKE without any > changes (again see > > > the thread for details). In this approach DSMIPv6 BUs are > > > secured with > > > ESP as usual. Normal traffic is sent over the DSMIPv6 > port. However, > > > secure traffic is sent over the IKE port (4500)." The > sub-optimality > > > comes from the fact that the solution causes additional delay to > > > cyphered traffic. > > > > > > We also have an optimal solution which is the same as the > > > above except > > > that MOBIKE is also used so that the additional delay > for cyphered > > > traffic is removed. > > > > > > Why don't we document both. The first being mandatory and > > > the second optional? > > > > > > Thanks > > > George > > > > > > On Nov 14, 2007 6:51 AM, Basavaraj Patil > > > wrote: > > > > > > > > Hi Vidya, > > > > > > > > The scope of the current discussion is of course limited > > > to the usage of > > > > IKEv2 in the presence of NATs when the MN moves to a > v4 network. > > > > > > > > What you are suggesting is that the issue can be solved if > > > the MN has Mobike > > > > capability. This IMO makes it normative. > > > > However I have no problems if this is mentioned as an > > > option for hosts which > > > > have Mobike capability. > > > > A DS-MIP6 host however does not need Mobike capability. To > > > solve the IKEv2 > > > > issue, we need a solution that may be suboptimal (as you say). > > > > > > > > The few opinions that have been expressed indicate a > > > preference for having > > > > usage of Mobike in the context of MIP6 specified in a > > > separate I-D. I have > > > > not seen any support for using Mobike to solve the current > > > problem even > > > > though it has been acknowledged that it is "a" solution. > > > > > > > > Hence I would recommend that the WG focus on specifying a > > > non-Mobike > > > > solution to address the issue. > > > > > > > > -Raj > > > > > > > > > > > > > > > > On 11/13/07 5:52 PM, "ext Narayanan, Vidya" > > > wrote: > > > > > > > > > I don't understand why an optional feature would > > > introduce a normative > > > > > dependency. Also, I'm not understanding the rationale > > > behind keeping > > > > > this out of the DSMIP6 spec - MOBIKE is a fully > > > specified solution and > > > > > all we need is a description of how it works with DSMIP6 > > > (much like what > > > > > we would write for regular IKEv2, probably even less), > > > especially when > > > > > that is technically the most optimal solution for > this particular > > > > > scenario being discussed. > > > > > > > > > > I'm not talking about replacing MIP6 mobility management > > > with MOBIKE > > > > > mobility management for all cases - I'm only talking > > > about handling IPv4 > > > > > tunnel mode NAT-T with MOBIKE. The two solutions > that are being > > > > > proposed for this case in the base spec are both > > > sub-optimal and we have > > > > > an optimal solution fully baked and available. I'm > > > puzzled by the > > > > > conclusion that is being reached at here. > > > > > > > > > > Vidya > > > > > > > > > >> -----Original Message----- > > > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > >> Sent: Tuesday, November 13, 2007 1:06 PM > > > > >> To: Levkowetz; Vijay Devarapalli > > > > >> Cc: nemo@ietf.org; mip6@ietf.org > > > > >> Subject: Re: [Mip6] RE: [nemo] Please review and provide > > > > >> input toDSMIP6-IKEv2discussion > > > > >> > > > > >> > > > > >> I agree that the MIP6/DS-MIP6 protocol need not have a > > > > >> normative dependency on Mobike. I agree that it is > one way of > > > > >> solving the issue but there are other solutions proposed as > > > > >> well that do not rely on Mobike. > > > > >> Requiring Mobike capability for MIP/DS-MIP6 is not > essential. > > > > >> > > > > >> -Raj > > > > >> > > > > >> > > > > >> On 11/12/07 12:55 PM, "ext Henrik Levkowetz" > > > > >> wrote: > > > > >> > > > > >>> > > > > >>> > > > > >>> On 2007-11-12 19:43 Vijay Devarapalli said the following: > > > > >>>> Narayanan, Vidya wrote: > > > > >>> ... > > > > >>>>> Ok, this discussion is tiring and unproductive and this > > > > >> will be my > > > > >>>>> last email on this topic. For the last time, I was > > > NOT proposing > > > > >>>>> MOBIKE to be the *only* mechanism for this scenario > > > - all I was > > > > >>>>> saying was that it doesn't involve tentative binding > > > > >> cache entries > > > > >>>>> or sequential roundtrips and hence, needs to be > permitted > > > > >> and documented as such as an *option*. > > > > >>>> > > > > >>>> Ok. But I am still objecting to specifying the use of > > > > >> MOBIKE as one > > > > >>>> of the solutions in the DS-MIPv6 document. There are > > > > >> multiple reason. > > > > >>>> It may require two round trips during the handover. And > > > > >> You will have > > > > >>>> two mobility management protocols running at the > same time. > > > > >>>> > > > > >>>> I do agree with Hesham that we can't really prevent if > > > > >> someone wants > > > > >>>> to use MOBIKE at the same time. > > > > >>>> > > > > >>>> I suggest a separate document on this if you still want > > > > >> MOBIKE to be > > > > >>>> an alternative. > > > > >>> > > > > >>> I agree with Vijay's viewpoints above. > > > > >>> > > > > >>> > > > > >>> Henrik > > > > >>> > > > > >>> > > > > >>> > > > > >>> _______________________________________________ > > > > >>> Mip6 mailing list > > > > >>> Mip6@ietf.org > > > > >>> https://www1.ietf.org/mailman/listinfo/mip6 > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > From nemo-bounces@ietf.org Wed Nov 14 04:43: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 1IsElz-0008Pv-Dl; Wed, 14 Nov 2007 04:43:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsElx-0008N0-RD; Wed, 14 Nov 2007 04:43:01 -0500 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsElv-0003Ii-C3; Wed, 14 Nov 2007 04:43:01 -0500 Received: from localhost ([127.0.0.1]:47294 helo=chardonnay.local ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IsElq-0006iv-Ug; Wed, 14 Nov 2007 10:42:55 +0100 Message-ID: <473AC31E.4040500@levkowetz.com> Date: Wed, 14 Nov 2007 10:42:54 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] RE: [nemo] Please review and provide inputtoDSMIP6-IKEv2discussion References: In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Hesham@elevatemobile.com, tsirtsis@googlemail.com, nemo@ietf.org, mip6@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -1.4 (-) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham, On 2007-11-14 11:29 Hesham Soliman said the following: > I don't have a problem with mentioning Mobike as an option but several > people seem to be against it. Frankly, I don't know why it's so bad to > mention it as an option. 'Mentioning it as an option' sounds like something like a 1-sentence update. That's fine with me. 'Documenting it' (as has been said) sounds like a whole new section. I'm opposed to adding that to this document. Henrik From eva7chi-tai@belizemail.net Wed Nov 14 05:45:41 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFkb-0002S9-CE for nemo-archive@lists.ietf.org; Wed, 14 Nov 2007 05:45:41 -0500 Received: from pppoe-88-147-138-95.san.ru ([88.147.138.95]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsFka-0003xN-Mn for nemo-archive@lists.ietf.org; Wed, 14 Nov 2007 05:45:41 -0500 Received: from [88.147.138.95] by qnmf.belizemail.net; Wed, 14 Nov 2007 10:45:22 +0000 Message-ID: <000701c826ab$0488f83a$fb553fbd@kxhqx> From: "cordie adolph" To: "Gena Hagen" Subject: Luxury replicas at some of the lowest prices possible Date: Wed, 14 Nov 2007 08:57:59 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C826AB.04855897" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C826AB.04855897 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Replica Rolex Watches and More…Great Products, Great Prices!=20 http://popullatrave.net/ ------=_NextPart_000_0004_01C826AB.04855897 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Replica Rolex Watches and More…Great Products, Great Prices! =

http://popullatrave.net/ ------=_NextPart_000_0004_01C826AB.04855897-- From XavierelmerOlsen@switchboard.com Wed Nov 14 06:01:33 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFzw-000209-TF; Wed, 14 Nov 2007 06:01:32 -0500 Received: from eu85-86-152-42.clientes.euskaltel.es ([85.86.152.42] helo=argente2005.euskaltel.es) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsFzw-0004sl-E9; Wed, 14 Nov 2007 06:01:32 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host71851903.switchboard.com (8.13.1/8.13.1) with SMTP id MTMtp1JV65.538475.UVj.eC0.9219437661195 for ; Wed, 14 Nov 2007 12:00:57 -0100 Message-ID: <2b4101c826ad$b2ea5b00$2a985655@argente2005> From: "Buddy Booth" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_2B3D_01C826AD.B2EA5B00-- From nemo-bounces@ietf.org Wed Nov 14 07:58:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsHpX-0001Rl-Nn; Wed, 14 Nov 2007 07:58:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsHpV-0001Pa-Tj; Wed, 14 Nov 2007 07:58:53 -0500 Received: from omta03ps.mx.bigpond.com ([144.140.82.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsHpS-0000b5-6F; Wed, 14 Nov 2007 07:58:53 -0500 Received: from oaamta06ps.mx.bigpond.com ([124.190.106.219]) by omta03ps.mx.bigpond.com with ESMTP id <20071114125846.YKNA25130.omta03ps.mx.bigpond.com@oaamta06ps.mx.bigpond.com>; Wed, 14 Nov 2007 12:58:46 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta06ps.mx.bigpond.com with ESMTP id <20071114125845.DNLK27263.oaamta06ps.mx.bigpond.com@PC20005>; Wed, 14 Nov 2007 12:58:45 +0000 From: "Hesham Soliman" To: , Date: Wed, 14 Nov 2007 23:58:34 +1000 Message-ID: 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.3198 Thread-Index: AcgmxnJqDYia2gpSRAKybifz8Eu5Uw== X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: Pasi.Eronen@nokia.com Subject: [nemo] Resolution of IKEv2 and DSMIPv6 issue X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi all, This is the last outstanding issue for DSMIPv6. In addition to this issue I received comments on the draft, mainly editorial from George and Samita. I'll respond to Samita's non-editorial questions separately. After analysing all of the alternatives we clearly have no concensus for either alternative so I asked the chairs and the security reviewers to make this decision for us. Pasi did a lot of work to flush out solution 2 (thanks!) and I'm including his analysis below with minor fixes. The conclusion of the analysis was that solution 2 is preferred, mainly because it doesn't require any of the changes to the implementation that solution 1 required. So I believe we should go with that and resolve this issue. Please find the complete steps for solution 2 below, with assumptions: Solution 2 rephrased =========================== (Pasi Eronen 2007-11-08) NOTE 1: In this description, the DSMIPv6 tunnel has an "encapsulation" property with three different values: - "UDP for all traffic" is obvious. - "UDP for ESP-V6HoA-V6HA only" means that all ESP traffic between V6HoA and V6HA is UDP-encapsulated; all other traffic is straight IPv4/6-in-IPv4 (without UDP). - "IPv4/6-in-IPv6" obvious. NOTE 2: This example assumes that MOBIKE is not negotiated. NOTE 3: RFC4877 allows the MN to use tunnel mode for BUs. Here, transport mode MUST be used. NOTE 4: This example assumes that UDP encapsulation (for DSMIPv6 tunnel or ESP) is never used with IPv6 (also "forced UDP encapsulation" can't be used). I.e. MUST NOT do UDP encapsulation when the mobile node is in an IPv6-enabled network. Solution 2, IPv6 network -> IPv4 only network ============================================= 1. The MN updates its DSMIPv6 tunnel as follows: local address = V4CoA:DSMIPv6-port remote address = V4HA:DSMIPv6-port encapsulation = "UDP for all traffic" 2. The MN updates its local binding/routing/something table to tunnel all traffic *from* V6HoA/V4HoA over the DSMIPv6 tunnel. 3. The MN deletes all route optimization entries from its binding cache. 4. The MN updates its IKE_SA with the home agent as follows: local address = V4CoA:4500 remote address = V4HA:4500 NAT traversal = yes (pessimistic -- will be changed later) 5. The MN updates its *tunnel* mode IPsec SAD entries with the home agent as follows: local tunnel header address = V4CoA remote tunnel header address = V4HA UDP encapsulation = yes (pessimistic -- will be changed later) 6. The MN may also need to update information in its SPD, so that any new SAs get created with these tunnel header addresses. (This depends a bit on how IKE determines the correct peer when SA creation is needed.) 7. The MN sends a Binding Update, which looks like this: IPv4 header (src=V4CoA, dst=V4HA) UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT) IPv6 header (src=V6HoA, dst=V6HA) Destination Options header Home Address option (V6HoA) ESP header (transport mode) Mobility header Binding Update IPv4 Care-of Address option (V4CoA) 8. The HA receives a Binding Update IPv4 header (src=NATTED_V4CoA, dst=V4HA) UDP header (src=NATTED_DSMIPv6-PORT, dst=DSMIPv6-PORT) IPv6 header (src=V6HoA, dst=V6HA) Destination Options header Home Address option (V6HoA) ESP header (transport mode) Mobility header Binding Update IPv4 Care-of Address option (V4CoA) 9. The HA determines whether UDP encapsulation is used (if the MN requested it, or local policy requires it, or NATTED_V4CoA and V4CoA do not match). 10. The HA updates its local DSMIPv6 tunnel: local address = V4HA:DSMIPv6-PORT remote address = NATTED_V4CoA:NATTED-DSMIPv6-PORT encapsulation = "UDP for all traffic"/"UDP for ESP-V6HoA-V6HA only" 11. The HA updates its binding cache so that traffic to V6HoA and V4HoA is sent over the DSMIPv6 tunnel. 12. If the HA supports "K" flag, it updates its IKE_SA as follows: local address = V4HA:4500 remote address = NATTED_V4CoA:4500 NAT traversal = yes/no (NOTE: remote port number is wrong if doing NAT-T; this will be updated below) 13. The HA updates its *tunnel* mode IPsec SAD entries with MN: local tunnel header address = V4HA:4500 remote tunnel header address = NATTED_V4CoA:4500 UDP encapsulation = yes/no (NOTE: remote port number is wrong if doing NAT-T; this will be updated below) 14. The HA may also need to update information in its SPD (similarly as MN in step 6). 15. HA replies with a Binding Acknowledgement. IPv4 header (src=V4HA, dst=NATTED_V4CoA) UDP header (src=DSMIPv6-PORT, dst=NATTED_DSMIPv6-PORT) IPv6 header (src=V6HA, dst=V6HoA) Routing header (type 2): V6HoA ESP header (transport mode) Mobility header Binding Acknowledgement [NAT detection option] 16. MN updates the DSMIPv6 tunnel depending on the NAT detection option: encapsulation = "UDP for all traffic"/"UDP for ESP-V6HoA-V6HA only" 17. The MN updates IKE/IPsec state as follows: - "K" flag not set: - negotiate a new IKE_SA and new IPsec SAs replace all the existing IPsec SAs (both transport and tunnel mode), and close the old IKE_SA. - "K" flag set, no NAT Detection option (and no MOBIKE): - update IKE_SA: NAT traversal = no - update tunnel mode IPsec SAs: UDP encapsulation = no - "K" flag set, NAT Detection option (and no MOBIKE): - update IKE_SA: NAT traversal = yes - update tunnel mode IPsec SAs: UDP encapsulation = no 18. If the MN sent an empty Informational request, the HA will update its IKE_SA as follows: remote_address = NATTED_V4CoA:NATTED_PORT_4500 and tunnel mode IPsec SAD entries as follows: remote_address = V4CoA:NATTED_PORT_4500 19. MN sends Binding Updates to delete bindings with all Correspondent Nodes that were using route optimization. 20. Done The above steps would basically apply to a move from IPv4 to IPv4 as well. Solution 2, IPv4 only network -> IPv6 network ============================================= 1. The MN updates its DSMIPv6 tunnel as follows: local address = V6CoA remote address = V4HA encapsulation = "straight IPv4/6-in-IPv6" 2. The MN updates its local binding/routing/something table to tunnel all traffic *from* V6HoA/V4HoA over the DSMIPv6 tunnel (note: "from" here means IP header source address, not including e.g. Home Address option) 3. The MN updates its IKE_SA with the home agent as follows: local address = V6CoA:4500 remote address = V6HA:4500 NAT traversal = no 4. The MN updates its *tunnel* mode IPsec SAD entries with the home agent as follows: local tunnel header address = V6CoA remote tunnel header address = V6HA UDP encapsulation = no 5. The MN may also need to update information in its SPD, so that any new SAs get created with these tunnel header addresses. (This depends a bit on how IKE determines the correct peer when SA creation is needed.) 6. The MN sends a Binding Update, which looks like this: IPv6 header (src=V6CoA, dst=V6HA) Destination Options header Home Address option (V6HoA) ESP header (transport mode) Mobility header Binding Update Alternate Care-of Address option (V6Coa) 7. The HA updates its local DSMIPv6 tunnel: local address = V6HA remote address = V6CoA encapsulation = "straight IPv4/6-in-IPv6" 8. The HA updates its binding cache so that traffic to V6HoA and V4HoA is sent over the DSMIPv6 tunnel. 9. If the HA supports "K" flag, it updates its IKE_SA as follows: local address = V6HA:4500 remote address = V6CoA:4500 NAT traversal = no 10. The HA updates its *tunnel* mode IPsec SAD entries with MN: local tunnel header address = V6HA:4500 remote tunnel header address = V6CoA:4500 UDP encapsulation = no 11. The HA may also need to update information in its SPD (similarly as MN in step 6). 12. HA replies with a Binding Acknowledgement. IPv6 header (src=V6HA, dst=V6CoA) Routing header (type 2): V6HoA ESP header (transport mode) Mobility header Binding Acknowledgement 13. The MN updates IKE/IPsec state as follows: - "K" flag not set: - negotiate a new IKE_SA and new IPsec SAs replace all the existing IPsec SAs (both transport and tunnel mode), and close the old IKE_SA. - "K" flag set: - nothing needs to be done 14. MN could send Binding Updates to update bindings with Corrrespondent Nodes for route optimization. 15. Done Hesham From nemo-bounces@ietf.org Wed Nov 14 08:49: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 1IsIcG-0001MO-MY; Wed, 14 Nov 2007 08:49:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsIcE-0001Kx-2O; Wed, 14 Nov 2007 08:49:14 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsIcC-0004AB-Sk; Wed, 14 Nov 2007 08:49:13 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lAEDmP4g000516; Wed, 14 Nov 2007 15:48:49 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 15:48:30 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 07:48:25 -0600 Received: from 10.241.58.33 ([10.241.58.33]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 14 Nov 2007 13:48:25 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 14 Nov 2007 07:49:23 -0600 Subject: Re: [Mip6] RE: [nemo] Please review and provide inputtoDSMIP6-IKEv2discussion From: Basavaraj Patil To: ext Hesham Soliman , "'George Tsirtsis'" Message-ID: Thread-Topic: [Mip6] RE: [nemo] Please review and provide inputtoDSMIP6-IKEv2discussion Thread-Index: AcgmnQSpDHdPafkkQ1yQssKFTJSZ7AAC9YbwAAcTvI0= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Nov 2007 13:48:25.0256 (UTC) FILETIME=[0746EA80:01C826C5] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Cc: nemo@ietf.org, mip6@ietf.org, Levkowetz X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham, I am okay with Mobike being mentioned as an optional solution for MNs that have such capability and an HA supporting it as well in the I-D. However without providing more details on the behavior of the MN and HA w.r.t when Mobike is used, I think it would be less than useful. -Raj On 11/14/07 4:29 AM, "ext Hesham Soliman" wrote: > >> OK, lets not get stack on the definition of the word "optimal" :-) > > => ok :) > >> >> My proposal is to make "Solution 2" mandatory, since it is fully >> implementable using just IKEv2 and DSMIPv6 and "Solution Mobike" >> optional, since it results in better performance than >> "Solution 1" but >> requires MOBIKE support in HA and MN.. > > => It doesn't perform better than 1, it performs better than 2 if there is > no support for dynamic updates. I.e. if the IKE daemon on the HA doesn't > support dynamic updates solution 2 would need to re-run IKE to setup a new > SA. But if dynamic updates are supported then both perform the same way > AFAICS. > > I don't have a problem with mentioning Mobike as an option but several > people seem to be against it. Frankly, I don't know why it's so bad to > mention it as an option. > > Hesham > >> >> George >> >> On Nov 14, 2007 10:55 AM, Hesham Soliman >> wrote: >>> George, >>> >>> I don't know if this is an accurate categorisation but from my >>> understanding, this is what we have: >>> >>> Solution 1, which is suboptimal from an implementation >> point of view >>> Solution 2, which is suboptimal because of the reasons you >> mentioned below >>> and I mentioned earlier. >>> Solution Mobike, which is also suboptimal compared to 1 >> (in terms of >>> messages) but more optimal compared to solution 2, which >> essentially needs >>> IKE to re-establish the SA unless IKE dynamic updates are >> supported and we >>> hope they are! >>> >>> So yes Mobike is faster than 2 (assuming IKE dynamic >> updates are not used) I >>> think but not optimal. >>> >>> Hesham >>> >>> >>>> -----Original Message----- >>>> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >>>> Sent: Wednesday, November 14, 2007 6:42 PM >>>> To: Basavaraj Patil >>>> Cc: nemo@ietf.org; mip6@ietf.org; Levkowetz >>>> Subject: Re: [Mip6] RE: [nemo] Please review and provide >>>> inputtoDSMIP6-IKEv2discussion >>>> >>>> Hi Raj et.al.,, >>>> >>>> My understanding is that we already have two solutions >> (sub-optimal >>>> and optimal) that do not require changes to IKEv2 and/or MOBIKE. >>>> >>>> The "sub-optimal" solution is what Hesham called >> solution 2 in an >>>> earlier thread: i.e., >>>> "Karen suggested a way of running IKE without any >> changes (again see >>>> the thread for details). In this approach DSMIPv6 BUs are >>>> secured with >>>> ESP as usual. Normal traffic is sent over the DSMIPv6 >> port. However, >>>> secure traffic is sent over the IKE port (4500)." The >> sub-optimality >>>> comes from the fact that the solution causes additional delay to >>>> cyphered traffic. >>>> >>>> We also have an optimal solution which is the same as the >>>> above except >>>> that MOBIKE is also used so that the additional delay >> for cyphered >>>> traffic is removed. >>>> >>>> Why don't we document both. The first being mandatory and >>>> the second optional? >>>> >>>> Thanks >>>> George >>>> >>>> On Nov 14, 2007 6:51 AM, Basavaraj Patil >>>> wrote: >>>>> >>>>> Hi Vidya, >>>>> >>>>> The scope of the current discussion is of course limited >>>> to the usage of >>>>> IKEv2 in the presence of NATs when the MN moves to a >> v4 network. >>>>> >>>>> What you are suggesting is that the issue can be solved if >>>> the MN has Mobike >>>>> capability. This IMO makes it normative. >>>>> However I have no problems if this is mentioned as an >>>> option for hosts which >>>>> have Mobike capability. >>>>> A DS-MIP6 host however does not need Mobike capability. To >>>> solve the IKEv2 >>>>> issue, we need a solution that may be suboptimal (as you say). >>>>> >>>>> The few opinions that have been expressed indicate a >>>> preference for having >>>>> usage of Mobike in the context of MIP6 specified in a >>>> separate I-D. I have >>>>> not seen any support for using Mobike to solve the current >>>> problem even >>>>> though it has been acknowledged that it is "a" solution. >>>>> >>>>> Hence I would recommend that the WG focus on specifying a >>>> non-Mobike >>>>> solution to address the issue. >>>>> >>>>> -Raj >>>>> >>>>> >>>>> >>>>> On 11/13/07 5:52 PM, "ext Narayanan, Vidya" >>>> wrote: >>>>> >>>>>> I don't understand why an optional feature would >>>> introduce a normative >>>>>> dependency. Also, I'm not understanding the rationale >>>> behind keeping >>>>>> this out of the DSMIP6 spec - MOBIKE is a fully >>>> specified solution and >>>>>> all we need is a description of how it works with DSMIP6 >>>> (much like what >>>>>> we would write for regular IKEv2, probably even less), >>>> especially when >>>>>> that is technically the most optimal solution for >> this particular >>>>>> scenario being discussed. >>>>>> >>>>>> I'm not talking about replacing MIP6 mobility management >>>> with MOBIKE >>>>>> mobility management for all cases - I'm only talking >>>> about handling IPv4 >>>>>> tunnel mode NAT-T with MOBIKE. The two solutions >> that are being >>>>>> proposed for this case in the base spec are both >>>> sub-optimal and we have >>>>>> an optimal solution fully baked and available. I'm >>>> puzzled by the >>>>>> conclusion that is being reached at here. >>>>>> >>>>>> Vidya >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>>>>>> Sent: Tuesday, November 13, 2007 1:06 PM >>>>>>> To: Levkowetz; Vijay Devarapalli >>>>>>> Cc: nemo@ietf.org; mip6@ietf.org >>>>>>> Subject: Re: [Mip6] RE: [nemo] Please review and provide >>>>>>> input toDSMIP6-IKEv2discussion >>>>>>> >>>>>>> >>>>>>> I agree that the MIP6/DS-MIP6 protocol need not have a >>>>>>> normative dependency on Mobike. I agree that it is >> one way of >>>>>>> solving the issue but there are other solutions proposed as >>>>>>> well that do not rely on Mobike. >>>>>>> Requiring Mobike capability for MIP/DS-MIP6 is not >> essential. >>>>>>> >>>>>>> -Raj >>>>>>> >>>>>>> >>>>>>> On 11/12/07 12:55 PM, "ext Henrik Levkowetz" >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2007-11-12 19:43 Vijay Devarapalli said the following: >>>>>>>>> Narayanan, Vidya wrote: >>>>>>>> ... >>>>>>>>>> Ok, this discussion is tiring and unproductive and this >>>>>>> will be my >>>>>>>>>> last email on this topic. For the last time, I was >>>> NOT proposing >>>>>>>>>> MOBIKE to be the *only* mechanism for this scenario >>>> - all I was >>>>>>>>>> saying was that it doesn't involve tentative binding >>>>>>> cache entries >>>>>>>>>> or sequential roundtrips and hence, needs to be >> permitted >>>>>>> and documented as such as an *option*. >>>>>>>>> >>>>>>>>> Ok. But I am still objecting to specifying the use of >>>>>>> MOBIKE as one >>>>>>>>> of the solutions in the DS-MIPv6 document. There are >>>>>>> multiple reason. >>>>>>>>> It may require two round trips during the handover. And >>>>>>> You will have >>>>>>>>> two mobility management protocols running at the >> same time. >>>>>>>>> >>>>>>>>> I do agree with Hesham that we can't really prevent if >>>>>>> someone wants >>>>>>>>> to use MOBIKE at the same time. >>>>>>>>> >>>>>>>>> I suggest a separate document on this if you still want >>>>>>> MOBIKE to be >>>>>>>>> an alternative. >>>>>>>> >>>>>>>> I agree with Vijay's viewpoints above. >>>>>>>> >>>>>>>> >>>>>>>> Henrik >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Mip6 mailing list >>>>>>>> Mip6@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>> >>> >>> >>> >> > > From nemo-bounces@ietf.org Wed Nov 14 08:57:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsIkZ-000896-LG; Wed, 14 Nov 2007 08:57:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsIkX-00085r-1u; Wed, 14 Nov 2007 08:57:49 -0500 Received: from omta02ps.mx.bigpond.com ([144.140.83.154]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsIkU-0004q8-RL; Wed, 14 Nov 2007 08:57:48 -0500 Received: from oaamta06ps.mx.bigpond.com ([124.190.106.219]) by omta02ps.mx.bigpond.com with ESMTP id <20071114135743.YVPN19085.omta02ps.mx.bigpond.com@oaamta06ps.mx.bigpond.com>; Wed, 14 Nov 2007 13:57:43 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta06ps.mx.bigpond.com with ESMTP id <20071114135743.DUXN27263.oaamta06ps.mx.bigpond.com@PC20005>; Wed, 14 Nov 2007 13:57:43 +0000 From: "Hesham Soliman" To: "'Basavaraj Patil'" , "'George Tsirtsis'" Subject: RE: [Mip6] RE: [nemo] Please review and provide inputtoDSMIP6-IKEv2discussion Date: Thu, 15 Nov 2007 00:56:35 +1000 Message-ID: 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.3198 Thread-Index: AcgmnQSpDHdPafkkQ1yQssKFTJSZ7AAC9YbwAAcTvI0AAijEoA== In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb Cc: nemo@ietf.org, mip6@ietf.org, 'Levkowetz' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Ok, I think there is agreement on mentioning this without extensive documentation. I'll add it to the next rev. Hesham > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > Sent: Wednesday, November 14, 2007 11:49 PM > To: ext Hesham Soliman; 'George Tsirtsis' > Cc: nemo@ietf.org; mip6@ietf.org; Levkowetz > Subject: Re: [Mip6] RE: [nemo] Please review and provide > inputtoDSMIP6-IKEv2discussion > > > Hesham, > > I am okay with Mobike being mentioned as an optional > solution for MNs that > have such capability and an HA supporting it as well in the > I-D. However > without providing more details on the behavior of the MN and > HA w.r.t when > Mobike is used, I think it would be less than useful. > > -Raj > > > On 11/14/07 4:29 AM, "ext Hesham Soliman" > wrote: > > > > >> OK, lets not get stack on the definition of the word "optimal" :-) > > > > => ok :) > > > >> > >> My proposal is to make "Solution 2" mandatory, since it is fully > >> implementable using just IKEv2 and DSMIPv6 and "Solution Mobike" > >> optional, since it results in better performance than > >> "Solution 1" but > >> requires MOBIKE support in HA and MN.. > > > > => It doesn't perform better than 1, it performs better > than 2 if there is > > no support for dynamic updates. I.e. if the IKE daemon on > the HA doesn't > > support dynamic updates solution 2 would need to re-run > IKE to setup a new > > SA. But if dynamic updates are supported then both perform > the same way > > AFAICS. > > > > I don't have a problem with mentioning Mobike as an option > but several > > people seem to be against it. Frankly, I don't know why > it's so bad to > > mention it as an option. > > > > Hesham > > > >> > >> George > >> > >> On Nov 14, 2007 10:55 AM, Hesham Soliman > >> wrote: > >>> George, > >>> > >>> I don't know if this is an accurate categorisation but from my > >>> understanding, this is what we have: > >>> > >>> Solution 1, which is suboptimal from an implementation > >> point of view > >>> Solution 2, which is suboptimal because of the reasons you > >> mentioned below > >>> and I mentioned earlier. > >>> Solution Mobike, which is also suboptimal compared to 1 > >> (in terms of > >>> messages) but more optimal compared to solution 2, which > >> essentially needs > >>> IKE to re-establish the SA unless IKE dynamic updates are > >> supported and we > >>> hope they are! > >>> > >>> So yes Mobike is faster than 2 (assuming IKE dynamic > >> updates are not used) I > >>> think but not optimal. > >>> > >>> Hesham > >>> > >>> > >>>> -----Original Message----- > >>>> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > >>>> Sent: Wednesday, November 14, 2007 6:42 PM > >>>> To: Basavaraj Patil > >>>> Cc: nemo@ietf.org; mip6@ietf.org; Levkowetz > >>>> Subject: Re: [Mip6] RE: [nemo] Please review and provide > >>>> inputtoDSMIP6-IKEv2discussion > >>>> > >>>> Hi Raj et.al.,, > >>>> > >>>> My understanding is that we already have two solutions > >> (sub-optimal > >>>> and optimal) that do not require changes to IKEv2 and/or MOBIKE. > >>>> > >>>> The "sub-optimal" solution is what Hesham called > >> solution 2 in an > >>>> earlier thread: i.e., > >>>> "Karen suggested a way of running IKE without any > >> changes (again see > >>>> the thread for details). In this approach DSMIPv6 BUs are > >>>> secured with > >>>> ESP as usual. Normal traffic is sent over the DSMIPv6 > >> port. However, > >>>> secure traffic is sent over the IKE port (4500)." The > >> sub-optimality > >>>> comes from the fact that the solution causes additional delay to > >>>> cyphered traffic. > >>>> > >>>> We also have an optimal solution which is the same as the > >>>> above except > >>>> that MOBIKE is also used so that the additional delay > >> for cyphered > >>>> traffic is removed. > >>>> > >>>> Why don't we document both. The first being mandatory and > >>>> the second optional? > >>>> > >>>> Thanks > >>>> George > >>>> > >>>> On Nov 14, 2007 6:51 AM, Basavaraj Patil > >>>> wrote: > >>>>> > >>>>> Hi Vidya, > >>>>> > >>>>> The scope of the current discussion is of course limited > >>>> to the usage of > >>>>> IKEv2 in the presence of NATs when the MN moves to a > >> v4 network. > >>>>> > >>>>> What you are suggesting is that the issue can be solved if > >>>> the MN has Mobike > >>>>> capability. This IMO makes it normative. > >>>>> However I have no problems if this is mentioned as an > >>>> option for hosts which > >>>>> have Mobike capability. > >>>>> A DS-MIP6 host however does not need Mobike capability. To > >>>> solve the IKEv2 > >>>>> issue, we need a solution that may be suboptimal (as you say). > >>>>> > >>>>> The few opinions that have been expressed indicate a > >>>> preference for having > >>>>> usage of Mobike in the context of MIP6 specified in a > >>>> separate I-D. I have > >>>>> not seen any support for using Mobike to solve the current > >>>> problem even > >>>>> though it has been acknowledged that it is "a" solution. > >>>>> > >>>>> Hence I would recommend that the WG focus on specifying a > >>>> non-Mobike > >>>>> solution to address the issue. > >>>>> > >>>>> -Raj > >>>>> > >>>>> > >>>>> > >>>>> On 11/13/07 5:52 PM, "ext Narayanan, Vidya" > >>>> wrote: > >>>>> > >>>>>> I don't understand why an optional feature would > >>>> introduce a normative > >>>>>> dependency. Also, I'm not understanding the rationale > >>>> behind keeping > >>>>>> this out of the DSMIP6 spec - MOBIKE is a fully > >>>> specified solution and > >>>>>> all we need is a description of how it works with DSMIP6 > >>>> (much like what > >>>>>> we would write for regular IKEv2, probably even less), > >>>> especially when > >>>>>> that is technically the most optimal solution for > >> this particular > >>>>>> scenario being discussed. > >>>>>> > >>>>>> I'm not talking about replacing MIP6 mobility management > >>>> with MOBIKE > >>>>>> mobility management for all cases - I'm only talking > >>>> about handling IPv4 > >>>>>> tunnel mode NAT-T with MOBIKE. The two solutions > >> that are being > >>>>>> proposed for this case in the base spec are both > >>>> sub-optimal and we have > >>>>>> an optimal solution fully baked and available. I'm > >>>> puzzled by the > >>>>>> conclusion that is being reached at here. > >>>>>> > >>>>>> Vidya > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >>>>>>> Sent: Tuesday, November 13, 2007 1:06 PM > >>>>>>> To: Levkowetz; Vijay Devarapalli > >>>>>>> Cc: nemo@ietf.org; mip6@ietf.org > >>>>>>> Subject: Re: [Mip6] RE: [nemo] Please review and provide > >>>>>>> input toDSMIP6-IKEv2discussion > >>>>>>> > >>>>>>> > >>>>>>> I agree that the MIP6/DS-MIP6 protocol need not have a > >>>>>>> normative dependency on Mobike. I agree that it is > >> one way of > >>>>>>> solving the issue but there are other solutions proposed as > >>>>>>> well that do not rely on Mobike. > >>>>>>> Requiring Mobike capability for MIP/DS-MIP6 is not > >> essential. > >>>>>>> > >>>>>>> -Raj > >>>>>>> > >>>>>>> > >>>>>>> On 11/12/07 12:55 PM, "ext Henrik Levkowetz" > >>>>>>> wrote: > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On 2007-11-12 19:43 Vijay Devarapalli said the following: > >>>>>>>>> Narayanan, Vidya wrote: > >>>>>>>> ... > >>>>>>>>>> Ok, this discussion is tiring and unproductive and this > >>>>>>> will be my > >>>>>>>>>> last email on this topic. For the last time, I was > >>>> NOT proposing > >>>>>>>>>> MOBIKE to be the *only* mechanism for this scenario > >>>> - all I was > >>>>>>>>>> saying was that it doesn't involve tentative binding > >>>>>>> cache entries > >>>>>>>>>> or sequential roundtrips and hence, needs to be > >> permitted > >>>>>>> and documented as such as an *option*. > >>>>>>>>> > >>>>>>>>> Ok. But I am still objecting to specifying the use of > >>>>>>> MOBIKE as one > >>>>>>>>> of the solutions in the DS-MIPv6 document. There are > >>>>>>> multiple reason. > >>>>>>>>> It may require two round trips during the handover. And > >>>>>>> You will have > >>>>>>>>> two mobility management protocols running at the > >> same time. > >>>>>>>>> > >>>>>>>>> I do agree with Hesham that we can't really prevent if > >>>>>>> someone wants > >>>>>>>>> to use MOBIKE at the same time. > >>>>>>>>> > >>>>>>>>> I suggest a separate document on this if you still want > >>>>>>> MOBIKE to be > >>>>>>>>> an alternative. > >>>>>>>> > >>>>>>>> I agree with Vijay's viewpoints above. > >>>>>>>> > >>>>>>>> > >>>>>>>> Henrik > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Mip6 mailing list > >>>>>>>> Mip6@ietf.org > >>>>>>>> https://www1.ietf.org/mailman/listinfo/mip6 > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Mip6 mailing list > >>>> Mip6@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/mip6 > >>>> > >>> > >>> > >>> > >> > > > > > > From nemo-bounces@ietf.org Wed Nov 14 09:16: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 1IsJ2y-00073R-0p; Wed, 14 Nov 2007 09:16:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJ2w-00070i-0e; Wed, 14 Nov 2007 09:16:50 -0500 Received: from ws000774.tietoenator.com ([193.12.181.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsJ2u-0006fG-Ps; Wed, 14 Nov 2007 09:16:49 -0500 X-AuditID: c10cb581-0000131c00001b74-44-473b032720b0 Received: from stingray.eu.tieto.com ([192.176.143.13]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 15:16:07 +0100 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 15:16:08 +0100 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] Resolution of IKEv2 and DSMIPv6 issue Date: Wed, 14 Nov 2007 15:16:07 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Resolution of IKEv2 and DSMIPv6 issue Thread-Index: AcgmxnJqDYia2gpSRAKybifz8Eu5UwAAPl0g References: From: To: , , X-OriginalArrivalTime: 14 Nov 2007 14:16:08.0435 (UTC) FILETIME=[E69BE430:01C826C8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: Pasi.Eronen@nokia.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org HI, I think that there might be an un-important mistake here, namely the BU's are sent with dest option over the UPD-Ipv4 tunnel, Or ? Something else: I would have assumed that one could not assume that the pair v4CoA:dsmip port and v4CoA:port4500 is mapped to the same natted ip address (and just different ports). Doesn't the model need to accommodate that the NAT mapping of the v4CoA may be different depending on the=20 local port, i.e., so that in full generality, we need to operate with a v4port4500NAT_address and a v4dsmipPortNAT_address, not simply with one common NATTED_V4CoA - ? BR, Karen > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Wednesday, November 14, 2007 2:59 PM > To: mip6@ietf.org; nemo@ietf.org > Cc: Pasi.Eronen@nokia.com > Subject: [nemo] Resolution of IKEv2 and DSMIPv6 issue >=20 > Hi all,=20 >=20 > This is the last outstanding issue for DSMIPv6. In addition=20 > to this issue I > received comments on the draft, mainly editorial from George=20 > and Samita. > I'll respond to Samita's non-editorial questions separately.=20 > After analysing > all of the alternatives we clearly have no concensus for=20 > either alternative > so I asked the chairs and the security reviewers to make this=20 > decision for > us. Pasi did a lot of work to flush out solution 2 (thanks!) and I'm > including his analysis below with minor fixes. The conclusion of the > analysis was that solution 2 is preferred, mainly because it=20 > doesn't require > any of the changes to the implementation that solution 1=20 > required. So I > believe we should go with that and resolve this issue.=20 >=20 > Please find the complete steps for solution 2 below, with assumptions: >=20 > Solution 2 rephrased > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > (Pasi Eronen 2007-11-08) >=20 > NOTE 1: In this description, the DSMIPv6 tunnel has an=20 > "encapsulation" property with three different values: > - "UDP for all traffic" is obvious. > - "UDP for ESP-V6HoA-V6HA only" means that all ESP traffic=20 > between V6HoA and V6HA is UDP-encapsulated; all other traffic=20 > is straight IPv4/6-in-IPv4 (without UDP). > - "IPv4/6-in-IPv6" obvious. >=20 > NOTE 2: This example assumes that MOBIKE is not negotiated. >=20 > NOTE 3: RFC4877 allows the MN to use tunnel mode for BUs. > Here, transport mode MUST be used. >=20 > NOTE 4: This example assumes that UDP encapsulation (for DSMIPv6 > tunnel or ESP) is never used with IPv6 (also "forced UDP > encapsulation" can't be used). I.e. MUST NOT do UDP=20 > encapsulation when the > mobile node is=20 > in an IPv6-enabled network.=20 >=20 > Solution 2, IPv6 network -> IPv4 only network=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 1. The MN updates its DSMIPv6 tunnel as follows: > local address =3D V4CoA:DSMIPv6-port > remote address =3D V4HA:DSMIPv6-port > encapsulation =3D "UDP for all traffic" >=20 > 2. The MN updates its local binding/routing/something table to=20 > tunnel all traffic *from* V6HoA/V4HoA over the DSMIPv6 tunnel. >=20 > 3. The MN deletes all route optimization entries from its > binding cache. >=20 > 4. The MN updates its IKE_SA with the home agent as follows:=20 > local address =3D V4CoA:4500 > remote address =3D V4HA:4500 > NAT traversal =3D yes (pessimistic -- will be changed later) >=20 > 5. The MN updates its *tunnel* mode IPsec SAD entries with=20 > the home agent as follows: > local tunnel header address =3D V4CoA > remote tunnel header address =3D V4HA > UDP encapsulation =3D yes (pessimistic -- will be changed later) >=20 > 6. The MN may also need to update information in its SPD, so > that any new SAs get created with these tunnel header addresses. > (This depends a bit on how IKE determines the correct peer > when SA creation is needed.) > =20 > 7. The MN sends a Binding Update, which looks like this: >=20 > IPv4 header (src=3DV4CoA, dst=3DV4HA) > UDP header (src=3DDSMIPv6-PORT, dst=3DDSMIPv6-PORT) > IPv6 header (src=3DV6HoA, dst=3DV6HA) > Destination Options header > Home Address option (V6HoA) > ESP header (transport mode) > Mobility header > Binding Update > IPv4 Care-of Address option (V4CoA) >=20 > 8. The HA receives a Binding Update=20 >=20 > IPv4 header (src=3DNATTED_V4CoA, dst=3DV4HA) > UDP header (src=3DNATTED_DSMIPv6-PORT, dst=3DDSMIPv6-PORT) > IPv6 header (src=3DV6HoA, dst=3DV6HA) > Destination Options header > Home Address option (V6HoA) > ESP header (transport mode) > Mobility header > Binding Update > IPv4 Care-of Address option (V4CoA) >=20 > 9. The HA determines whether UDP encapsulation is used > (if the MN requested it, or local policy requires it, or > NATTED_V4CoA and V4CoA do not match). >=20 > 10. The HA updates its local DSMIPv6 tunnel: > local address =3D V4HA:DSMIPv6-PORT > remote address =3D NATTED_V4CoA:NATTED-DSMIPv6-PORT > encapsulation =3D "UDP for all traffic"/"UDP for ESP-V6HoA-V6HA = only" >=20 > 11. The HA updates its binding cache so that traffic to V6HoA=20 > and V4HoA > is sent over the DSMIPv6 tunnel. >=20 > 12. If the HA supports "K" flag, it updates its IKE_SA as follows: > local address =3D V4HA:4500 > remote address =3D NATTED_V4CoA:4500=20 > NAT traversal =3D yes/no > (NOTE: remote port number is wrong if doing NAT-T; this > will be updated below) >=20 > 13. The HA updates its *tunnel* mode IPsec SAD entries with MN: > local tunnel header address =3D V4HA:4500 > remote tunnel header address =3D NATTED_V4CoA:4500 > UDP encapsulation =3D yes/no > (NOTE: remote port number is wrong if doing NAT-T; this > will be updated below) >=20 > 14. The HA may also need to update information in its SPD=20 > (similarly as MN in step 6). >=20 > 15. HA replies with a Binding Acknowledgement. >=20 > IPv4 header (src=3DV4HA, dst=3DNATTED_V4CoA) > UDP header (src=3DDSMIPv6-PORT, dst=3DNATTED_DSMIPv6-PORT) > IPv6 header (src=3DV6HA, dst=3DV6HoA) > Routing header (type 2): V6HoA > ESP header (transport mode) > Mobility header > Binding Acknowledgement > [NAT detection option] >=20 > 16. MN updates the DSMIPv6 tunnel depending on the NAT=20 > detection option: > encapsulation =3D "UDP for all traffic"/"UDP for ESP-V6HoA-V6HA = only" >=20 > 17. The MN updates IKE/IPsec state as follows: >=20 > - "K" flag not set:=20 > - negotiate a new IKE_SA and new IPsec SAs replace all the=20 > existing IPsec SAs (both transport and tunnel mode),=20 > and close the old IKE_SA. >=20 > - "K" flag set, no NAT Detection option (and no MOBIKE):=20 > - update IKE_SA: NAT traversal =3D no > - update tunnel mode IPsec SAs: UDP encapsulation =3D no > =20 > - "K" flag set, NAT Detection option (and no MOBIKE): > - update IKE_SA: NAT traversal =3D yes > - update tunnel mode IPsec SAs: UDP encapsulation =3D no >=20 > 18. If the MN sent an empty Informational request, the HA will =20 > update its IKE_SA as follows: > remote_address =3D NATTED_V4CoA:NATTED_PORT_4500 > =20 > and tunnel mode IPsec SAD entries as follows: > remote_address =3D V4CoA:NATTED_PORT_4500 > =20 > 19. MN sends Binding Updates to delete bindings with all=20 > Correspondent Nodes that were using route optimization.=20 >=20 > 20. Done >=20 > The above steps would basically apply to a move from IPv4 to=20 > IPv4 as well. >=20 > Solution 2, IPv4 only network -> IPv6 network > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 1. The MN updates its DSMIPv6 tunnel as follows: > local address =3D V6CoA > remote address =3D V4HA > encapsulation =3D "straight IPv4/6-in-IPv6" >=20 > 2. The MN updates its local binding/routing/something table=20 > to tunnel all traffic *from* V6HoA/V4HoA over the DSMIPv6 tunnel > (note: "from" here means IP header source address, not including > e.g. Home Address option) >=20 > 3. The MN updates its IKE_SA with the home agent as follows:=20 > local address =3D V6CoA:4500 > remote address =3D V6HA:4500 > NAT traversal =3D no >=20 > 4. The MN updates its *tunnel* mode IPsec SAD entries with=20 > the home agent as follows: > local tunnel header address =3D V6CoA > remote tunnel header address =3D V6HA > UDP encapsulation =3D no >=20 > 5. The MN may also need to update information in its SPD, so > that any new SAs get created with these tunnel header addresses. > (This depends a bit on how IKE determines the correct peer > when SA creation is needed.) > =20 > 6. The MN sends a Binding Update, which looks like this: >=20 > IPv6 header (src=3DV6CoA, dst=3DV6HA) > Destination Options header > Home Address option (V6HoA) > ESP header (transport mode) > Mobility header > Binding Update > Alternate Care-of Address option (V6Coa) >=20 > 7. The HA updates its local DSMIPv6 tunnel: > local address =3D V6HA > remote address =3D V6CoA > encapsulation =3D "straight IPv4/6-in-IPv6" >=20 > 8. The HA updates its binding cache so that traffic to V6HoA=20 > and V4HoA is sent over the DSMIPv6 tunnel. >=20 > 9. If the HA supports "K" flag, it updates its IKE_SA as follows: > local address =3D V6HA:4500 > remote address =3D V6CoA:4500=20 > NAT traversal =3D no >=20 > 10. The HA updates its *tunnel* mode IPsec SAD entries with MN: > local tunnel header address =3D V6HA:4500 > remote tunnel header address =3D V6CoA:4500 > UDP encapsulation =3D no >=20 > 11. The HA may also need to update information in its SPD=20 > (similarly as MN in step 6). >=20 > 12. HA replies with a Binding Acknowledgement. >=20 > IPv6 header (src=3DV6HA, dst=3DV6CoA) > Routing header (type 2): V6HoA > ESP header (transport mode) > Mobility header > Binding Acknowledgement >=20 > 13. The MN updates IKE/IPsec state as follows: >=20 > - "K" flag not set:=20 > - negotiate a new IKE_SA and new IPsec SAs replace all the=20 > existing IPsec SAs (both transport and tunnel mode),=20 > and close the old IKE_SA. >=20 > - "K" flag set: > - nothing needs to be done >=20 > 14. MN could send Binding Updates to update bindings with > Corrrespondent Nodes for route optimization.=20 >=20 > 15. Done >=20 >=20 > Hesham >=20 >=20 >=20 >=20 From RollandhereuntoKnowles@interfax.ru Wed Nov 14 09:17:58 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJ42-0000pH-37; Wed, 14 Nov 2007 09:17:58 -0500 Received: from 209.68.220.87.dynamic.jazztel.es ([87.220.68.209] helo=portatil) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsJ3z-0006ly-QT; Wed, 14 Nov 2007 09:17:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host40264157.interfax.ru (8.13.1/8.13.1) with SMTP id PvzB9QlU39.115124.13k.eRH.6413700875520 for ; Wed, 14 Nov 2007 15:16:53 -0100 Message-ID: <3b9401c826c9$208db920$0201a8c0@portatil> From: "Robt Knowles" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_3B90_01C826C9.208DB920-- From nemo-bounces@ietf.org Wed Nov 14 09:19: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 1IsJ59-0002UV-Rm; Wed, 14 Nov 2007 09:19:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJ58-0002Sx-J2; Wed, 14 Nov 2007 09:19:06 -0500 Received: from ws000774.tietoenator.com ([193.12.181.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsJ55-0006t5-K3; Wed, 14 Nov 2007 09:19:06 -0500 X-AuditID: c10cb581-000024a400001b74-df-473b03c206c1 Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 15:18:42 +0100 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 15:18:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] RE: [nemo] Resolution of IKEv2 and DSMIPv6 issue Date: Wed, 14 Nov 2007 15:18:46 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: [nemo] Resolution of IKEv2 and DSMIPv6 issue Thread-Index: AcgmxnJqDYia2gpSRAKybifz8Eu5UwAAPl0gAABt1oA= References: From: To: , , , X-OriginalArrivalTime: 14 Nov 2007 14:18:48.0820 (UTC) FILETIME=[4634B340:01C826C9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926 Cc: Pasi.Eronen@nokia.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, =20 Sorry. I mean to say that RH and dest options are NOT USED over the UDP-IPv4 dsmip tunnel - right ? Karen=20 > -----Original Message----- > From: Karen.Nielsen@tietoenator.com=20 > [mailto:Karen.Nielsen@tietoenator.com]=20 > Sent: Wednesday, November 14, 2007 3:16 PM > To: Hesham@elevatemobile.com; mip6@ietf.org; nemo@ietf.org > Cc: Pasi.Eronen@nokia.com > Subject: [Mip6] RE: [nemo] Resolution of IKEv2 and DSMIPv6 issue >=20 > HI, >=20 > I think that there might be an un-important mistake here, namely the > BU's are sent with dest option > over the UPD-Ipv4 tunnel, Or ? >=20 > Something else: I would have assumed that one could not=20 > assume that the > pair > v4CoA:dsmip port and v4CoA:port4500 is mapped to the same natted ip > address (and just different ports). > Doesn't the model need to accommodate that the NAT mapping of=20 > the v4CoA > may be different depending on the=20 > local port, i.e., so that in full generality, we need to=20 > operate with a > v4port4500NAT_address and a v4dsmipPortNAT_address, not simply > with one common NATTED_V4CoA - ? >=20 > BR, Karen >=20 > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > > Sent: Wednesday, November 14, 2007 2:59 PM > > To: mip6@ietf.org; nemo@ietf.org > > Cc: Pasi.Eronen@nokia.com > > Subject: [nemo] Resolution of IKEv2 and DSMIPv6 issue > >=20 > > Hi all,=20 > >=20 > > This is the last outstanding issue for DSMIPv6. In addition=20 > > to this issue I > > received comments on the draft, mainly editorial from George=20 > > and Samita. > > I'll respond to Samita's non-editorial questions separately.=20 > > After analysing > > all of the alternatives we clearly have no concensus for=20 > > either alternative > > so I asked the chairs and the security reviewers to make this=20 > > decision for > > us. Pasi did a lot of work to flush out solution 2 (thanks!) and I'm > > including his analysis below with minor fixes. The conclusion of the > > analysis was that solution 2 is preferred, mainly because it=20 > > doesn't require > > any of the changes to the implementation that solution 1=20 > > required. So I > > believe we should go with that and resolve this issue.=20 > >=20 > > Please find the complete steps for solution 2 below, with=20 > assumptions: > >=20 > > Solution 2 rephrased > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > (Pasi Eronen 2007-11-08) > >=20 > > NOTE 1: In this description, the DSMIPv6 tunnel has an=20 > > "encapsulation" property with three different values: > > - "UDP for all traffic" is obvious. > > - "UDP for ESP-V6HoA-V6HA only" means that all ESP traffic=20 > > between V6HoA and V6HA is UDP-encapsulated; all other traffic=20 > > is straight IPv4/6-in-IPv4 (without UDP). > > - "IPv4/6-in-IPv6" obvious. > >=20 > > NOTE 2: This example assumes that MOBIKE is not negotiated. > >=20 > > NOTE 3: RFC4877 allows the MN to use tunnel mode for BUs. > > Here, transport mode MUST be used. > >=20 > > NOTE 4: This example assumes that UDP encapsulation (for DSMIPv6 > > tunnel or ESP) is never used with IPv6 (also "forced UDP > > encapsulation" can't be used). I.e. MUST NOT do UDP=20 > > encapsulation when the > > mobile node is=20 > > in an IPv6-enabled network.=20 > >=20 > > Solution 2, IPv6 network -> IPv4 only network=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > 1. The MN updates its DSMIPv6 tunnel as follows: > > local address =3D V4CoA:DSMIPv6-port > > remote address =3D V4HA:DSMIPv6-port > > encapsulation =3D "UDP for all traffic" > >=20 > > 2. The MN updates its local binding/routing/something table to=20 > > tunnel all traffic *from* V6HoA/V4HoA over the DSMIPv6 tunnel. > >=20 > > 3. The MN deletes all route optimization entries from its > > binding cache. > >=20 > > 4. The MN updates its IKE_SA with the home agent as follows:=20 > > local address =3D V4CoA:4500 > > remote address =3D V4HA:4500 > > NAT traversal =3D yes (pessimistic -- will be changed later) > >=20 > > 5. The MN updates its *tunnel* mode IPsec SAD entries with=20 > > the home agent as follows: > > local tunnel header address =3D V4CoA > > remote tunnel header address =3D V4HA > > UDP encapsulation =3D yes (pessimistic -- will be changed later) > >=20 > > 6. The MN may also need to update information in its SPD, so > > that any new SAs get created with these tunnel header addresses. > > (This depends a bit on how IKE determines the correct peer > > when SA creation is needed.) > > =20 > > 7. The MN sends a Binding Update, which looks like this: > >=20 > > IPv4 header (src=3DV4CoA, dst=3DV4HA) > > UDP header (src=3DDSMIPv6-PORT, dst=3DDSMIPv6-PORT) > > IPv6 header (src=3DV6HoA, dst=3DV6HA) > > Destination Options header > > Home Address option (V6HoA) > > ESP header (transport mode) > > Mobility header > > Binding Update > > IPv4 Care-of Address option (V4CoA) > >=20 > > 8. The HA receives a Binding Update=20 > >=20 > > IPv4 header (src=3DNATTED_V4CoA, dst=3DV4HA) > > UDP header (src=3DNATTED_DSMIPv6-PORT, dst=3DDSMIPv6-PORT) > > IPv6 header (src=3DV6HoA, dst=3DV6HA) > > Destination Options header > > Home Address option (V6HoA) > > ESP header (transport mode) > > Mobility header > > Binding Update > > IPv4 Care-of Address option (V4CoA) > >=20 > > 9. The HA determines whether UDP encapsulation is used > > (if the MN requested it, or local policy requires it, or > > NATTED_V4CoA and V4CoA do not match). > >=20 > > 10. The HA updates its local DSMIPv6 tunnel: > > local address =3D V4HA:DSMIPv6-PORT > > remote address =3D NATTED_V4CoA:NATTED-DSMIPv6-PORT > > encapsulation =3D "UDP for all traffic"/"UDP for=20 > ESP-V6HoA-V6HA only" > >=20 > > 11. The HA updates its binding cache so that traffic to V6HoA=20 > > and V4HoA > > is sent over the DSMIPv6 tunnel. > >=20 > > 12. If the HA supports "K" flag, it updates its IKE_SA as follows: > > local address =3D V4HA:4500 > > remote address =3D NATTED_V4CoA:4500=20 > > NAT traversal =3D yes/no > > (NOTE: remote port number is wrong if doing NAT-T; this > > will be updated below) > >=20 > > 13. The HA updates its *tunnel* mode IPsec SAD entries with MN: > > local tunnel header address =3D V4HA:4500 > > remote tunnel header address =3D NATTED_V4CoA:4500 > > UDP encapsulation =3D yes/no > > (NOTE: remote port number is wrong if doing NAT-T; this > > will be updated below) > >=20 > > 14. The HA may also need to update information in its SPD=20 > > (similarly as MN in step 6). > >=20 > > 15. HA replies with a Binding Acknowledgement. > >=20 > > IPv4 header (src=3DV4HA, dst=3DNATTED_V4CoA) > > UDP header (src=3DDSMIPv6-PORT, dst=3DNATTED_DSMIPv6-PORT) > > IPv6 header (src=3DV6HA, dst=3DV6HoA) > > Routing header (type 2): V6HoA > > ESP header (transport mode) > > Mobility header > > Binding Acknowledgement > > [NAT detection option] > >=20 > > 16. MN updates the DSMIPv6 tunnel depending on the NAT=20 > > detection option: > > encapsulation =3D "UDP for all traffic"/"UDP for=20 > ESP-V6HoA-V6HA only" > >=20 > > 17. The MN updates IKE/IPsec state as follows: > >=20 > > - "K" flag not set:=20 > > - negotiate a new IKE_SA and new IPsec SAs replace all the=20 > > existing IPsec SAs (both transport and tunnel mode),=20 > > and close the old IKE_SA. > >=20 > > - "K" flag set, no NAT Detection option (and no MOBIKE):=20 > > - update IKE_SA: NAT traversal =3D no > > - update tunnel mode IPsec SAs: UDP encapsulation =3D no > > =20 > > - "K" flag set, NAT Detection option (and no MOBIKE): > > - update IKE_SA: NAT traversal =3D yes > > - update tunnel mode IPsec SAs: UDP encapsulation =3D no > >=20 > > 18. If the MN sent an empty Informational request, the HA will =20 > > update its IKE_SA as follows: > > remote_address =3D NATTED_V4CoA:NATTED_PORT_4500 > > =20 > > and tunnel mode IPsec SAD entries as follows: > > remote_address =3D V4CoA:NATTED_PORT_4500 > > =20 > > 19. MN sends Binding Updates to delete bindings with all=20 > > Correspondent Nodes that were using route optimization.=20 > >=20 > > 20. Done > >=20 > > The above steps would basically apply to a move from IPv4 to=20 > > IPv4 as well. > >=20 > > Solution 2, IPv4 only network -> IPv6 network > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > 1. The MN updates its DSMIPv6 tunnel as follows: > > local address =3D V6CoA > > remote address =3D V4HA > > encapsulation =3D "straight IPv4/6-in-IPv6" > >=20 > > 2. The MN updates its local binding/routing/something table=20 > > to tunnel all traffic *from* V6HoA/V4HoA over the DSMIPv6 tunnel > > (note: "from" here means IP header source address, not including > > e.g. Home Address option) > >=20 > > 3. The MN updates its IKE_SA with the home agent as follows:=20 > > local address =3D V6CoA:4500 > > remote address =3D V6HA:4500 > > NAT traversal =3D no > >=20 > > 4. The MN updates its *tunnel* mode IPsec SAD entries with=20 > > the home agent as follows: > > local tunnel header address =3D V6CoA > > remote tunnel header address =3D V6HA > > UDP encapsulation =3D no > >=20 > > 5. The MN may also need to update information in its SPD, so > > that any new SAs get created with these tunnel header addresses. > > (This depends a bit on how IKE determines the correct peer > > when SA creation is needed.) > > =20 > > 6. The MN sends a Binding Update, which looks like this: > >=20 > > IPv6 header (src=3DV6CoA, dst=3DV6HA) > > Destination Options header > > Home Address option (V6HoA) > > ESP header (transport mode) > > Mobility header > > Binding Update > > Alternate Care-of Address option (V6Coa) > >=20 > > 7. The HA updates its local DSMIPv6 tunnel: > > local address =3D V6HA > > remote address =3D V6CoA > > encapsulation =3D "straight IPv4/6-in-IPv6" > >=20 > > 8. The HA updates its binding cache so that traffic to V6HoA=20 > > and V4HoA is sent over the DSMIPv6 tunnel. > >=20 > > 9. If the HA supports "K" flag, it updates its IKE_SA as follows: > > local address =3D V6HA:4500 > > remote address =3D V6CoA:4500=20 > > NAT traversal =3D no > >=20 > > 10. The HA updates its *tunnel* mode IPsec SAD entries with MN: > > local tunnel header address =3D V6HA:4500 > > remote tunnel header address =3D V6CoA:4500 > > UDP encapsulation =3D no > >=20 > > 11. The HA may also need to update information in its SPD=20 > > (similarly as MN in step 6). > >=20 > > 12. HA replies with a Binding Acknowledgement. > >=20 > > IPv6 header (src=3DV6HA, dst=3DV6CoA) > > Routing header (type 2): V6HoA > > ESP header (transport mode) > > Mobility header > > Binding Acknowledgement > >=20 > > 13. The MN updates IKE/IPsec state as follows: > >=20 > > - "K" flag not set:=20 > > - negotiate a new IKE_SA and new IPsec SAs replace all the=20 > > existing IPsec SAs (both transport and tunnel mode),=20 > > and close the old IKE_SA. > >=20 > > - "K" flag set: > > - nothing needs to be done > >=20 > > 14. MN could send Binding Updates to update bindings with > > Corrrespondent Nodes for route optimization.=20 > >=20 > > 15. Done > >=20 > >=20 > > Hesham > >=20 > >=20 > >=20 > >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 From nemo-bounces@ietf.org Wed Nov 14 09:19: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 1IsJ5G-0002jv-0S; Wed, 14 Nov 2007 09:19:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJ5E-0002eU-DD for nemo@ietf.org; Wed, 14 Nov 2007 09:19:12 -0500 Received: from rv-out-0910.google.com ([209.85.198.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsJ5C-0006tm-Nh for nemo@ietf.org; Wed, 14 Nov 2007 09:19:12 -0500 Received: by rv-out-0910.google.com with SMTP id l15so157646rvb for ; Wed, 14 Nov 2007 06:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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; bh=gDMEUwY9KmI4yIMNe1klrpTYtKr8LO5WzpA5SKlOIIo=; b=TSC5lsIIUfDYDsgbxHpFyHhH8sC+/khAi/rmoZDmlYmrwOHK/5uaCPiI0dBRgGFPzyzEkRRirgMITkn4yR3YQErYWI/VjJ37+piP9hX+A/U1U770b8qIKKvltZAgDQZYOfjx2EuVMjb2upjBd1TJg1q1DBELtUwq/4xiXaXsjYo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.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=uuvruxiMeFbUPsSsVfP12mLuNKLET7Dn+4dIQkpzRNDeF15dIT9Rcx4NCyuFUiPoDjfPL7tllv8BZeyGMGbTY/1O1/rLnXkvmRYpwKC6mtfN57v5SpjJOoJBIbGeFiss8cUju190mBiK1FqX4FmDReKK0kzZZ5lRuaN6E0uaqYc= Received: by 10.141.33.21 with SMTP id l21mr346120rvj.1195049949548; Wed, 14 Nov 2007 06:19:09 -0800 (PST) Received: by 10.141.177.11 with HTTP; Wed, 14 Nov 2007 06:19:09 -0800 (PST) Message-ID: Date: Wed, 14 Nov 2007 15:19:09 +0100 From: "George Tsirtsis" To: "Hesham Soliman" Subject: Re: [Mip6] RE: [nemo] Please review and provide inputtoDSMIP6-IKEv2discussion In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Cc: nemo@ietf.org, mip6@ietf.org, Levkowetz , Basavaraj Patil X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I am now a bit concerned with what it means to "mention MOBIKE without extensive documentation". I think the documentation should be enough to allow the implementor to understand how MOBIKE can be used as an alternative to Solution 2. Since no change to MOBIKE is required for this, however, I expect the description to be relatively brief and easy. In any case I trust Hesham to apply common sense in this case :-) Regards George On Nov 14, 2007 3:56 PM, Hesham Soliman wrote: > Ok, I think there is agreement on mentioning this without extensive > documentation. > I'll add it to the next rev. > > Hesham > > > -----Original Message----- > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > Sent: Wednesday, November 14, 2007 11:49 PM > > To: ext Hesham Soliman; 'George Tsirtsis' > > Cc: nemo@ietf.org; mip6@ietf.org; Levkowetz > > Subject: Re: [Mip6] RE: [nemo] Please review and provide > > inputtoDSMIP6-IKEv2discussion > > > > > > Hesham, > > > > I am okay with Mobike being mentioned as an optional > > solution for MNs that > > have such capability and an HA supporting it as well in the > > I-D. However > > without providing more details on the behavior of the MN and > > HA w.r.t when > > Mobike is used, I think it would be less than useful. > > > > -Raj > > > > > > On 11/14/07 4:29 AM, "ext Hesham Soliman" > > wrote: > > > > > > > >> OK, lets not get stack on the definition of the word "optimal" :-) > > > > > > => ok :) > > > > > >> > > >> My proposal is to make "Solution 2" mandatory, since it is fully > > >> implementable using just IKEv2 and DSMIPv6 and "Solution Mobike" > > >> optional, since it results in better performance than > > >> "Solution 1" but > > >> requires MOBIKE support in HA and MN.. > > > > > > => It doesn't perform better than 1, it performs better > > than 2 if there is > > > no support for dynamic updates. I.e. if the IKE daemon on > > the HA doesn't > > > support dynamic updates solution 2 would need to re-run > > IKE to setup a new > > > SA. But if dynamic updates are supported then both perform > > the same way > > > AFAICS. > > > > > > I don't have a problem with mentioning Mobike as an option > > but several > > > people seem to be against it. Frankly, I don't know why > > it's so bad to > > > mention it as an option. > > > > > > Hesham > > > > > >> > > >> George > > >> > > >> On Nov 14, 2007 10:55 AM, Hesham Soliman > > >> wrote: > > >>> George, > > >>> > > >>> I don't know if this is an accurate categorisation but from my > > >>> understanding, this is what we have: > > >>> > > >>> Solution 1, which is suboptimal from an implementation > > >> point of view > > >>> Solution 2, which is suboptimal because of the reasons you > > >> mentioned below > > >>> and I mentioned earlier. > > >>> Solution Mobike, which is also suboptimal compared to 1 > > >> (in terms of > > >>> messages) but more optimal compared to solution 2, which > > >> essentially needs > > >>> IKE to re-establish the SA unless IKE dynamic updates are > > >> supported and we > > >>> hope they are! > > >>> > > >>> So yes Mobike is faster than 2 (assuming IKE dynamic > > >> updates are not used) I > > >>> think but not optimal. > > >>> > > >>> Hesham > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > > >>>> Sent: Wednesday, November 14, 2007 6:42 PM > > >>>> To: Basavaraj Patil > > >>>> Cc: nemo@ietf.org; mip6@ietf.org; Levkowetz > > >>>> Subject: Re: [Mip6] RE: [nemo] Please review and provide > > >>>> inputtoDSMIP6-IKEv2discussion > > >>>> > > >>>> Hi Raj et.al.,, > > >>>> > > >>>> My understanding is that we already have two solutions > > >> (sub-optimal > > >>>> and optimal) that do not require changes to IKEv2 and/or MOBIKE. > > >>>> > > >>>> The "sub-optimal" solution is what Hesham called > > >> solution 2 in an > > >>>> earlier thread: i.e., > > >>>> "Karen suggested a way of running IKE without any > > >> changes (again see > > >>>> the thread for details). In this approach DSMIPv6 BUs are > > >>>> secured with > > >>>> ESP as usual. Normal traffic is sent over the DSMIPv6 > > >> port. However, > > >>>> secure traffic is sent over the IKE port (4500)." The > > >> sub-optimality > > >>>> comes from the fact that the solution causes additional delay to > > >>>> cyphered traffic. > > >>>> > > >>>> We also have an optimal solution which is the same as the > > >>>> above except > > >>>> that MOBIKE is also used so that the additional delay > > >> for cyphered > > >>>> traffic is removed. > > >>>> > > >>>> Why don't we document both. The first being mandatory and > > >>>> the second optional? > > >>>> > > >>>> Thanks > > >>>> George > > >>>> > > >>>> On Nov 14, 2007 6:51 AM, Basavaraj Patil > > >>>> wrote: > > >>>>> > > >>>>> Hi Vidya, > > >>>>> > > >>>>> The scope of the current discussion is of course limited > > >>>> to the usage of > > >>>>> IKEv2 in the presence of NATs when the MN moves to a > > >> v4 network. > > >>>>> > > >>>>> What you are suggesting is that the issue can be solved if > > >>>> the MN has Mobike > > >>>>> capability. This IMO makes it normative. > > >>>>> However I have no problems if this is mentioned as an > > >>>> option for hosts which > > >>>>> have Mobike capability. > > >>>>> A DS-MIP6 host however does not need Mobike capability. To > > >>>> solve the IKEv2 > > >>>>> issue, we need a solution that may be suboptimal (as you say). > > >>>>> > > >>>>> The few opinions that have been expressed indicate a > > >>>> preference for having > > >>>>> usage of Mobike in the context of MIP6 specified in a > > >>>> separate I-D. I have > > >>>>> not seen any support for using Mobike to solve the current > > >>>> problem even > > >>>>> though it has been acknowledged that it is "a" solution. > > >>>>> > > >>>>> Hence I would recommend that the WG focus on specifying a > > >>>> non-Mobike > > >>>>> solution to address the issue. > > >>>>> > > >>>>> -Raj > > >>>>> > > >>>>> > > >>>>> > > >>>>> On 11/13/07 5:52 PM, "ext Narayanan, Vidya" > > >>>> wrote: > > >>>>> > > >>>>>> I don't understand why an optional feature would > > >>>> introduce a normative > > >>>>>> dependency. Also, I'm not understanding the rationale > > >>>> behind keeping > > >>>>>> this out of the DSMIP6 spec - MOBIKE is a fully > > >>>> specified solution and > > >>>>>> all we need is a description of how it works with DSMIP6 > > >>>> (much like what > > >>>>>> we would write for regular IKEv2, probably even less), > > >>>> especially when > > >>>>>> that is technically the most optimal solution for > > >> this particular > > >>>>>> scenario being discussed. > > >>>>>> > > >>>>>> I'm not talking about replacing MIP6 mobility management > > >>>> with MOBIKE > > >>>>>> mobility management for all cases - I'm only talking > > >>>> about handling IPv4 > > >>>>>> tunnel mode NAT-T with MOBIKE. The two solutions > > >> that are being > > >>>>>> proposed for this case in the base spec are both > > >>>> sub-optimal and we have > > >>>>>> an optimal solution fully baked and available. I'm > > >>>> puzzled by the > > >>>>>> conclusion that is being reached at here. > > >>>>>> > > >>>>>> Vidya > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > >>>>>>> Sent: Tuesday, November 13, 2007 1:06 PM > > >>>>>>> To: Levkowetz; Vijay Devarapalli > > >>>>>>> Cc: nemo@ietf.org; mip6@ietf.org > > >>>>>>> Subject: Re: [Mip6] RE: [nemo] Please review and provide > > >>>>>>> input toDSMIP6-IKEv2discussion > > >>>>>>> > > >>>>>>> > > >>>>>>> I agree that the MIP6/DS-MIP6 protocol need not have a > > >>>>>>> normative dependency on Mobike. I agree that it is > > >> one way of > > >>>>>>> solving the issue but there are other solutions proposed as > > >>>>>>> well that do not rely on Mobike. > > >>>>>>> Requiring Mobike capability for MIP/DS-MIP6 is not > > >> essential. > > >>>>>>> > > >>>>>>> -Raj > > >>>>>>> > > >>>>>>> > > >>>>>>> On 11/12/07 12:55 PM, "ext Henrik Levkowetz" > > >>>>>>> wrote: > > >>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On 2007-11-12 19:43 Vijay Devarapalli said the following: > > >>>>>>>>> Narayanan, Vidya wrote: > > >>>>>>>> ... > > >>>>>>>>>> Ok, this discussion is tiring and unproductive and this > > >>>>>>> will be my > > >>>>>>>>>> last email on this topic. For the last time, I was > > >>>> NOT proposing > > >>>>>>>>>> MOBIKE to be the *only* mechanism for this scenario > > >>>> - all I was > > >>>>>>>>>> saying was that it doesn't involve tentative binding > > >>>>>>> cache entries > > >>>>>>>>>> or sequential roundtrips and hence, needs to be > > >> permitted > > >>>>>>> and documented as such as an *option*. > > >>>>>>>>> > > >>>>>>>>> Ok. But I am still objecting to specifying the use of > > >>>>>>> MOBIKE as one > > >>>>>>>>> of the solutions in the DS-MIPv6 document. There are > > >>>>>>> multiple reason. > > >>>>>>>>> It may require two round trips during the handover. And > > >>>>>>> You will have > > >>>>>>>>> two mobility management protocols running at the > > >> same time. > > >>>>>>>>> > > >>>>>>>>> I do agree with Hesham that we can't really prevent if > > >>>>>>> someone wants > > >>>>>>>>> to use MOBIKE at the same time. > > >>>>>>>>> > > >>>>>>>>> I suggest a separate document on this if you still want > > >>>>>>> MOBIKE to be > > >>>>>>>>> an alternative. > > >>>>>>>> > > >>>>>>>> I agree with Vijay's viewpoints above. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> Henrik > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> _______________________________________________ > > >>>>>>>> Mip6 mailing list > > >>>>>>>> Mip6@ietf.org > > >>>>>>>> https://www1.ietf.org/mailman/listinfo/mip6 > > >>>>>>> > > >>>>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Mip6 mailing list > > >>>> Mip6@ietf.org > > >>>> https://www1.ietf.org/mailman/listinfo/mip6 > > >>>> > > >>> > > >>> > > >>> > > >> > > > > > > > > > > > > > From SylviasidesaddleAndrade@harpers.org Wed Nov 14 10:22:20 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsK4K-00007D-Bk; Wed, 14 Nov 2007 10:22:20 -0500 Received: from [200.121.1.44] (helo=administrador) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsK4J-0005Xt-RS; Wed, 14 Nov 2007 10:22:20 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host19094420.harpers.org (8.13.1/8.13.1) with SMTP id zrnNkVmY18.667402.5LO.Ddm.2987878700593 for ; Wed, 14 Nov 2007 10:21:49 +0500 Message-ID: <432001c826d2$2477ae70$2201a8c0@administrador> From: "Edith Lyon" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_431C_01C826D2.2477AE70-- From Turgeonkzcdd@american-greencards.com Wed Nov 14 10:55:08 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKa4-0004Yi-EU for nemo-archive@lists.ietf.org; Wed, 14 Nov 2007 10:55:08 -0500 Received: from cjy76.neoplus.adsl.tpnet.pl ([83.31.74.76]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsKa3-00019S-U0 for nemo-archive@lists.ietf.org; Wed, 14 Nov 2007 10:55:08 -0500 Received: by 10.132.45.23 with SMTP id gOlUZFSdpZBKU; Wed, 14 Nov 2007 16:56:20 +0100 (GMT) Received: by 192.168.175.111 with SMTP id OgfOrTCNvshEXL.2420756732902; Wed, 14 Nov 2007 16:56:18 +0100 (GMT) Message-ID: <000e01c826d6$e2ebf330$4c4a1f53@budcfc299624f4> From: "samson Turgeon" To: Subject: ucayupma Date: Wed, 14 Nov 2007 16:56:15 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C826DF.44B05B30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.8 (++++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0008_01C826DF.44B05B30 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable put yourself into a class of your own with a larger penis Bifeng Backus http://agacoltd.com/ ------=_NextPart_000_0008_01C826DF.44B05B30 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
put yourself into a class of your own with a = larger penis
Bifeng Backus
http://agacoltd.com/
------=_NextPart_000_0008_01C826DF.44B05B30-- From nemo-bounces@ietf.org Wed Nov 14 12:53: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 1IsMQy-0007kN-75; Wed, 14 Nov 2007 12:53:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsMQw-0007jS-8I; Wed, 14 Nov 2007 12:53:50 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsMQv-00078B-AG; Wed, 14 Nov 2007 12:53:49 -0500 Received: from [127.0.0.1] ([131.107.204.126]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Nov 2007 09:53:47 -0800 Message-ID: <473B362A.3060505@azairenet.com> Date: Wed, 14 Nov 2007 09:53:46 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: George Tsirtsis Subject: Re: [Mip6] RE: [nemo] Please review and provide input toDSMIP6-IKEv2discussion References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2007 17:53:48.0035 (UTC) FILETIME=[4EBCB530:01C826E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: nemo@ietf.org, mip6@ietf.org, Levkowetz , Basavaraj Patil X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org George Tsirtsis wrote: > Hi Raj et.al.,, > > My understanding is that we already have two solutions (sub-optimal > and optimal) that do not require changes to IKEv2 and/or MOBIKE. > > The "sub-optimal" solution is what Hesham called solution 2 in an > earlier thread: i.e., > "Karen suggested a way of running IKE without any changes (again see > the thread for details). In this approach DSMIPv6 BUs are secured with > ESP as usual. Normal traffic is sent over the DSMIPv6 port. However, > secure traffic is sent over the IKE port (4500)." The sub-optimality > comes from the fact that the solution causes additional delay to > cyphered traffic. We can avoid the delay for cyphered traffic. See http://www1.ietf.org/mail-archive/web/mip6/current/msg06910.html and follow the thread. Vijay > > We also have an optimal solution which is the same as the above except > that MOBIKE is also used so that the additional delay for cyphered > traffic is removed. > > Why don't we document both. The first being mandatory and the second optional? > > Thanks > George > > On Nov 14, 2007 6:51 AM, Basavaraj Patil wrote: >> Hi Vidya, >> >> The scope of the current discussion is of course limited to the usage of >> IKEv2 in the presence of NATs when the MN moves to a v4 network. >> >> What you are suggesting is that the issue can be solved if the MN has Mobike >> capability. This IMO makes it normative. >> However I have no problems if this is mentioned as an option for hosts which >> have Mobike capability. >> A DS-MIP6 host however does not need Mobike capability. To solve the IKEv2 >> issue, we need a solution that may be suboptimal (as you say). >> >> The few opinions that have been expressed indicate a preference for having >> usage of Mobike in the context of MIP6 specified in a separate I-D. I have >> not seen any support for using Mobike to solve the current problem even >> though it has been acknowledged that it is "a" solution. >> >> Hence I would recommend that the WG focus on specifying a non-Mobike >> solution to address the issue. >> >> -Raj >> >> >> >> On 11/13/07 5:52 PM, "ext Narayanan, Vidya" wrote: >> >>> I don't understand why an optional feature would introduce a normative >>> dependency. Also, I'm not understanding the rationale behind keeping >>> this out of the DSMIP6 spec - MOBIKE is a fully specified solution and >>> all we need is a description of how it works with DSMIP6 (much like what >>> we would write for regular IKEv2, probably even less), especially when >>> that is technically the most optimal solution for this particular >>> scenario being discussed. >>> >>> I'm not talking about replacing MIP6 mobility management with MOBIKE >>> mobility management for all cases - I'm only talking about handling IPv4 >>> tunnel mode NAT-T with MOBIKE. The two solutions that are being >>> proposed for this case in the base spec are both sub-optimal and we have >>> an optimal solution fully baked and available. I'm puzzled by the >>> conclusion that is being reached at here. >>> >>> Vidya >>> >>>> -----Original Message----- >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>>> Sent: Tuesday, November 13, 2007 1:06 PM >>>> To: Levkowetz; Vijay Devarapalli >>>> Cc: nemo@ietf.org; mip6@ietf.org >>>> Subject: Re: [Mip6] RE: [nemo] Please review and provide >>>> input toDSMIP6-IKEv2discussion >>>> >>>> >>>> I agree that the MIP6/DS-MIP6 protocol need not have a >>>> normative dependency on Mobike. I agree that it is one way of >>>> solving the issue but there are other solutions proposed as >>>> well that do not rely on Mobike. >>>> Requiring Mobike capability for MIP/DS-MIP6 is not essential. >>>> >>>> -Raj >>>> >>>> >>>> On 11/12/07 12:55 PM, "ext Henrik Levkowetz" >>>> wrote: >>>> >>>>> >>>>> On 2007-11-12 19:43 Vijay Devarapalli said the following: >>>>>> Narayanan, Vidya wrote: >>>>> ... >>>>>>> Ok, this discussion is tiring and unproductive and this >>>> will be my >>>>>>> last email on this topic. For the last time, I was NOT proposing >>>>>>> MOBIKE to be the *only* mechanism for this scenario - all I was >>>>>>> saying was that it doesn't involve tentative binding >>>> cache entries >>>>>>> or sequential roundtrips and hence, needs to be permitted >>>> and documented as such as an *option*. >>>>>> Ok. But I am still objecting to specifying the use of >>>> MOBIKE as one >>>>>> of the solutions in the DS-MIPv6 document. There are >>>> multiple reason. >>>>>> It may require two round trips during the handover. And >>>> You will have >>>>>> two mobility management protocols running at the same time. >>>>>> >>>>>> I do agree with Hesham that we can't really prevent if >>>> someone wants >>>>>> to use MOBIKE at the same time. >>>>>> >>>>>> I suggest a separate document on this if you still want >>>> MOBIKE to be >>>>>> an alternative. >>>>> I agree with Vijay's viewpoints above. >>>>> >>>>> >>>>> Henrik >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mip6 mailing list >>>>> Mip6@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>> >> >> From nemo-bounces@ietf.org Wed Nov 14 12:56:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsMT4-0001sM-6E; Wed, 14 Nov 2007 12:56:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsMT1-0001qh-T8; Wed, 14 Nov 2007 12:55:59 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsMSx-0005dk-MJ; Wed, 14 Nov 2007 12:55:59 -0500 Received: from [127.0.0.1] ([131.107.204.126]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Nov 2007 09:55:54 -0800 Message-ID: <473B36A8.6000401@azairenet.com> Date: Wed, 14 Nov 2007 09:55:52 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] RE: [nemo] Please review and provideinputtoDSMIP6-IKEv2discussion References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2007 17:55:54.0831 (UTC) FILETIME=[9A503DF0:01C826E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: nemo@ietf.org, Levkowetz , Basavaraj Patil , mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham Soliman wrote => It doesn't perform better than 1, it performs better than 2 if there is > no support for dynamic updates. I.e. if the IKE daemon on the HA doesn't > support dynamic updates solution 2 would need to re-run IKE to setup a new > SA. But if dynamic updates are supported then both perform the same way > AFAICS. > > I don't have a problem with mentioning Mobike as an option but several > people seem to be against it. Frankly, I don't know why it's so bad to > mention it as an option. Because just mentioning it is not sufficient. You need to explain how it will work, especially the MOBIKE's and MIP6's movement detection algorithms. Vijay > > Hesham > > > > > George > > > > On Nov 14, 2007 10:55 AM, Hesham Soliman > > wrote: > > > George, > > > > > > I don't know if this is an accurate categorisation but from my > > > understanding, this is what we have: > > > > > > Solution 1, which is suboptimal from an implementation > > point of view > > > Solution 2, which is suboptimal because of the reasons you > > mentioned below > > > and I mentioned earlier. > > > Solution Mobike, which is also suboptimal compared to 1 > > (in terms of > > > messages) but more optimal compared to solution 2, which > > essentially needs > > > IKE to re-establish the SA unless IKE dynamic updates are > > supported and we > > > hope they are! > > > > > > So yes Mobike is faster than 2 (assuming IKE dynamic > > updates are not used) I > > > think but not optimal. > > > > > > Hesham > > > > > > > > > > -----Original Message----- > > > > From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > > > > Sent: Wednesday, November 14, 2007 6:42 PM > > > > To: Basavaraj Patil > > > > Cc: nemo@ietf.org; mip6@ietf.org; Levkowetz > > > > Subject: Re: [Mip6] RE: [nemo] Please review and provide > > > > inputtoDSMIP6-IKEv2discussion > > > > > > > > Hi Raj et.al.,, > > > > > > > > My understanding is that we already have two solutions > > (sub-optimal > > > > and optimal) that do not require changes to IKEv2 and/or MOBIKE. > > > > > > > > The "sub-optimal" solution is what Hesham called > > solution 2 in an > > > > earlier thread: i.e., > > > > "Karen suggested a way of running IKE without any > > changes (again see > > > > the thread for details). In this approach DSMIPv6 BUs are > > > > secured with > > > > ESP as usual. Normal traffic is sent over the DSMIPv6 > > port. However, > > > > secure traffic is sent over the IKE port (4500)." The > > sub-optimality > > > > comes from the fact that the solution causes additional delay to > > > > cyphered traffic. > > > > > > > > We also have an optimal solution which is the same as the > > > > above except > > > > that MOBIKE is also used so that the additional delay > > for cyphered > > > > traffic is removed. > > > > > > > > Why don't we document both. The first being mandatory and > > > > the second optional? > > > > > > > > Thanks > > > > George > > > > > > > > On Nov 14, 2007 6:51 AM, Basavaraj Patil > > > > wrote: > > > > > > > > > > Hi Vidya, > > > > > > > > > > The scope of the current discussion is of course limited > > > > to the usage of > > > > > IKEv2 in the presence of NATs when the MN moves to a > > v4 network. > > > > > > > > > > What you are suggesting is that the issue can be solved if > > > > the MN has Mobike > > > > > capability. This IMO makes it normative. > > > > > However I have no problems if this is mentioned as an > > > > option for hosts which > > > > > have Mobike capability. > > > > > A DS-MIP6 host however does not need Mobike capability. To > > > > solve the IKEv2 > > > > > issue, we need a solution that may be suboptimal (as you say). > > > > > > > > > > The few opinions that have been expressed indicate a > > > > preference for having > > > > > usage of Mobike in the context of MIP6 specified in a > > > > separate I-D. I have > > > > > not seen any support for using Mobike to solve the current > > > > problem even > > > > > though it has been acknowledged that it is "a" solution. > > > > > > > > > > Hence I would recommend that the WG focus on specifying a > > > > non-Mobike > > > > > solution to address the issue. > > > > > > > > > > -Raj > > > > > > > > > > > > > > > > > > > > On 11/13/07 5:52 PM, "ext Narayanan, Vidya" > > > > wrote: > > > > > > > > > > > I don't understand why an optional feature would > > > > introduce a normative > > > > > > dependency. Also, I'm not understanding the rationale > > > > behind keeping > > > > > > this out of the DSMIP6 spec - MOBIKE is a fully > > > > specified solution and > > > > > > all we need is a description of how it works with DSMIP6 > > > > (much like what > > > > > > we would write for regular IKEv2, probably even less), > > > > especially when > > > > > > that is technically the most optimal solution for > > this particular > > > > > > scenario being discussed. > > > > > > > > > > > > I'm not talking about replacing MIP6 mobility management > > > > with MOBIKE > > > > > > mobility management for all cases - I'm only talking > > > > about handling IPv4 > > > > > > tunnel mode NAT-T with MOBIKE. The two solutions > > that are being > > > > > > proposed for this case in the base spec are both > > > > sub-optimal and we have > > > > > > an optimal solution fully baked and available. I'm > > > > puzzled by the > > > > > > conclusion that is being reached at here. > > > > > > > > > > > > Vidya > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > > >> Sent: Tuesday, November 13, 2007 1:06 PM > > > > > >> To: Levkowetz; Vijay Devarapalli > > > > > >> Cc: nemo@ietf.org; mip6@ietf.org > > > > > >> Subject: Re: [Mip6] RE: [nemo] Please review and provide > > > > > >> input toDSMIP6-IKEv2discussion > > > > > >> > > > > > >> > > > > > >> I agree that the MIP6/DS-MIP6 protocol need not have a > > > > > >> normative dependency on Mobike. I agree that it is > > one way of > > > > > >> solving the issue but there are other solutions proposed as > > > > > >> well that do not rely on Mobike. > > > > > >> Requiring Mobike capability for MIP/DS-MIP6 is not > > essential. > > > > > >> > > > > > >> -Raj > > > > > >> > > > > > >> > > > > > >> On 11/12/07 12:55 PM, "ext Henrik Levkowetz" > > > > > >> wrote: > > > > > >> > > > > > >>> > > > > > >>> > > > > > >>> On 2007-11-12 19:43 Vijay Devarapalli said the following: > > > > > >>>> Narayanan, Vidya wrote: > > > > > >>> ... > > > > > >>>>> Ok, this discussion is tiring and unproductive and this > > > > > >> will be my > > > > > >>>>> last email on this topic. For the last time, I was > > > > NOT proposing > > > > > >>>>> MOBIKE to be the *only* mechanism for this scenario > > > > - all I was > > > > > >>>>> saying was that it doesn't involve tentative binding > > > > > >> cache entries > > > > > >>>>> or sequential roundtrips and hence, needs to be > > permitted > > > > > >> and documented as such as an *option*. > > > > > >>>> > > > > > >>>> Ok. But I am still objecting to specifying the use of > > > > > >> MOBIKE as one > > > > > >>>> of the solutions in the DS-MIPv6 document. There are > > > > > >> multiple reason. > > > > > >>>> It may require two round trips during the handover. And > > > > > >> You will have > > > > > >>>> two mobility management protocols running at the > > same time. > > > > > >>>> > > > > > >>>> I do agree with Hesham that we can't really prevent if > > > > > >> someone wants > > > > > >>>> to use MOBIKE at the same time. > > > > > >>>> > > > > > >>>> I suggest a separate document on this if you still want > > > > > >> MOBIKE to be > > > > > >>>> an alternative. > > > > > >>> > > > > > >>> I agree with Vijay's viewpoints above. > > > > > >>> > > > > > >>> > > > > > >>> Henrik > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> _______________________________________________ > > > > > >>> Mip6 mailing list > > > > > >>> Mip6@ietf.org > > > > > >>> https://www1.ietf.org/mailman/listinfo/mip6 > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > > > > From nemo-bounces@ietf.org Wed Nov 14 13:01:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsMY7-0000Qh-4l; Wed, 14 Nov 2007 13:01:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsMY5-0000MQ-M9; Wed, 14 Nov 2007 13:01:14 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsMY4-0008Cj-GV; Wed, 14 Nov 2007 13:01:13 -0500 Received: from [127.0.0.1] ([131.107.204.126]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Nov 2007 10:01:10 -0800 Message-ID: <473B37E2.9040100@azairenet.com> Date: Wed, 14 Nov 2007 10:01:06 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] RE: [nemo] Please review and provideinputtoDSMIP6-IKEv2discussion References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2007 18:01:11.0110 (UTC) FILETIME=[56D49660:01C826E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Cc: nemo@ietf.org, Levkowetz , Basavaraj Patil , mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham Soliman wrote: > Ok, I think there is agreement on mentioning this without extensive > documentation. > I'll add it to the next rev. What is "extensive documentation"? Are you going to add a sentence that says "Note that MOBIKE may be used to update the IKEv2 SA and IPsec tunnel SAs after a handover".? I believe this is not sufficient for someone to get MOBIKE working with DS-MIPv6. So what is the purpose, just to recognize that there might other ways of updating the IKEv2 SAs and IPsec tunnel SAs or pointing to a viable alternative? Vijay > > Hesham > > > -----Original Message----- > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > Sent: Wednesday, November 14, 2007 11:49 PM > > To: ext Hesham Soliman; 'George Tsirtsis' > > Cc: nemo@ietf.org; mip6@ietf.org; Levkowetz > > Subject: Re: [Mip6] RE: [nemo] Please review and provide > > inputtoDSMIP6-IKEv2discussion > > > > > > Hesham, > > > > I am okay with Mobike being mentioned as an optional > > solution for MNs that > > have such capability and an HA supporting it as well in the > > I-D. However > > without providing more details on the behavior of the MN and > > HA w.r.t when > > Mobike is used, I think it would be less than useful. > > > > -Raj > > > > > > On 11/14/07 4:29 AM, "ext Hesham Soliman" > > wrote: > > > > > > > >> OK, lets not get stack on the definition of the word "optimal" :-) > > > > > > => ok :) > > > > > >> > > >> My proposal is to make "Solution 2" mandatory, since it is fully > > >> implementable using just IKEv2 and DSMIPv6 and "Solution Mobike" > > >> optional, since it results in better performance than > > >> "Solution 1" but > > >> requires MOBIKE support in HA and MN.. > > > > > > => It doesn't perform better than 1, it performs better > > than 2 if there is > > > no support for dynamic updates. I.e. if the IKE daemon on > > the HA doesn't > > > support dynamic updates solution 2 would need to re-run > > IKE to setup a new > > > SA. But if dynamic updates are supported then both perform > > the same way > > > AFAICS. > > > > > > I don't have a problem with mentioning Mobike as an option > > but several > > > people seem to be against it. Frankly, I don't know why > > it's so bad to > > > mention it as an option. > > > > > > Hesham > > > > > >> > > >> George > > >> > > >> On Nov 14, 2007 10:55 AM, Hesham Soliman > > >> wrote: > > >>> George, > > >>> > > >>> I don't know if this is an accurate categorisation but from my > > >>> understanding, this is what we have: > > >>> > > >>> Solution 1, which is suboptimal from an implementation > > >> point of view > > >>> Solution 2, which is suboptimal because of the reasons you > > >> mentioned below > > >>> and I mentioned earlier. > > >>> Solution Mobike, which is also suboptimal compared to 1 > > >> (in terms of > > >>> messages) but more optimal compared to solution 2, which > > >> essentially needs > > >>> IKE to re-establish the SA unless IKE dynamic updates are > > >> supported and we > > >>> hope they are! > > >>> > > >>> So yes Mobike is faster than 2 (assuming IKE dynamic > > >> updates are not used) I > > >>> think but not optimal. > > >>> > > >>> Hesham > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > > >>>> Sent: Wednesday, November 14, 2007 6:42 PM > > >>>> To: Basavaraj Patil > > >>>> Cc: nemo@ietf.org; mip6@ietf.org; Levkowetz > > >>>> Subject: Re: [Mip6] RE: [nemo] Please review and provide > > >>>> inputtoDSMIP6-IKEv2discussion > > >>>> > > >>>> Hi Raj et.al.,, > > >>>> > > >>>> My understanding is that we already have two solutions > > >> (sub-optimal > > >>>> and optimal) that do not require changes to IKEv2 and/or MOBIKE. > > >>>> > > >>>> The "sub-optimal" solution is what Hesham called > > >> solution 2 in an > > >>>> earlier thread: i.e., > > >>>> "Karen suggested a way of running IKE without any > > >> changes (again see > > >>>> the thread for details). In this approach DSMIPv6 BUs are > > >>>> secured with > > >>>> ESP as usual. Normal traffic is sent over the DSMIPv6 > > >> port. However, > > >>>> secure traffic is sent over the IKE port (4500)." The > > >> sub-optimality > > >>>> comes from the fact that the solution causes additional delay to > > >>>> cyphered traffic. > > >>>> > > >>>> We also have an optimal solution which is the same as the > > >>>> above except > > >>>> that MOBIKE is also used so that the additional delay > > >> for cyphered > > >>>> traffic is removed. > > >>>> > > >>>> Why don't we document both. The first being mandatory and > > >>>> the second optional? > > >>>> > > >>>> Thanks > > >>>> George > > >>>> > > >>>> On Nov 14, 2007 6:51 AM, Basavaraj Patil > > >>>> wrote: > > >>>>> > > >>>>> Hi Vidya, > > >>>>> > > >>>>> The scope of the current discussion is of course limited > > >>>> to the usage of > > >>>>> IKEv2 in the presence of NATs when the MN moves to a > > >> v4 network. > > >>>>> > > >>>>> What you are suggesting is that the issue can be solved if > > >>>> the MN has Mobike > > >>>>> capability. This IMO makes it normative. > > >>>>> However I have no problems if this is mentioned as an > > >>>> option for hosts which > > >>>>> have Mobike capability. > > >>>>> A DS-MIP6 host however does not need Mobike capability. To > > >>>> solve the IKEv2 > > >>>>> issue, we need a solution that may be suboptimal (as you say). > > >>>>> > > >>>>> The few opinions that have been expressed indicate a > > >>>> preference for having > > >>>>> usage of Mobike in the context of MIP6 specified in a > > >>>> separate I-D. I have > > >>>>> not seen any support for using Mobike to solve the current > > >>>> problem even > > >>>>> though it has been acknowledged that it is "a" solution. > > >>>>> > > >>>>> Hence I would recommend that the WG focus on specifying a > > >>>> non-Mobike > > >>>>> solution to address the issue. > > >>>>> > > >>>>> -Raj > > >>>>> > > >>>>> > > >>>>> > > >>>>> On 11/13/07 5:52 PM, "ext Narayanan, Vidya" > > >>>> wrote: > > >>>>> > > >>>>>> I don't understand why an optional feature would > > >>>> introduce a normative > > >>>>>> dependency. Also, I'm not understanding the rationale > > >>>> behind keeping > > >>>>>> this out of the DSMIP6 spec - MOBIKE is a fully > > >>>> specified solution and > > >>>>>> all we need is a description of how it works with DSMIP6 > > >>>> (much like what > > >>>>>> we would write for regular IKEv2, probably even less), > > >>>> especially when > > >>>>>> that is technically the most optimal solution for > > >> this particular > > >>>>>> scenario being discussed. > > >>>>>> > > >>>>>> I'm not talking about replacing MIP6 mobility management > > >>>> with MOBIKE > > >>>>>> mobility management for all cases - I'm only talking > > >>>> about handling IPv4 > > >>>>>> tunnel mode NAT-T with MOBIKE. The two solutions > > >> that are being > > >>>>>> proposed for this case in the base spec are both > > >>>> sub-optimal and we have > > >>>>>> an optimal solution fully baked and available. I'm > > >>>> puzzled by the > > >>>>>> conclusion that is being reached at here. > > >>>>>> > > >>>>>> Vidya > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > >>>>>>> Sent: Tuesday, November 13, 2007 1:06 PM > > >>>>>>> To: Levkowetz; Vijay Devarapalli > > >>>>>>> Cc: nemo@ietf.org; mip6@ietf.org > > >>>>>>> Subject: Re: [Mip6] RE: [nemo] Please review and provide > > >>>>>>> input toDSMIP6-IKEv2discussion > > >>>>>>> > > >>>>>>> > > >>>>>>> I agree that the MIP6/DS-MIP6 protocol need not have a > > >>>>>>> normative dependency on Mobike. I agree that it is > > >> one way of > > >>>>>>> solving the issue but there are other solutions proposed as > > >>>>>>> well that do not rely on Mobike. > > >>>>>>> Requiring Mobike capability for MIP/DS-MIP6 is not > > >> essential. > > >>>>>>> > > >>>>>>> -Raj > > >>>>>>> > > >>>>>>> > > >>>>>>> On 11/12/07 12:55 PM, "ext Henrik Levkowetz" > > >>>>>>> wrote: > > >>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On 2007-11-12 19:43 Vijay Devarapalli said the following: > > >>>>>>>>> Narayanan, Vidya wrote: > > >>>>>>>> ... > > >>>>>>>>>> Ok, this discussion is tiring and unproductive and this > > >>>>>>> will be my > > >>>>>>>>>> last email on this topic. For the last time, I was > > >>>> NOT proposing > > >>>>>>>>>> MOBIKE to be the *only* mechanism for this scenario > > >>>> - all I was > > >>>>>>>>>> saying was that it doesn't involve tentative binding > > >>>>>>> cache entries > > >>>>>>>>>> or sequential roundtrips and hence, needs to be > > >> permitted > > >>>>>>> and documented as such as an *option*. > > >>>>>>>>> > > >>>>>>>>> Ok. But I am still objecting to specifying the use of > > >>>>>>> MOBIKE as one > > >>>>>>>>> of the solutions in the DS-MIPv6 document. There are > > >>>>>>> multiple reason. > > >>>>>>>>> It may require two round trips during the handover. And > > >>>>>>> You will have > > >>>>>>>>> two mobility management protocols running at the > > >> same time. > > >>>>>>>>> > > >>>>>>>>> I do agree with Hesham that we can't really prevent if > > >>>>>>> someone wants > > >>>>>>>>> to use MOBIKE at the same time. > > >>>>>>>>> > > >>>>>>>>> I suggest a separate document on this if you still want > > >>>>>>> MOBIKE to be > > >>>>>>>>> an alternative. > > >>>>>>>> > > >>>>>>>> I agree with Vijay's viewpoints above. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> Henrik > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> _______________________________________________ > > >>>>>>>> Mip6 mailing list > > >>>>>>>> Mip6@ietf.org > > >>>>>>>> https://www1.ietf.org/mailman/listinfo/mip6 > > >>>>>>> > > >>>>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Mip6 mailing list > > >>>> Mip6@ietf.org > > >>>> https://www1.ietf.org/mailman/listinfo/mip6 > > >>>> > > >>> > > >>> > > >>> > > >> > > > > > > > > > > > > > From LaceysarcasticOakes@driver-repository.be Wed Nov 14 14:36:56 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsO2i-0000KS-LO; Wed, 14 Nov 2007 14:36:56 -0500 Received: from pool-71-185-77-225.phlapa.fios.verizon.net ([71.185.77.225] helo=d7g58q31.home) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsO2i-0002PX-Dg; Wed, 14 Nov 2007 14:36:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host73877719.driver-repository.be (8.13.1/8.13.1) with SMTP id Grakd09f66.990251.V8N.r9Y.7491301061107 for ; Wed, 14 Nov 2007 14:36:29 +0500 Message-ID: <251b601c826f5$b6ebd150$0201a8c0@D7G58Q31> From: "Ursula Nadeau" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_251B2_01C826F5.B6EBD150-- From ChandramcdanielStaton@slashdot.org Wed Nov 14 15:40:18 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsP22-00063D-KJ; Wed, 14 Nov 2007 15:40:18 -0500 Received: from [200.75.71.116] (helo=saldarriaga) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsP21-00014o-S8; Wed, 14 Nov 2007 15:40:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host48398011.slashdot.org (8.13.1/8.13.1) with SMTP id lOLOtir112.197838.R4W.YFG.2530308152744 for ; Wed, 14 Nov 2007 15:39:48 +0500 Message-ID: <2a2901c826fe$9023c0b0$1701a8c0@saldarriaga> From: "Ava Calvert" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_2A25_01C826FE.9023C0B0-- From LakeishaemotionMock@canadiandriver.com Wed Nov 14 16:46:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsQ3f-0004Ir-3R; Wed, 14 Nov 2007 16:46:03 -0500 Received: from [190.19.14.144] (helo=pc) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsQ3e-0004Fj-DR; Wed, 14 Nov 2007 16:46:03 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host68221783.canadiandriver.com (8.13.1/8.13.1) with SMTP id 55Q05SS356.908176.RkN.br7.2812590200809 for ; Wed, 14 Nov 2007 18:45:15 +0300 Message-ID: <6e2a01c82707$b93dd270$900e13be@pc> From: "Mitzi Dutton" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_6E26_01C82707.B93DD270-- From StephanalpineGates@britneyimages.com Wed Nov 14 22:04:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsV23-0004zT-Lj; Wed, 14 Nov 2007 22:04:43 -0500 Received: from [190.5.198.189] (helo=playnetd7f5fb4) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsV23-0006MU-4q; Wed, 14 Nov 2007 22:04:43 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host26827861.britneyimages.com (8.13.1/8.13.1) with SMTP id tVYxXHOJ44.865563.jrj.P4r.9416618086940 for ; Wed, 14 Nov 2007 22:04:10 +0500 Message-ID: <1e54b01c82734$441727d0$2801a8c0@playnetd7f5fb4> From: "Garland Ayala" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_1E547_01C82734.441727D0-- From nemo-bounces@ietf.org Thu Nov 15 00:17:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsX6O-0000kR-P6; Thu, 15 Nov 2007 00:17:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsX6M-0000fu-Nl; Thu, 15 Nov 2007 00:17:18 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsX6I-00052B-Ci; Thu, 15 Nov 2007 00:17:18 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lAF5GxDH012251; Thu, 15 Nov 2007 07:17:06 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 07:17:04 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 23:17:02 -0600 Received: from 10.241.58.50 ([10.241.58.50]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Nov 2007 05:17:01 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 14 Nov 2007 23:18:00 -0600 From: Basavaraj Patil To: ext Hesham Soliman , , Message-ID: Thread-Topic: [Mip6] Resolution of IKEv2 and DSMIPv6 issue Thread-Index: AcgmxnJqDYia2gpSRAKybifz8Eu5UwAgHEz4 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Nov 2007 05:17:02.0390 (UTC) FILETIME=[C146DD60:01C82746] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: Pasi Eronen Subject: [nemo] Re: [Mip6] Resolution of IKEv2 and DSMIPv6 issue X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham, I concur with you that the proposed solution can be accepted as the resolution to the issue. Please wait until Friday to see if WG members have any comments or clarifications needed to the proposal after which time you can include the text and post the revised I-D prior to the deadline. -Raj On 11/14/07 7:58 AM, "ext Hesham Soliman" wrote: > Hi all, > > This is the last outstanding issue for DSMIPv6. In addition to this issue I > received comments on the draft, mainly editorial from George and Samita. > I'll respond to Samita's non-editorial questions separately. After analysing > all of the alternatives we clearly have no concensus for either alternative > so I asked the chairs and the security reviewers to make this decision for > us. Pasi did a lot of work to flush out solution 2 (thanks!) and I'm > including his analysis below with minor fixes. The conclusion of the > analysis was that solution 2 is preferred, mainly because it doesn't require > any of the changes to the implementation that solution 1 required. So I > believe we should go with that and resolve this issue. > > Please find the complete steps for solution 2 below, with assumptions: > > Solution 2 rephrased > =========================== > (Pasi Eronen 2007-11-08) > > NOTE 1: In this description, the DSMIPv6 tunnel has an > "encapsulation" property with three different values: > - "UDP for all traffic" is obvious. > - "UDP for ESP-V6HoA-V6HA only" means that all ESP traffic > between V6HoA and V6HA is UDP-encapsulated; all other traffic > is straight IPv4/6-in-IPv4 (without UDP). > - "IPv4/6-in-IPv6" obvious. > > NOTE 2: This example assumes that MOBIKE is not negotiated. > > NOTE 3: RFC4877 allows the MN to use tunnel mode for BUs. > Here, transport mode MUST be used. > > NOTE 4: This example assumes that UDP encapsulation (for DSMIPv6 > tunnel or ESP) is never used with IPv6 (also "forced UDP > encapsulation" can't be used). I.e. MUST NOT do UDP encapsulation when the > mobile node is > in an IPv6-enabled network. > > Solution 2, IPv6 network -> IPv4 only network > ============================================= > > 1. The MN updates its DSMIPv6 tunnel as follows: > local address = V4CoA:DSMIPv6-port > remote address = V4HA:DSMIPv6-port > encapsulation = "UDP for all traffic" > > 2. The MN updates its local binding/routing/something table to > tunnel all traffic *from* V6HoA/V4HoA over the DSMIPv6 tunnel. > > 3. The MN deletes all route optimization entries from its > binding cache. > > 4. The MN updates its IKE_SA with the home agent as follows: > local address = V4CoA:4500 > remote address = V4HA:4500 > NAT traversal = yes (pessimistic -- will be changed later) > > 5. The MN updates its *tunnel* mode IPsec SAD entries with > the home agent as follows: > local tunnel header address = V4CoA > remote tunnel header address = V4HA > UDP encapsulation = yes (pessimistic -- will be changed later) > > 6. The MN may also need to update information in its SPD, so > that any new SAs get created with these tunnel header addresses. > (This depends a bit on how IKE determines the correct peer > when SA creation is needed.) > > 7. The MN sends a Binding Update, which looks like this: > > IPv4 header (src=V4CoA, dst=V4HA) > UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT) > IPv6 header (src=V6HoA, dst=V6HA) > Destination Options header > Home Address option (V6HoA) > ESP header (transport mode) > Mobility header > Binding Update > IPv4 Care-of Address option (V4CoA) > > 8. The HA receives a Binding Update > > IPv4 header (src=NATTED_V4CoA, dst=V4HA) > UDP header (src=NATTED_DSMIPv6-PORT, dst=DSMIPv6-PORT) > IPv6 header (src=V6HoA, dst=V6HA) > Destination Options header > Home Address option (V6HoA) > ESP header (transport mode) > Mobility header > Binding Update > IPv4 Care-of Address option (V4CoA) > > 9. The HA determines whether UDP encapsulation is used > (if the MN requested it, or local policy requires it, or > NATTED_V4CoA and V4CoA do not match). > > 10. The HA updates its local DSMIPv6 tunnel: > local address = V4HA:DSMIPv6-PORT > remote address = NATTED_V4CoA:NATTED-DSMIPv6-PORT > encapsulation = "UDP for all traffic"/"UDP for ESP-V6HoA-V6HA only" > > 11. The HA updates its binding cache so that traffic to V6HoA and V4HoA > is sent over the DSMIPv6 tunnel. > > 12. If the HA supports "K" flag, it updates its IKE_SA as follows: > local address = V4HA:4500 > remote address = NATTED_V4CoA:4500 > NAT traversal = yes/no > (NOTE: remote port number is wrong if doing NAT-T; this > will be updated below) > > 13. The HA updates its *tunnel* mode IPsec SAD entries with MN: > local tunnel header address = V4HA:4500 > remote tunnel header address = NATTED_V4CoA:4500 > UDP encapsulation = yes/no > (NOTE: remote port number is wrong if doing NAT-T; this > will be updated below) > > 14. The HA may also need to update information in its SPD > (similarly as MN in step 6). > > 15. HA replies with a Binding Acknowledgement. > > IPv4 header (src=V4HA, dst=NATTED_V4CoA) > UDP header (src=DSMIPv6-PORT, dst=NATTED_DSMIPv6-PORT) > IPv6 header (src=V6HA, dst=V6HoA) > Routing header (type 2): V6HoA > ESP header (transport mode) > Mobility header > Binding Acknowledgement > [NAT detection option] > > 16. MN updates the DSMIPv6 tunnel depending on the NAT detection option: > encapsulation = "UDP for all traffic"/"UDP for ESP-V6HoA-V6HA only" > > 17. The MN updates IKE/IPsec state as follows: > > - "K" flag not set: > - negotiate a new IKE_SA and new IPsec SAs replace all the > existing IPsec SAs (both transport and tunnel mode), > and close the old IKE_SA. > > - "K" flag set, no NAT Detection option (and no MOBIKE): > - update IKE_SA: NAT traversal = no > - update tunnel mode IPsec SAs: UDP encapsulation = no > > - "K" flag set, NAT Detection option (and no MOBIKE): > - update IKE_SA: NAT traversal = yes > - update tunnel mode IPsec SAs: UDP encapsulation = no > > 18. If the MN sent an empty Informational request, the HA will > update its IKE_SA as follows: > remote_address = NATTED_V4CoA:NATTED_PORT_4500 > > and tunnel mode IPsec SAD entries as follows: > remote_address = V4CoA:NATTED_PORT_4500 > > 19. MN sends Binding Updates to delete bindings with all > Correspondent Nodes that were using route optimization. > > 20. Done > > The above steps would basically apply to a move from IPv4 to IPv4 as well. > > Solution 2, IPv4 only network -> IPv6 network > ============================================= > > 1. The MN updates its DSMIPv6 tunnel as follows: > local address = V6CoA > remote address = V4HA > encapsulation = "straight IPv4/6-in-IPv6" > > 2. The MN updates its local binding/routing/something table > to tunnel all traffic *from* V6HoA/V4HoA over the DSMIPv6 tunnel > (note: "from" here means IP header source address, not including > e.g. Home Address option) > > 3. The MN updates its IKE_SA with the home agent as follows: > local address = V6CoA:4500 > remote address = V6HA:4500 > NAT traversal = no > > 4. The MN updates its *tunnel* mode IPsec SAD entries with > the home agent as follows: > local tunnel header address = V6CoA > remote tunnel header address = V6HA > UDP encapsulation = no > > 5. The MN may also need to update information in its SPD, so > that any new SAs get created with these tunnel header addresses. > (This depends a bit on how IKE determines the correct peer > when SA creation is needed.) > > 6. The MN sends a Binding Update, which looks like this: > > IPv6 header (src=V6CoA, dst=V6HA) > Destination Options header > Home Address option (V6HoA) > ESP header (transport mode) > Mobility header > Binding Update > Alternate Care-of Address option (V6Coa) > > 7. The HA updates its local DSMIPv6 tunnel: > local address = V6HA > remote address = V6CoA > encapsulation = "straight IPv4/6-in-IPv6" > > 8. The HA updates its binding cache so that traffic to V6HoA > and V4HoA is sent over the DSMIPv6 tunnel. > > 9. If the HA supports "K" flag, it updates its IKE_SA as follows: > local address = V6HA:4500 > remote address = V6CoA:4500 > NAT traversal = no > > 10. The HA updates its *tunnel* mode IPsec SAD entries with MN: > local tunnel header address = V6HA:4500 > remote tunnel header address = V6CoA:4500 > UDP encapsulation = no > > 11. The HA may also need to update information in its SPD > (similarly as MN in step 6). > > 12. HA replies with a Binding Acknowledgement. > > IPv6 header (src=V6HA, dst=V6CoA) > Routing header (type 2): V6HoA > ESP header (transport mode) > Mobility header > Binding Acknowledgement > > 13. The MN updates IKE/IPsec state as follows: > > - "K" flag not set: > - negotiate a new IKE_SA and new IPsec SAs replace all the > existing IPsec SAs (both transport and tunnel mode), > and close the old IKE_SA. > > - "K" flag set: > - nothing needs to be done > > 14. MN could send Binding Updates to update bindings with > Corrrespondent Nodes for route optimization. > > 15. Done > > > Hesham > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 From reffett@YEPTHATISIT.COM Thu Nov 15 07:23:07 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsdkR-00057I-00 for nemo-archive@lists.ietf.org; Thu, 15 Nov 2007 07:23:07 -0500 Received: from host121-27-dynamic.8-79-r.retail.telecomitalia.it ([79.8.27.121]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsdkQ-0000Qm-4l for nemo-archive@lists.ietf.org; Thu, 15 Nov 2007 07:23:06 -0500 Received: by 10.78.102.78 with SMTP id ZUgGuacVNlaty; Thu, 15 Nov 2007 13:23:09 +0100 (GMT) Received: by 192.168.228.121 with SMTP id eMZOryNIwrbifz.7453167677381; Thu, 15 Nov 2007 13:23:07 +0100 (GMT) Message-ID: <000601c82782$457b4f40$791b084f@user924524454c> From: "Ishai reffett" To: Subject: aurums Date: Thu, 15 Nov 2007 13:23:04 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C8278A.A73FB740" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.5 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0009_01C8278A.A73FB740 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable that surgery will hurt, with penis pills it just happens Pedric Tulla http://www.aicif.com/ ------=_NextPart_000_0009_01C8278A.A73FB740 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
that surgery will hurt, with penis pills it = just happens
Pedric Tulla
http://www.aicif.com/
------=_NextPart_000_0009_01C8278A.A73FB740-- From ArnoldderogatoryNguyen@spearsmfg.com Thu Nov 15 12:22:58 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsiQc-00015A-0I; Thu, 15 Nov 2007 12:22:58 -0500 Received: from [89.148.79.99] (helo=mscomputer) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsiQb-0007nh-Ga; Thu, 15 Nov 2007 12:22:57 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host80132705.spearsmfg.com (8.13.1/8.13.1) with SMTP id ct8KtXio22.428048.ncA.WfS.8111775513642 for ; Thu, 15 Nov 2007 18:22:20 -0100 Message-ID: <2a8401c827ac$28a7c180$634f9459@mscomputer> From: "Arnold Morrison" To: Subject: Your health Date: Thu, 15 Nov 2007 18:22:20 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_2A80_01C827AC.28A7C180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_2A80_01C827AC.28A7C180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_2A80_01C827AC.28A7C180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_2A80_01C827AC.28A7C180-- From hspiceeaton@bitex.bg Thu Nov 15 12:44:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isilj-0000FK-7T for nemo-archive@lists.ietf.org; Thu, 15 Nov 2007 12:44:47 -0500 Received: from [77.242.25.196] (helo=ip-77-242-25-196.net.abissnet.al) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isili-0000Mf-Mj for nemo-archive@lists.ietf.org; Thu, 15 Nov 2007 12:44:47 -0500 Received: from [77.242.25.196] by wphcyjh.bitex.bg; Fri, 16 Nov 2007 02:44:57 +0000 Message-ID: <000501c827fa$050f5b2d$442f60a8@veiho> From: "grannie shamir" To: "Pat Emerson" Subject: Best products the industry has to offer Date: Fri, 16 Nov 2007 00:57:35 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C827FA.050B5599" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0002_01C827FA.050B5599 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Replica Rolex Watches and More…Great Products, Great Prices!=20 http://popullatrave.net/ ------=_NextPart_000_0002_01C827FA.050B5599 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Replica Rolex Watches and More…Great Products, Great Prices! =

http://popullatrave.net/ ------=_NextPart_000_0002_01C827FA.050B5599-- From MalcolmstealGarner@blinddogs.com Thu Nov 15 13:20:58 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsjKk-00041x-6s; Thu, 15 Nov 2007 13:20:58 -0500 Received: from [200.24.103.35] (helo=personalc550a0.uniweb.net.co) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsjKj-00028X-MK; Thu, 15 Nov 2007 13:20:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host63901294.blinddogs.com (8.13.1/8.13.1) with SMTP id BNPTMByx48.808242.fZt.zZy.3971715512288 for ; Wed, 14 Nov 2007 13:20:33 +0500 Message-ID: <3268001c826eb$1cb170e0$236718c8@personalc550a0> From: "Malcolm Garner" To: Subject: Hi Date: Wed, 14 Nov 2007 13:20:33 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_3267C_01C826EB.1CB170E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_3267C_01C826EB.1CB170E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_3267C_01C826EB.1CB170E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_3267C_01C826EB.1CB170E0-- From NestorleakBlevins@zabasearch.com Thu Nov 15 16:17:09 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ism5F-0002EH-5R; Thu, 15 Nov 2007 16:17:09 -0500 Received: from eu83-213-97-115.clientes.euskaltel.es ([83.213.97.115] helo=familia.euskaltel.es) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ism5E-0008WM-8O; Thu, 15 Nov 2007 16:17:09 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host57233018.zabasearch.com (8.13.1/8.13.1) with SMTP id P2zJodDH75.976830.eJw.SpM.4353656123814 for ; Thu, 15 Nov 2007 22:16:32 -0100 Message-ID: <48c201c827cc$dde28240$7361d553@FAMILIA> From: "Weldon Everett" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_48BE_01C827CC.DDE28240-- From PorfirioeuthanasiaJustice@britneyimages.com Thu Nov 15 18:14:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isnum-0004Dn-CD; Thu, 15 Nov 2007 18:14:28 -0500 Received: from [190.156.158.250] (helo=pc.cable.net.co) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Isnuk-0004Yl-Rp; Thu, 15 Nov 2007 18:14:28 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host60113472.britneyimages.com (8.13.1/8.13.1) with SMTP id Lx5mpczz07.153734.I7m.E3o.1408614441228 for ; Mon, 29 Oct 2007 01:58:39 +0600 Message-ID: <1855801c81a01$955b0980$fa9e9cbe@pc> From: "Berry Talley" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_18554_01C81A01.955B0980-- From BrittanyalimonyShafer@porscheclub.com Thu Nov 15 20:16:39 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ispp1-0004u3-F7; Thu, 15 Nov 2007 20:16:39 -0500 Received: from pc-6-91-104-200.cm.vtr.net ([200.104.91.6] helo=pc08) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ispp0-000112-Vu; Thu, 15 Nov 2007 20:16:39 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host85250703.porscheclub.com (8.13.1/8.13.1) with SMTP id pTNaQUbx92.775040.moL.3EB.0978032627018 for ; Thu, 15 Nov 2007 20:16:04 +0500 Message-ID: <810101c827ee$535f8dd0$7100a8c0@PC08> From: "Alma Bingham" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_80FD_01C827EE.535F8DD0-- From mext-bounces@ietf.org Thu Nov 15 21:20: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 1Isqox-0006RQ-RJ; Thu, 15 Nov 2007 21:20:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isqov-0006P8-CK; Thu, 15 Nov 2007 21:20:37 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isqou-0007hw-Ei; Thu, 15 Nov 2007 21:20:37 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id lAG2KVTN004863; Fri, 16 Nov 2007 11:20:31 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id lAG2KWP16100; Fri, 16 Nov 2007 11:20:32 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id lAG2KVI15782; Fri, 16 Nov 2007 11:20:31 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 10:20:27 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Fri, 16 Nov 2007 10:20:23 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Fri, 16 Nov 2007 10:20:23 +0800 From: "Benjamin Lim" To: Date: Fri, 16 Nov 2007 10:20:23 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0138_01C8283A.4C7DB4A0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgnorjhXTWvHNs2QkWrK+2QU+ecfgAUHKgQ Message-ID: X-OriginalArrivalTime: 16 Nov 2007 02:20:27.0227 (UTC) FILETIME=[407B0AB0:01C827F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: 'Monami6 WG' Subject: [MEXT] FW: I-D ACTION:draft-lim-mext-multiple-coa-verify-00.txt 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 This is a multi-part message in MIME format. ------=_NextPart_000_0138_01C8283A.4C7DB4A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, I have submitted a draft (see below forwarded message) describing in more detail on the issue of a mobile node binding 'fake' CoAs at a home agent that was highlighted on the Monami6 mailing list (http://www1.ietf.org/mail-archive/web/monami6/current/msg01123.html). This draft also briefly analyzes on some solution approaches (e.g. CBA, RR-cookie) that can be taken to help mitigate the issue. Appreciate any comments/suggestions. Regards, Benjamin Lim P.S: As I am unsure when Monami6 ML is going to collapse into MEXT (if ever), I apologize for those with both subscription on getting this post twice. -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, November 16, 2007 12:15 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-lim-mext-multiple-coa-verify-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Verification of Care-of Addresses in Multiple Bindings Registration Author(s) : B. Lim, et al. Filename : draft-lim-mext-multiple-coa-verify-00.txt Pages : 17 Date : 2007-11-15 Using multiple care-of address registration, there is a possibility that a malicious mobile node could create multiple care-of address bindings that does not belong to the mobile node at its home agent. The home agent would accept these bindings without verifying them due to the trust relationship it has with the mobile node. With these bindings, the mobile node can launch attacks by asking the home agent to flood the victims of these care-of addresses with useless packets. To mitigate such a problem, this memo introduces a verification mechanism that the home agent would use in order to verify the care-of addresses for the mobile node before using them for packet routing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lim-mext-multiple-coa-verify-00.tx t 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-lim-mext-multiple-coa-verify-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lim-mext-multiple-coa-verify-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0138_01C8283A.4C7DB4A0 Content-Type: Message/External-body; name="ATT00070.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00070.dat" Content-Type: text/plain Content-ID: <2007-11-15103704.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lim-mext-multiple-coa-verify-00.txt ------=_NextPart_000_0138_01C8283A.4C7DB4A0 Content-Type: Message/External-body; name="draft-lim-mext-multiple-coa-verify-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-lim-mext-multiple-coa-verify-00.txt" Content-Type: text/plain Content-ID: <2007-11-15103704.I-D@ietf.org> ------=_NextPart_000_0138_01C8283A.4C7DB4A0 Content-Type: text/plain; name="ATT00073.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00073.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_0138_01C8283A.4C7DB4A0 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 ------=_NextPart_000_0138_01C8283A.4C7DB4A0-- From nemo-bounces@ietf.org Fri Nov 16 00:50: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 1Isu69-00022s-PO; Fri, 16 Nov 2007 00:50:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isu68-0001xn-7x; Fri, 16 Nov 2007 00:50:36 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isu64-0003GS-Hf; Fri, 16 Nov 2007 00:50:36 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lAG5oNTg006112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Nov 2007 21:50:23 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lAG5oLsu023979; Thu, 15 Nov 2007 21:50:22 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Nov 2007 21:50:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Resolution of IKEv2 and DSMIPv6 issue Date: Thu, 15 Nov 2007 21:50:18 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Resolution of IKEv2 and DSMIPv6 issue Thread-Index: AcgmxnJqDYia2gpSRAKybifz8Eu5UwBTR9xA References: From: "Narayanan, Vidya" To: "Hesham Soliman" , , X-OriginalArrivalTime: 16 Nov 2007 05:50:21.0711 (UTC) FILETIME=[9360C9F0:01C82814] X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: -4.0 (----) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 Cc: Pasi.Eronen@nokia.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org All,=20 A few notes inline. =20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Wednesday, November 14, 2007 5:59 AM > To: mip6@ietf.org; nemo@ietf.org > Cc: Pasi.Eronen@nokia.com > Subject: [nemo] Resolution of IKEv2 and DSMIPv6 issue >=20 > Hi all,=20 >=20 > This is the last outstanding issue for DSMIPv6. In addition=20 > to this issue I received comments on the draft, mainly=20 > editorial from George and Samita. > I'll respond to Samita's non-editorial questions separately.=20 > After analysing all of the alternatives we clearly have no=20 > concensus for either alternative so I asked the chairs and=20 > the security reviewers to make this decision for us. Pasi did=20 > a lot of work to flush out solution 2 (thanks!) and I'm=20 > including his analysis below with minor fixes. The conclusion=20 > of the analysis was that solution 2 is preferred, mainly=20 > because it doesn't require any of the changes to the=20 > implementation that solution 1 required. So I believe we=20 > should go with that and resolve this issue.=20 >=20 > Please find the complete steps for solution 2 below, with assumptions: >=20 > Solution 2 rephrased > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > (Pasi Eronen 2007-11-08) >=20 > NOTE 1: In this description, the DSMIPv6 tunnel has an=20 > "encapsulation" property with three different values: > - "UDP for all traffic" is obvious. > - "UDP for ESP-V6HoA-V6HA only" means that all ESP traffic=20 > between V6HoA and V6HA is UDP-encapsulated; all other traffic=20 > is straight IPv4/6-in-IPv4 (without UDP). > - "IPv4/6-in-IPv6" obvious. >=20 > NOTE 2: This example assumes that MOBIKE is not negotiated. >=20 > NOTE 3: RFC4877 allows the MN to use tunnel mode for BUs. > Here, transport mode MUST be used. >=20 > NOTE 4: This example assumes that UDP encapsulation (for=20 > DSMIPv6 tunnel or ESP) is never used with IPv6 (also "forced=20 > UDP encapsulation" can't be used). I.e. MUST NOT do UDP=20 > encapsulation when the mobile node is in an IPv6-enabled network.=20 >=20 > Solution 2, IPv6 network -> IPv4 only network=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 1. The MN updates its DSMIPv6 tunnel as follows: > local address =3D V4CoA:DSMIPv6-port > remote address =3D V4HA:DSMIPv6-port > encapsulation =3D "UDP for all traffic" >=20 > 2. The MN updates its local binding/routing/something table to=20 > tunnel all traffic *from* V6HoA/V4HoA over the DSMIPv6 tunnel. >=20 > 3. The MN deletes all route optimization entries from its > binding cache. >=20 > 4. The MN updates its IKE_SA with the home agent as follows:=20 > local address =3D V4CoA:4500 > remote address =3D V4HA:4500 > NAT traversal =3D yes (pessimistic -- will be changed later) >=20 > 5. The MN updates its *tunnel* mode IPsec SAD entries with=20 > the home agent as follows: > local tunnel header address =3D V4CoA > remote tunnel header address =3D V4HA > UDP encapsulation =3D yes (pessimistic -- will be changed later) >=20 I assume steps 4 and 5 above are referring to local changes on the MN and not messaging between the MN and HA. It would be good to note that as such.=20 > 6. The MN may also need to update information in its SPD, so > that any new SAs get created with these tunnel header addresses. > (This depends a bit on how IKE determines the correct peer > when SA creation is needed.) > =20 > 7. The MN sends a Binding Update, which looks like this: >=20 > IPv4 header (src=3DV4CoA, dst=3DV4HA) > UDP header (src=3DDSMIPv6-PORT, dst=3DDSMIPv6-PORT) > IPv6 header (src=3DV6HoA, dst=3DV6HA) > Destination Options header > Home Address option (V6HoA) > ESP header (transport mode) > Mobility header > Binding Update > IPv4 Care-of Address option (V4CoA) >=20 > 8. The HA receives a Binding Update=20 >=20 > IPv4 header (src=3DNATTED_V4CoA, dst=3DV4HA) > UDP header (src=3DNATTED_DSMIPv6-PORT, dst=3DDSMIPv6-PORT) > IPv6 header (src=3DV6HoA, dst=3DV6HA) > Destination Options header > Home Address option (V6HoA) > ESP header (transport mode) > Mobility header > Binding Update > IPv4 Care-of Address option (V4CoA) >=20 > 9. The HA determines whether UDP encapsulation is used > (if the MN requested it, or local policy requires it, or > NATTED_V4CoA and V4CoA do not match). >=20 > 10. The HA updates its local DSMIPv6 tunnel: > local address =3D V4HA:DSMIPv6-PORT > remote address =3D NATTED_V4CoA:NATTED-DSMIPv6-PORT > encapsulation =3D "UDP for all traffic"/"UDP for ESP-V6HoA-V6HA = only" >=20 > 11. The HA updates its binding cache so that traffic to V6HoA=20 > and V4HoA > is sent over the DSMIPv6 tunnel. >=20 > 12. If the HA supports "K" flag, it updates its IKE_SA as follows: > local address =3D V4HA:4500 > remote address =3D NATTED_V4CoA:4500=20 > NAT traversal =3D yes/no > (NOTE: remote port number is wrong if doing NAT-T; this > will be updated below) >=20 > 13. The HA updates its *tunnel* mode IPsec SAD entries with MN: > local tunnel header address =3D V4HA:4500 > remote tunnel header address =3D NATTED_V4CoA:4500 > UDP encapsulation =3D yes/no > (NOTE: remote port number is wrong if doing NAT-T; this > will be updated below) >=20 As Karen pointed out, I don't think it can be assumed that the NAT-ed IP address remains the same and just the port number is going to be different for IKE usage. So, I think both need to be updated from the actual IKE exchange that occurs (more comments on that under step 18 below).=20 > 14. The HA may also need to update information in its SPD=20 > (similarly as MN in step 6). >=20 > 15. HA replies with a Binding Acknowledgement. >=20 > IPv4 header (src=3DV4HA, dst=3DNATTED_V4CoA) > UDP header (src=3DDSMIPv6-PORT, dst=3DNATTED_DSMIPv6-PORT) > IPv6 header (src=3DV6HA, dst=3DV6HoA) > Routing header (type 2): V6HoA > ESP header (transport mode) > Mobility header > Binding Acknowledgement > [NAT detection option] >=20 > 16. MN updates the DSMIPv6 tunnel depending on the NAT=20 > detection option: > encapsulation =3D "UDP for all traffic"/"UDP for ESP-V6HoA-V6HA = only" >=20 > 17. The MN updates IKE/IPsec state as follows: >=20 > - "K" flag not set:=20 > - negotiate a new IKE_SA and new IPsec SAs replace all the=20 > existing IPsec SAs (both transport and tunnel mode),=20 > and close the old IKE_SA. >=20 > - "K" flag set, no NAT Detection option (and no MOBIKE):=20 > - update IKE_SA: NAT traversal =3D no > - update tunnel mode IPsec SAs: UDP encapsulation =3D no > =20 > - "K" flag set, NAT Detection option (and no MOBIKE): > - update IKE_SA: NAT traversal =3D yes > - update tunnel mode IPsec SAs: UDP encapsulation =3D no >=20 > 18. If the MN sent an empty Informational request, the HA will =20 > update its IKE_SA as follows: > remote_address =3D NATTED_V4CoA:NATTED_PORT_4500 > =20 > and tunnel mode IPsec SAD entries as follows: > remote_address =3D V4CoA:NATTED_PORT_4500 > =20 IKEv2 allows the change of remote address of the initiator using any IKE exchange (like the empty informational one mentioned above) only if NAT-T was detected during the initial IKE exchange (section 2.23 in RFC4306). For this, the NAT detection payloads must have been included in the IKE_SA_INIT message and a mismatch in IP address between that and the actual IP source/destination address must have been detected. If the IKE SA was established when the MN was in a non-NATed v4 or v6 network, then, the MN needs to re-do the full IKE exchange when it moves to a NAT-ed IPv4 network (I don't believe there is a way around this, since IKEv2 was written for static nodes). =20 I believe the above method uses a shortcut (more hacks to MIP6-IKEv2 interactions, but, who's counting :)) to this and that needs more clarification in the document. For instance, in steps 4, 5, 12, and 13, it appears that the goal is to have the MN and HA locally put the IKE SA in a state as though it was created in the presence of NATs to begin with. In essence, based on detection of NATs by DSMIP6, the IKE SA is updated as though it got created with NATs. I have to think about the implications of this some more; it may be okay to do that. =20 However, in the above case, the IKE Informational exchange MUST be sequentially done, after the BU/BA exchange has occurred. This is because the IKE SA state must be updated to indicated NAT-T (based on the BU/BA) before IP addresses in the SAs can be changed using step 18. This should be clearly stated as such.=20 If the above shortcut is not taken, step 18 will be different for different cases here:=20 A) If the MN is moving from IPv6 or non-NAT-ed IPv4 network into a NAT-ed IPv4 network, the MN must re-do the IKE exchange to allow NAT detection=20 B) If the MN is moving from a NAT-ed IPv4 network into another NAT-ed IPv4 network, it can simply use the empty informational exchange mentioned above.=20 So, in conclusion, you either have sequential BU/BA followed by a 1-RT IKE exchange (any IKE message exchange will work here) or a parallel BU/BA and 2-RT full IKE exchange to pull this off. =20 Vidya > 19. MN sends Binding Updates to delete bindings with all=20 > Correspondent Nodes that were using route optimization.=20 >=20 > 20. Done >=20 > The above steps would basically apply to a move from IPv4 to=20 > IPv4 as well. >=20 > Solution 2, IPv4 only network -> IPv6 network=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 1. The MN updates its DSMIPv6 tunnel as follows: > local address =3D V6CoA > remote address =3D V4HA > encapsulation =3D "straight IPv4/6-in-IPv6" >=20 > 2. The MN updates its local binding/routing/something table=20 > to tunnel all traffic *from* V6HoA/V4HoA over the DSMIPv6 tunnel > (note: "from" here means IP header source address, not including > e.g. Home Address option) >=20 > 3. The MN updates its IKE_SA with the home agent as follows:=20 > local address =3D V6CoA:4500 > remote address =3D V6HA:4500 > NAT traversal =3D no >=20 > 4. The MN updates its *tunnel* mode IPsec SAD entries with=20 > the home agent as follows: > local tunnel header address =3D V6CoA > remote tunnel header address =3D V6HA > UDP encapsulation =3D no >=20 > 5. The MN may also need to update information in its SPD, so > that any new SAs get created with these tunnel header addresses. > (This depends a bit on how IKE determines the correct peer > when SA creation is needed.) > =20 > 6. The MN sends a Binding Update, which looks like this: >=20 > IPv6 header (src=3DV6CoA, dst=3DV6HA) > Destination Options header > Home Address option (V6HoA) > ESP header (transport mode) > Mobility header > Binding Update > Alternate Care-of Address option (V6Coa) >=20 > 7. The HA updates its local DSMIPv6 tunnel: > local address =3D V6HA > remote address =3D V6CoA > encapsulation =3D "straight IPv4/6-in-IPv6" >=20 > 8. The HA updates its binding cache so that traffic to V6HoA=20 > and V4HoA is sent over the DSMIPv6 tunnel. >=20 > 9. If the HA supports "K" flag, it updates its IKE_SA as follows: > local address =3D V6HA:4500 > remote address =3D V6CoA:4500=20 > NAT traversal =3D no >=20 > 10. The HA updates its *tunnel* mode IPsec SAD entries with MN: > local tunnel header address =3D V6HA:4500 > remote tunnel header address =3D V6CoA:4500 > UDP encapsulation =3D no >=20 > 11. The HA may also need to update information in its SPD=20 > (similarly as MN in step 6). >=20 > 12. HA replies with a Binding Acknowledgement. >=20 > IPv6 header (src=3DV6HA, dst=3DV6CoA) > Routing header (type 2): V6HoA > ESP header (transport mode) > Mobility header > Binding Acknowledgement >=20 > 13. The MN updates IKE/IPsec state as follows: >=20 > - "K" flag not set:=20 > - negotiate a new IKE_SA and new IPsec SAs replace all the=20 > existing IPsec SAs (both transport and tunnel mode),=20 > and close the old IKE_SA. >=20 > - "K" flag set: > - nothing needs to be done >=20 > 14. MN could send Binding Updates to update bindings with > Corrrespondent Nodes for route optimization.=20 >=20 > 15. Done >=20 >=20 > Hesham >=20 >=20 >=20 From MarajohansenPereira@concern.net Fri Nov 16 02:31:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsvfN-0001q1-KB; Fri, 16 Nov 2007 02:31:05 -0500 Received: from pool-71-242-211-16.phlapa.east.verizon.net ([71.242.211.16] helo=dhtmnt71.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsvfN-0002pl-4f; Fri, 16 Nov 2007 02:31:05 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host63812907.concern.net (8.13.1/8.13.1) with SMTP id WAMKxwvA30.577282.cNR.8KA.2136052481874 for ; Fri, 16 Nov 2007 02:43:37 +0500 Message-ID: <621c601c82824$76304df0$2f01a8c0@DHTMNT71> From: "Hester Valentin" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_621C2_01C82824.76304DF0-- From MarvinbivariateGibson@metacritic.com Fri Nov 16 03:59:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isx2u-0003AR-6v; Fri, 16 Nov 2007 03:59:28 -0500 Received: from bzq-84-108-117-60.cablep.bezeqint.net ([84.108.117.60] helo=eli) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Isx2t-00083w-Ga; Fri, 16 Nov 2007 03:59:28 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host52730517.metacritic.com (8.13.1/8.13.1) with SMTP id GdUvdXwd48.867908.ZVS.Qop.5644543828736 for ; Fri, 16 Nov 2007 11:00:53 -0200 Message-ID: <14041b01c8282f$463a77f0$3c756c54@Eli> From: "Glenn Graham" To: Subject: Your order approved Date: Fri, 16 Nov 2007 11:00:53 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_140417_01C8282F.463A77F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_140417_01C8282F.463A77F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_140417_01C8282F.463A77F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_140417_01C8282F.463A77F0-- From Elbert@monakimprojects.com Fri Nov 16 05:47:52 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isyjo-000454-Sq for nemo-archive@lists.ietf.org; Fri, 16 Nov 2007 05:47:52 -0500 Received: from [210.4.14.194] (helo=[210.4.14.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isyjn-0006SR-R4 for nemo-archive@lists.ietf.org; Fri, 16 Nov 2007 05:47:52 -0500 Received: by 10.230.125.65 with SMTP id AVTiXSVJGlTLo; Fri, 16 Nov 2007 18:59:21 -0800 (GMT) Received: by 192.168.147.219 with SMTP id fsMWrxGAArYLta.5274651394307; Fri, 16 Nov 2007 18:59:19 -0800 (GMT) Message-ID: <000d01c828c5$d7668e30$c20e04d2@pc2> From: "Guang Elbert" To: Subject: tamperer Date: Fri, 16 Nov 2007 18:59:16 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C82882.C9434E30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0008_01C82882.C9434E30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is my secret to my new life.. Freeman gilmore http://www.baanbaa.com/ ------=_NextPart_000_0008_01C82882.C9434E30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This is my secret to my new = life..
Freeman gilmore
http://www.baanbaa.com/
= ------=_NextPart_000_0008_01C82882.C9434E30-- From carimEnola@devlij.nl Fri Nov 16 10:20:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2zq-0004pp-Fg for nemo-archive@lists.ietf.org; Fri, 16 Nov 2007 10:20:42 -0500 Received: from astdenis-105-1-27-223.w81-248.abo.wanadoo.fr ([81.248.253.223] helo=AStDenis-105-1-82-232.w80-8.abo.wanadoo.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It2zp-0000Qt-JF for nemo-archive@lists.ietf.org; Fri, 16 Nov 2007 10:20:42 -0500 Received: from richard-6e55e8a ([109.101.130.47]:28242 "EHLO richard-6e55e8a" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by AStDenis-105-1-82-232.w80-8.abo.wanadoo.fr with ESMTP id S22UKIMLUKBLAWXS (ORCPT ); Fri, 16 Nov 2007 19:21:07 +0300 Message-ID: <000601c8286c$a07b18e0$e8d80850@richard6e55e8a> From: "carim Enola" To: Subject: seratrat Date: Fri, 16 Nov 2007 19:20:39 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C82885.C5C850E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0003_01C82885.C5C850E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable life is short, dont have a small cock all your life ahed ghghgh http://www.baidna.com/ ------=_NextPart_000_0003_01C82885.C5C850E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
life is short, dont have a small cock all your = life
ahed ghghgh
http://www.baidna.com/
------=_NextPart_000_0003_01C82885.C5C850E0-- From mext-bounces@ietf.org Fri Nov 16 11:36: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 1It4Au-0005ZU-4s; Fri, 16 Nov 2007 11:36:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4As-0005ZJ-C1 for mext@ietf.org; Fri, 16 Nov 2007 11:36:10 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1It4Ar-0000Ua-TU for mext@ietf.org; Fri, 16 Nov 2007 11:36:10 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1195230968!2974078!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 30288 invoked from network); 16 Nov 2007 16:36:08 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-7.tower-128.messagelabs.com with SMTP; 16 Nov 2007 16:36:08 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lAGGa6h0007323; Fri, 16 Nov 2007 09:36:08 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lAGGa5qK016988; Fri, 16 Nov 2007 10:36:05 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id lAGGa3OH016965; Fri, 16 Nov 2007 10:36:03 -0600 (CST) Message-ID: <473DC6F2.9060509@gmail.com> Date: Fri, 16 Nov 2007 17:36:02 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Romain KUNTZ References: <483735.10786.qm@web84112.mail.mud.yahoo.com> <470167CD.8020601@gmail.com> <8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr> In-Reply-To: <8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071115-0, 15/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: mext@ietf.org Subject: [MEXT] Re: [nemo] Prefix Delegation documents 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 [NEMO topic Cc'ed on MEXT and not NEMO - hoping to correspond ok] Romain KUNTZ wrote: > Hi Alex, > > On 2007/10/01, at 23:34, Alexandru Petrescu wrote: >> Behcet Sarikaya wrote: >>> I agree with Alex. DHAAD extension proposed in NEMO DHCP PD draft >>> is I think a stretch and may probably be not needed. >> >> Err? Sorry, I'm happy you agree with me, but I think the NEMO DHCP >> PD draft doesn't propose DHAAD extensions...(?) > > And I agree with Behcet that this may not be useful, as the MIP6 > bootstrapping work does not rely on DHAAD to assign HA addresses. I see it differently. I see it as the MIP6 bootstrapping work _should_ rely on DHAAD to assign the HA address. (I've always wondered how could the MIP6 bootstrapping work simply ignore the existence of DHAAD.) > draft-ietf-nemo-dhcpv6-pd-02 adds a new D flag to DHAAD in section > 3.5. Right... just read it. I think DHCPv6PD for NEMO uses DHAAD extensions (D bit) to obtain the address of the DHCPv6PD Server HA (the Delegating Router DR). I think this is a possible means to learn the DR address. And another one is to multicast the DHCPv6 Solicit over the MR-HA tunnel interface and for the receiving HA to multicast it further on the home link and only the right DR will reply to it. I think this can work too and it may involve less modifications on software (no message extension). What do others think - will this work? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From CaraalpineMarcum@closer.com Fri Nov 16 15:54:08 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It8CW-0001Dn-Pk; Fri, 16 Nov 2007 15:54:08 -0500 Received: from [85.98.146.128] (helo=sega020) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1It8CW-0000d2-7I; Fri, 16 Nov 2007 15:54:08 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host19452702.closer.com (8.13.1/8.13.1) with SMTP id WLpiKULU95.948101.uMb.WLj.4595731993426 for ; Fri, 16 Nov 2007 22:53:47 -0200 Message-ID: <9eb301c82892$df4e5c50$2300a8c0@sega020> From: "Lenora Marcum" To: Subject: Your family Date: Fri, 16 Nov 2007 22:53:47 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_9EAF_01C82892.DF4E5C50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_9EAF_01C82892.DF4E5C50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_9EAF_01C82892.DF4E5C50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_9EAF_01C82892.DF4E5C50-- From rectorsrxz@aucaza.com.mx Sun Nov 18 02:54:02 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iteyg-0004k7-Ju for nemo-archive@lists.ietf.org; Sun, 18 Nov 2007 02:54:02 -0500 Received: from host170-238-static.61-82-b.business.telecomitalia.it ([82.61.238.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iteyf-00008S-Nk for nemo-archive@lists.ietf.org; Sun, 18 Nov 2007 02:54:02 -0500 Received: from SIMONE-PC by aucaza.com.mx with ASMTP id A40934C3 for ; Sun, 18 Nov 2007 08:47:41 +0100 Received: from SIMONE-PC ([128.121.22.179]) by aucaza.com.mx with ESMTP id 496A58179E78 for ; Sun, 18 Nov 2007 08:47:41 +0100 Message-ID: <000601c829b7$4025c430$aaee3d52@SIMONEPC> From: "Sam rector" To: Subject: |likneh{ Date: Sun, 18 Nov 2007 08:47:21 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C829BF.A1EA2C30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.3 (++++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0008_01C829BF.A1EA2C30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Increased sexual stamina - Go for longer, stronger and YOU decide when = you ejaculate Ginger mickael http://celebryx.com/ ------=_NextPart_000_0008_01C829BF.A1EA2C30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Increased sexual stamina - Go for longer, = stronger and=20 YOU decide when you ejaculate
Ginger mickael
http://celebryx.com/
------=_NextPart_000_0008_01C829BF.A1EA2C30-- From nelsonolin1@650dialup.com Sun Nov 18 10:26:14 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itm2I-0000Wf-Ah for nemo-archive@lists.ietf.org; Sun, 18 Nov 2007 10:26:14 -0500 Received: from pas75-2-87-91-90-152.dsl.club-internet.fr ([87.91.90.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Itm2F-0002Qw-At for nemo-archive@lists.ietf.org; Sun, 18 Nov 2007 10:26:12 -0500 Received: from [87.91.90.152] by gtwqceg.650dialup.com; Sun, 18 Nov 2007 15:25:52 +0000 Message-ID: <000a01c829f7$0780f8ac$bbac1a8f@itxsblx> From: "jock narendra" To: "Chester Mcgowan" Subject: You can be sure Date: Sun, 18 Nov 2007 13:38:29 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C829F7.077C0966" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C829F7.077C0966 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Replica Rolex Watches and More…Great Products, Great Prices!=20 http://prereeraplay.net/ ------=_NextPart_000_0007_01C829F7.077C0966 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Replica Rolex Watches and More…Great Products, Great Prices! =

http://prereeraplay.net/ ------=_NextPart_000_0007_01C829F7.077C0966-- From nemo-bounces@ietf.org Sun Nov 18 21:01:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItvxO-0001Jb-Vh; Sun, 18 Nov 2007 21:01:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItvxL-0001Bl-WE; Sun, 18 Nov 2007 21:01:48 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItvxH-0000Ay-Pf; Sun, 18 Nov 2007 21:01:47 -0500 Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Nov 2007 18:01:40 -0800 Message-ID: <4740EE81.4020402@azairenet.com> Date: Sun, 18 Nov 2007 18:01:37 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [nemo] Resolution of IKEv2 and DSMIPv6 issue References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Nov 2007 02:01:41.0030 (UTC) FILETIME=[20744460:01C82A50] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: nemo@ietf.org, mip6@ietf.org, Pasi.Eronen@nokia.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, This looks good, So what are we going to add to the draft? Just mention that transport mode ESP SA MUST be negotiated for sending a Binding Update? Or are we planning to add all the details below (that Pasi sent) to the draft? I would prefer the former. A couple of minor comments on packet formats below. Hesham Soliman wrote: > 7. The MN sends a Binding Update, which looks like this: > > IPv4 header (src=V4CoA, dst=V4HA) > UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT) > IPv6 header (src=V6HoA, dst=V6HA) > Destination Options header > Home Address option (V6HoA) > ESP header (transport mode) > Mobility header > Binding Update > IPv4 Care-of Address option (V4CoA) The destination options header would not be present in this BU, since the home address is already present in the IPv6 header itself. > 15. HA replies with a Binding Acknowledgement. > > IPv4 header (src=V4HA, dst=NATTED_V4CoA) > UDP header (src=DSMIPv6-PORT, dst=NATTED_DSMIPv6-PORT) > IPv6 header (src=V6HA, dst=V6HoA) > Routing header (type 2): V6HoA > ESP header (transport mode) > Mobility header > Binding Acknowledgement > [NAT detection option] The routing header should not be present in this binding ack, since the binding ack is already destined to the IPv6 home address. Vijay From nemo-bounces@ietf.org Sun Nov 18 21:25:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItwKN-000285-Bk; Sun, 18 Nov 2007 21:25:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItwKM-00027L-0p; Sun, 18 Nov 2007 21:25:34 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItwKL-0006TF-6i; Sun, 18 Nov 2007 21:25:33 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id lAJ2PTjv004331; Mon, 19 Nov 2007 11:25:29 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id lAJ2PTb06891; Mon, 19 Nov 2007 11:25:29 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with ESMTP id lAJ2PS805358; Mon, 19 Nov 2007 11:25:28 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 10:25:21 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id 79A59D40B3; Mon, 19 Nov 2007 10:40:35 +0800 (SGT) From: Chan-Wah Ng To: IETF NEMO WG , mext@ietf.org Content-Type: multipart/mixed; boundary="=-iOfj9+CfRGnDDWpAJpvV" Date: Mon, 19 Nov 2007 10:40:34 +0800 Message-Id: <1195440034.2124.8.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-OriginalArrivalTime: 19 Nov 2007 02:25:21.0197 (UTC) FILETIME=[6EF08DD0:01C82A53] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Subject: [nemo] [Fwd: I-D Action:draft-ng-nemo-ce-req-01.txt] X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org --=-iOfj9+CfRGnDDWpAJpvV Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello all, We have updated the NEMO Consumer Electronics Requirements draft. I am also happy to say that three more authors have joined in this effort. As a result, you will find this update a better quality read, with more usage scenarios (complete with figures) and the requirements are more clearly stipulated and separated from desired features. As always, comments and suggestions are welcomed. /rgds /cwng -------- Forwarded Message -------- From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ng-nemo-ce-req-01.txt Date: Sat, 17 Nov 2007 21:00:02 -0500 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Consumer Electronics Requirements for Network Mobility Route Optimization Author(s) : C. Ng, et al. Filename : draft-ng-nemo-ce-req-01.txt Pages : 15 Date : 2007-11-17 This document illustrates different deployments of Network Mobility (NEMO) from the consumer electronics perspective. From these deployments, a set of requirements is deduced for Route Optimization (RO) with NEMO. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ng-nemo-ce-req-01.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-ng-nemo-ce-req-01.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-ng-nemo-ce-req-01.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. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --=-iOfj9+CfRGnDDWpAJpvV Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwyMDA3LTExLTE3MjA1MzQzLkkt REBpZXRmLm9yZz4KCkVOQ09ESU5HIG1pbWUKRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW5n LW5lbW8tY2UtcmVxLTAxLnR4dAo= --=-iOfj9+CfRGnDDWpAJpvV Content-Type: Message/External-body; name="draft-ng-nemo-ce-req-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwyMDA3LTExLTE3MjA1MzQzLkkt RFxAaWV0Zi5vcmc+Cgo= --=-iOfj9+CfRGnDDWpAJpvV-- From mext-bounces@ietf.org Sun Nov 18 21:25:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItwKN-00028R-Lq; Sun, 18 Nov 2007 21:25:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItwKM-00027L-0p; Sun, 18 Nov 2007 21:25:34 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItwKL-0006TF-6i; Sun, 18 Nov 2007 21:25:33 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id lAJ2PTjv004331; Mon, 19 Nov 2007 11:25:29 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id lAJ2PTb06891; Mon, 19 Nov 2007 11:25:29 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with ESMTP id lAJ2PS805358; Mon, 19 Nov 2007 11:25:28 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 10:25:21 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id 79A59D40B3; Mon, 19 Nov 2007 10:40:35 +0800 (SGT) From: Chan-Wah Ng To: IETF NEMO WG , mext@ietf.org Content-Type: multipart/mixed; boundary="=-iOfj9+CfRGnDDWpAJpvV" Date: Mon, 19 Nov 2007 10:40:34 +0800 Message-Id: <1195440034.2124.8.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-OriginalArrivalTime: 19 Nov 2007 02:25:21.0197 (UTC) FILETIME=[6EF08DD0:01C82A53] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Subject: [MEXT] [Fwd: I-D Action:draft-ng-nemo-ce-req-01.txt] 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 --=-iOfj9+CfRGnDDWpAJpvV Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello all, We have updated the NEMO Consumer Electronics Requirements draft. I am also happy to say that three more authors have joined in this effort. As a result, you will find this update a better quality read, with more usage scenarios (complete with figures) and the requirements are more clearly stipulated and separated from desired features. As always, comments and suggestions are welcomed. /rgds /cwng -------- Forwarded Message -------- From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ng-nemo-ce-req-01.txt Date: Sat, 17 Nov 2007 21:00:02 -0500 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Consumer Electronics Requirements for Network Mobility Route Optimization Author(s) : C. Ng, et al. Filename : draft-ng-nemo-ce-req-01.txt Pages : 15 Date : 2007-11-17 This document illustrates different deployments of Network Mobility (NEMO) from the consumer electronics perspective. From these deployments, a set of requirements is deduced for Route Optimization (RO) with NEMO. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ng-nemo-ce-req-01.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-ng-nemo-ce-req-01.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-ng-nemo-ce-req-01.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. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --=-iOfj9+CfRGnDDWpAJpvV Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwyMDA3LTExLTE3MjA1MzQzLkkt REBpZXRmLm9yZz4KCkVOQ09ESU5HIG1pbWUKRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW5n LW5lbW8tY2UtcmVxLTAxLnR4dAo= --=-iOfj9+CfRGnDDWpAJpvV Content-Type: Message/External-body; name="draft-ng-nemo-ce-req-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwyMDA3LTExLTE3MjA1MzQzLkkt RFxAaWV0Zi5vcmc+Cgo= --=-iOfj9+CfRGnDDWpAJpvV 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 --=-iOfj9+CfRGnDDWpAJpvV-- From nemo-bounces@ietf.org Mon Nov 19 03:35: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 1Iu262-0003tv-FP; Mon, 19 Nov 2007 03:35:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu261-0003tT-Cp; Mon, 19 Nov 2007 03:35:09 -0500 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu25z-0005JA-J8; Mon, 19 Nov 2007 03:35:08 -0500 Received: from oaamta06ps.mx.bigpond.com ([124.190.106.219]) by omta01ps.mx.bigpond.com with ESMTP id <20071119083503.UGZN16290.omta01ps.mx.bigpond.com@oaamta06ps.mx.bigpond.com>; Mon, 19 Nov 2007 08:35:03 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta06ps.mx.bigpond.com with ESMTP id <20071119083503.CMJV27263.oaamta06ps.mx.bigpond.com@PC20005>; Mon, 19 Nov 2007 08:35:03 +0000 From: "Hesham Soliman" To: , Subject: RE: [nemo] Resolution of IKEv2 and DSMIPv6 issue Date: Mon, 19 Nov 2007 19:34:49 +1000 Message-ID: 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.3198 In-Reply-To: Thread-Index: AcgqUCx55WT8Kvc1S4mZDZtQzj8E9gAMaVDwAANgK2A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I completely agree with Pasi. There is no way we can just say "MUST use transport mode". We need to clearly explain the process. Hesham > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Monday, November 19, 2007 6:04 PM > To: vijay.devarapalli@AzaireNet.com; Hesham@elevatemobile.com > Cc: mip6@ietf.org; nemo@ietf.org > Subject: RE: [nemo] Resolution of IKEv2 and DSMIPv6 issue > > > I think the discussion so far has shown that "MUST use > transport mode for BU" isn't sufficient -- based on > that information only, the reader can't really figure > out how this works (or might arrive at quite different > solution). > > Perhaps not all the details aren't necessary, but > as the interaction of local state updates for DSMIPv6, > local state updates for IPsec, (DS)MIPv6 messages, > and IPsec messages it a bit complex, explaining > what happens (and in what order it has to happen) > would be IMHO helpful. > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Vijay Devarapalli > [mailto:vijay.devarapalli@AzaireNet.com] > > Sent: 19 November, 2007 04:02 > > To: Hesham Soliman > > Cc: mip6@ietf.org; nemo@ietf.org; Eronen Pasi (Nokia-NRC/Helsinki) > > Subject: Re: [nemo] Resolution of IKEv2 and DSMIPv6 issue > > > > Hi, > > > > This looks good, So what are we going to add to the draft? > > Just mention that transport mode ESP SA MUST be negotiated > > for sending a Binding Update? Or are we planning to add all > > the details below (that Pasi sent) to the draft? I would > > prefer the former. > > > > A couple of minor comments on packet formats below. > > > > Hesham Soliman wrote: > > > > > 7. The MN sends a Binding Update, which looks like this: > > > > > > IPv4 header (src=V4CoA, dst=V4HA) > > > UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT) > > > IPv6 header (src=V6HoA, dst=V6HA) > > > Destination Options header > > > Home Address option (V6HoA) > > > ESP header (transport mode) > > > Mobility header > > > Binding Update > > > IPv4 Care-of Address option (V4CoA) > > > > The destination options header would not be present in this BU, > > since the home address is already present in the IPv6 header > > itself. > > > > > 15. HA replies with a Binding Acknowledgement. > > > > > > IPv4 header (src=V4HA, dst=NATTED_V4CoA) > > > UDP header (src=DSMIPv6-PORT, dst=NATTED_DSMIPv6-PORT) > > > IPv6 header (src=V6HA, dst=V6HoA) > > > Routing header (type 2): V6HoA > > > ESP header (transport mode) > > > Mobility header > > > Binding Acknowledgement > > > [NAT detection option] > > > > The routing header should not be present in this binding ack, > > since the binding ack is already destined to the IPv6 home > > address. > > > > Vijay > > > From nemo-bounces@ietf.org Mon Nov 19 03:38: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 1Iu295-0006gl-4B; Mon, 19 Nov 2007 03:38:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu293-0006ej-Q9; Mon, 19 Nov 2007 03:38:17 -0500 Received: from ws000774.tietoenator.com ([193.12.181.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu293-0005Vy-DT; Mon, 19 Nov 2007 03:38:17 -0500 X-AuditID: c10cb581-000025c000000fb0-3b-47414b76575b Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 09:38:14 +0100 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 09:38:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Re: [nemo] Resolution of IKEv2 and DSMIPv6 issue Date: Mon, 19 Nov 2007 09:38:10 +0100 Message-ID: In-Reply-To: <4740EE81.4020402@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Re: [nemo] Resolution of IKEv2 and DSMIPv6 issue Thread-Index: AcgqUDDWggKB3XbESNy3EZ1ND52YaQANM4Rw References: <4740EE81.4020402@azairenet.com> From: To: , X-OriginalArrivalTime: 19 Nov 2007 08:38:15.0413 (UTC) FILETIME=[8702FA50:01C82A87] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: nemo@ietf.org, mip6@ietf.org, Pasi.Eronen@nokia.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > Hi, >=20 > This looks good, So what are we going to add to the draft? > Just mention that transport mode ESP SA MUST be negotiated > for sending a Binding Update? Or are we planning to add all > the details below (that Pasi sent) to the draft? I would > prefer the former. >=20 In my opinion it is important to specify the updating of the IKE_SA, the IPSEC-SAs, and potentially the IPSEc SPs that needs to be performed on the basis of DSMIP signaling at the MN and at the HA respectively. AS WELL AS how the address and the port information, that is the (v4port4500NAT_address, NATTED-4500), is inserted into these by subsequent IKE operation. =20 Something else, considering the situation IPv6 network -> IPv4 only network (but similarly for the other situations), then I should have thought that step 1 to step 6 should not be done at the MN until after it have received the BACK form the HA, that is, not until after step 15. Thereby if the BACK is negative, it need not "roll back", assuming that the old network attachment=20 still works. Or is this wrong ? BR, Karen From nemo-bounces@ietf.org Mon Nov 19 04:08: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 1Iu2cH-0006iA-Oo; Mon, 19 Nov 2007 04:08:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2cG-0006hk-33; Mon, 19 Nov 2007 04:08:28 -0500 Received: from mail1.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu2cF-0000EJ-K8; Mon, 19 Nov 2007 04:08:27 -0500 X-AuditID: c26e2f18-0000079000000940-07-4741527828c3 Received: from camaro.eu.tieto.com ([192.176.143.43]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 11:08:08 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 10:08:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Re: [nemo] Resolution of IKEv2 and DSMIPv6 issue Date: Mon, 19 Nov 2007 10:08:24 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Re: [nemo] Resolution of IKEv2 and DSMIPv6 issue Thread-Index: AcgqUDDWggKB3XbESNy3EZ1ND52YaQANM4RwAADdY5AAAIGScA== References: <4740EE81.4020402@azairenet.com> From: To: , , X-OriginalArrivalTime: 19 Nov 2007 09:08:25.0550 (UTC) FILETIME=[BDEFF6E0:01C82A8B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org =20 >=20 > > Something else, considering the situation IPv6 network -> IPv4 only > > network (but similarly for the other situations), then I should have > > thought that step 1 to step 6 should not be done at the MN until > > after it have received the BACK form the HA, that is, not until > > after step 15. > >=20 > > Thereby if the BACK is negative, it need not "roll back", assuming > > that the old network attachment still works. Or is this wrong ? >=20 > Steps 1/2 are required so that the BU actually gets sent > correctly (without requiring modifications to IPsec). >=20 Ok, I can accept 1/2 before sending BU, at least conceptually. I think that it is a little implementation dependent, however, whether the DSMIP tunnel is set up before or after the receipt of the BACK. I agree, of course, that the BU/BACK are sent/received with the tunnel headers, but payload MUST NOT be accepted through or from this tunnel before after the receipt of the BACK (in my opinion). Where IPSec comes into this, I cannot see.=20 I wouldn't expect IPSec to have anything to do with the tunnel headers headers for the BU/BACK. Karen > (If the old network attachment still works, the IPsec stack=20 > would see just a packet destined to V6HA, and send it via the=20 > old network attachment.) >=20 > Best regards, > Pasi >=20 From mext-bounces@ietf.org Mon Nov 19 05:06:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu3Vv-0006Rr-HX; Mon, 19 Nov 2007 05:05:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu3Vu-0006Pn-IG for mext@ietf.org; Mon, 19 Nov 2007 05:05:58 -0500 Received: from rv-out-0910.google.com ([209.85.198.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu3Vr-0007Ge-0W for mext@ietf.org; Mon, 19 Nov 2007 05:05:58 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1234773rvb for ; Mon, 19 Nov 2007 02:05:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=BMcpABgksm/TJ2fVzldHn82LJ2X4UNiwrWZbSZqKZLw=; b=aWcdBmh6a9WIxbqQUWJEsEgWRFkTpQyaH2B3OR+v6/VuR0u+jCo9aj0fWgu1bRF586/brAWx+i8jBo0bQUSBJ1Jex5pe7GnPXOY5b26w6z6cOZoGt6W0mJ8ctSy9/t4VrymOhGEYd+6O5kgGesBEXSggXAYUqh7RWOARcWlEhvY= 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=uI3f5uR1B9qOnN45u6ei4umb0HH5ncmu/0gS6ZCrKDrI8UAU7+kxW3XAlGRdIjD4jnLwTyLkFAXYZJtzeGrYGPHYAW0Z77NvRt+ntFV1lSWH6Zw0Dsir5kBOp29pAWOyM+gzPe3Zw8JqSnukwgoaaM6ERFjexn8eMJoYUzXQXfs= Received: by 10.140.179.25 with SMTP id b25mr1576347rvf.1195466749943; Mon, 19 Nov 2007 02:05:49 -0800 (PST) Received: by 10.140.177.17 with HTTP; Mon, 19 Nov 2007 02:05:49 -0800 (PST) Message-ID: <1d38a3350711190205u7d9f541dqf76e5bd9ee490906@mail.gmail.com> Date: Mon, 19 Nov 2007 18:05:49 +0800 From: "Hui Deng" To: mext@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [MEXT] Call for paper: IEEE ICC 2008 Workshop on IP Mobility Management and Architecture 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 We are sorry if you received multiple copies of this. IPMMA 2008 2008 Workshop on IP Mobility Management and Architecture May 19/23, 2008, Beijing, China (To be held with IEEE ICC 2008, May 19-23, 2008) Sponsored by China Mobile Webpage: http://www.ieee-icc.org/2008/ Webpage: http://www.mobilehub.com.cn/yjy/ieee/index.htm Important Dates: Submission Deadline: Dec. 20, 2007 Acceptance notification: Jan 31 2008 Camera ready: Feb 28 2008 Program Co-Chairs Bill Huang China Mobile Ziqiang Hou Institue of Acoustics, CAS Sajal Das The Univ. Texas at Arlington Program Committees: Thierry Ernst INRIA Wing C. Lau The Chinese Univ. of Hong Kong Bing Wei China Mobile Min Liu Institute of Computing Technology, CAS Ying Qiu Institute for Infocomm Research Ryuji Wakikawa KEIO University Peng Yang Hitachi Yong Cui Tsinghua University Xiaobing Guo Lenovo Publicity Chair Hui Deng China Mobile With recently, various kinds of IP mobility management solutions have been widely adopted by many wireless communication standard bodies such as Wimax forum, 3GPP, 3GPP2 etc. Most adopted solutions are point to point connection which is similar to traditional circuit-switched architecture. Handover among heterogeneous networks with different wireless links is standardized by different incompatible mobility management technologies. Designing next generation IP mobility management and architecture on the scenarios, such as next generation wireless communication evolution, ad hoc subscriber grouping, and peer to peer Internet network architecture seems to be a timely request and will influence all kinds of operator's network architectures. Many technologies are under development. "IP mobility management and architecture" welcomes original submission which emphasizing the general aspects, soliciting authors to provide very high quality contributions. Topics of interest are (but not limited to): 1) IP mobility management for structured P2P network; 2) Heterogeneous network handover; 3) IP mobility management for mobile Ad hoc network; 4) Network based local mobility management; 5) Network mobility; 6) EAP based handover key management in wireless IP network; 7) Multiple interface and multi-homing in the mobility management environment. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 19 06:04: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 1Iu4QM-00029A-TQ; Mon, 19 Nov 2007 06:04:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4QK-00027P-OS for mext@ietf.org; Mon, 19 Nov 2007 06:04:16 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iu4QH-0001dl-8g for mext@ietf.org; Mon, 19 Nov 2007 06:04:16 -0500 Received: (qmail 4013 invoked for bounce); 19 Nov 2007 13:09:23 -0000 Received: from unknown (HELO ?130.79.91.222?) (kuntz@unknown) by unknown with RC4-SHA encrypted SMTP; 19 Nov 2007 13:09:23 -0000 Message-Id: <664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr> From: Romain KUNTZ To: Alexandru Petrescu In-Reply-To: <473DC6F2.9060509@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 19 Nov 2007 12:04:11 +0100 References: <483735.10786.qm@web84112.mail.mud.yahoo.com> <470167CD.8020601@gmail.com> <8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr> <473DC6F2.9060509@gmail.com> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: mext@ietf.org Subject: [MEXT] Re: [nemo] Prefix Delegation documents 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 Alex, On 2007/11/16, at 17:36, Alexandru Petrescu wrote: >> On 2007/10/01, at 23:34, Alexandru Petrescu wrote: >>> Behcet Sarikaya wrote: >>>> I agree with Alex. DHAAD extension proposed in NEMO DHCP PD draft >>>> is I think a stretch and may probably be not needed. >>> Err? Sorry, I'm happy you agree with me, but I think the NEMO DHCP >>> PD draft doesn't propose DHAAD extensions...(?) >> And I agree with Behcet that this may not be useful, as the MIP6 >> bootstrapping work does not rely on DHAAD to assign HA addresses. > > I see it differently. I see it as the MIP6 bootstrapping work > _should_ > rely on DHAAD to assign the HA address. > > (I've always wondered how could the MIP6 bootstrapping work simply > ignore the existence of DHAAD.) DHAAD relies on the fact that the home prefix is known whereas MIP6 bootstrapping does not. Using DHAAD means first retrieving the home prefix by a to-be-defined way then using DHAAD, where a DNS lookup or SRV query is a more efficient and already existing protocol. Regards, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr Louis Pasteur University - Networks and Protocols Team _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 19 06:23: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 1Iu4iN-00073C-6K; Mon, 19 Nov 2007 06:22:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4iL-0006te-70 for mext@ietf.org; Mon, 19 Nov 2007 06:22:53 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iu4iI-0002bK-TQ for mext@ietf.org; Mon, 19 Nov 2007 06:22:53 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1195471369!28576706!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 10897 invoked from network); 19 Nov 2007 11:22:50 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-5.tower-119.messagelabs.com with SMTP; 19 Nov 2007 11:22:50 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id lAJBMn4s019143; Mon, 19 Nov 2007 04:22:49 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lAJBMmmU014227; Mon, 19 Nov 2007 05:22:49 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id lAJBMk2q014210; Mon, 19 Nov 2007 05:22:47 -0600 (CST) Message-ID: <47417205.7070805@gmail.com> Date: Mon, 19 Nov 2007 12:22:45 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Romain KUNTZ References: <483735.10786.qm@web84112.mail.mud.yahoo.com> <470167CD.8020601@gmail.com> <8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr> <473DC6F2.9060509@gmail.com> <664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr> In-Reply-To: <664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071118-1, 18/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mext@ietf.org Subject: [MEXT] Re: [nemo] Prefix Delegation documents 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 Romain KUNTZ wrote: > Hi Alex, > > On 2007/11/16, at 17:36, Alexandru Petrescu wrote: >>> On 2007/10/01, at 23:34, Alexandru Petrescu wrote: >>>> Behcet Sarikaya wrote: >>>>> I agree with Alex. DHAAD extension proposed in NEMO DHCP PD draft >>>>> is I think a stretch and may probably be not needed. >>>> Err? Sorry, I'm happy you agree with me, but I think the NEMO DHCP >>>> PD draft doesn't propose DHAAD extensions...(?) >>> And I agree with Behcet that this may not be useful, as the MIP6 >>> bootstrapping work does not rely on DHAAD to assign HA addresses. >> >> I see it differently. I see it as the MIP6 bootstrapping work _should_ >> rely on DHAAD to assign the HA address. >> >> (I've always wondered how could the MIP6 bootstrapping work simply >> ignore the existence of DHAAD.) > > DHAAD relies on the fact that the home prefix is known whereas MIP6 > bootstrapping does not. But Romain, the MN always has to have some pre-configured information before being able to acquire the HA address and HoA. If MIP6 Bootstrapping pre-configures a NAI, or maybe a FQDN of the home domain - don't you think one can easily say that "MIP6 bootstrapping relies on the fact that the NAI or the FQDN is known whereas DHAAD does not" - and thus make it look as an inconvenient? > Using DHAAD means first retrieving the home prefix by a to-be-defined > way then using DHAAD, where a DNS lookup or SRV query is a more > efficient and already existing protocol. But don't you think the same can be said about the FQDN? How does MN retrieve its FQDN? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From nemo-bounces@ietf.org Mon Nov 19 07:37: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 1Iu5sl-0001OJ-Gy; Mon, 19 Nov 2007 07:37:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu5si-0001HR-PV; Mon, 19 Nov 2007 07:37:40 -0500 Received: from omta03ps.mx.bigpond.com ([144.140.82.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu5sg-0004DH-QE; Mon, 19 Nov 2007 07:37:39 -0500 Received: from oaamta05ps.mx.bigpond.com ([124.190.106.219]) by omta03ps.mx.bigpond.com with ESMTP id <20071119123735.QYHE25130.omta03ps.mx.bigpond.com@oaamta05ps.mx.bigpond.com>; Mon, 19 Nov 2007 12:37:35 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta05ps.mx.bigpond.com with ESMTP id <20071119123734.FEMH27365.oaamta05ps.mx.bigpond.com@PC20005>; Mon, 19 Nov 2007 12:37:34 +0000 From: "Hesham Soliman" To: , Date: Mon, 19 Nov 2007 23:37:20 +1000 Message-ID: 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.3198 In-Reply-To: Thread-Index: AcgqUDDWggKB3XbESNy3EZ1ND52YaQANM4RwAADdY5AAAIGScAAJoISg X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Pasi.Eronen@nokia.com Subject: [nemo] Security considerations text X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Folks, This is the current text in the draft. If there are comments we can add them to the IESG comments, provided there are no major problems here. Thanks for all the comments. Special thanks to Pasi and Karen for developing the solution. Hesham This specification allows a mobile node to send one binding update for its IPv6 and IPv4 home addresses. This is a slight deviation from [MIPv6] which requires one binding update per home address. However, like [MIPv6], the IPsec security association needed to authenticate the binding update is still based on the mobile node's IPv6 home address. Therefore, in order to authorize the mobile node's IPv4 home address binding, the home agent MUST store the IPv4 address corresponding to the IPv6 address that is allocated to a mobile node. Therefore, it is sufficient for the home agent to know that the IPsec verification for the packet containing the binding update was valid provided that it knows which IPv4 home address is associated with which IPv6 home address. Hence, the security of the IPv4 home address binding is the same as the IPv6 binding. In effect, associating the mobile node's IPv4 home address with its IPv6 home address moves the authorization of the binding update for the IPv4 address to the Mobile IPv6 implementation, which infers it from the fact that mobile node has an IPv6 home address and the right credentials for sending an authentic binding update for such address. In cases where this specification is used for NAT traversal, it is important to note that it has the same UNSAF vulnerabilities associated with RFC 3519. An attacker is able to hijack the mobile node's session with the home agent if it can modify the contents of the outer IPv4 header. The contents of the header are not authenticated and there is no way for the home agent to verify their validity. Hence, a man in the middle attack where a change in the contents of the IPv4 header can cause a legitimate mobile node's traffic to be diverted to an illegitimate receiver independently of the authenticity of the binding update message. In this specification the binding update message MUST be protected using ESP transport mode. When the mobile node is located in an IPv4- only network, the binding update message is encapsulated in UDP as described earlier. However, UDP MUST NOT be used to encapsulate the binding update message when the mobile node is located in an IPv6- enabled network. If protection of payload traffic is needed when the mobile node is located in an IPv4-only network, encapsulation is done using tunnel mode ESP over port 4500 as described in [TUNSEC]. Handovers within private IPv4 networks or from IPv6 to IPv4 networks will have impacts on the security association between the mobile node and the home agent. The following section presents the expected behaviour of the mobile node and home agent in those situations. 5.1 Handover interactions for IPsec and IKE After the mobile node detects movement it updates its tunnel information depending on the network capability. If the new link is IPv4-only then the mobile node updates its tunnel to UDP using the DSMIPv6 port and the local IPv4 address. Furthermore, the mobile node updates its local Security Association information to include its local IPv4 address and with the remote address being the home agent's IPv4 address. The mobile node also removes binding update list entries for correspondent nodes since route optimisation cannot be supported while the mobile node is in an IPv4-only network. This may cause inbound packet losses as remote correspondent node are unaware of such movement. Following this, the mobile node sends the binding update message to the home agent. Upon receiving the binding update message, the home agent updates it security association locally to include the mobile node's remote address as the IP address received in the outer header. When the mobile node is located in a private IPv4 network (which is detected as described above), this address is the public address allocated by the NAT. Based on the setting of the K flag in the binding update, the home agent updates its IKE security association to include the remote address as that received in the outer header of the binding update message. If the mobile node were located in a private IPv4 network this address is likely to be wrong as the NAT would likely allocate a different address to the IKE messages. Hence, the mobile node MUST update the IKE SA in one of two ways as follows. The mobile node SHOULD send an empty informational message, which results in the IKE module in the home agent to dynamically update the SA information. Alternatively, the IKE SA should be re-negotiated. Note that updating the IKE SA MUST take place after the mobile node has sent the binding update and received the acknowledgement from the home agent. The mobile node MAY use [MOBIKE] to update its IKE SA with the home agent. Using MOBIKE requires negotiating this capability with the home agent when establishing the SA. In this case, the mobile node and the home agent need not update their IPsec SAs locally as this step is performed by MOBIKE. Furthermore, the use of MOBIKE allows the mobile node to update the SA independently of the binding update exchange. Hence, there is no need for the mobile node to wait for a binding acknowledgement before performing MOBIKE. The use of MOBIKE is OPTIONAL in this specification. From mext-bounces@ietf.org Mon Nov 19 08:50:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu71L-0003k6-Gm; Mon, 19 Nov 2007 08:50:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu71F-0003YI-MG for mext@ietf.org; Mon, 19 Nov 2007 08:50:33 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iu71E-00005m-7Q for mext@ietf.org; Mon, 19 Nov 2007 08:50:33 -0500 Received: (qmail 6537 invoked for bounce); 19 Nov 2007 15:55:42 -0000 Received: from unknown (HELO ?130.79.91.222?) (kuntz@unknown) by unknown with RC4-SHA encrypted SMTP; 19 Nov 2007 15:55:42 -0000 Message-Id: From: Romain KUNTZ To: Alexandru Petrescu In-Reply-To: <47417205.7070805@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 19 Nov 2007 14:50:31 +0100 References: <483735.10786.qm@web84112.mail.mud.yahoo.com> <470167CD.8020601@gmail.com> <8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr> <473DC6F2.9060509@gmail.com> <664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr> <47417205.7070805@gmail.com> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mext@ietf.org Subject: [MEXT] Re: [nemo] Prefix Delegation documents 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 On 2007/11/19, at 12:22, Alexandru Petrescu wrote: >>> I see it differently. I see it as the MIP6 bootstrapping work >>> _should_ >>> rely on DHAAD to assign the HA address. >>> >>> (I've always wondered how could the MIP6 bootstrapping work simply >>> ignore the existence of DHAAD.) >> DHAAD relies on the fact that the home prefix is known whereas MIP6 >> bootstrapping does not. > > But Romain, the MN always has to have some pre-configured > information before being able to acquire the HA address and HoA. > > If MIP6 Bootstrapping pre-configures a NAI, or maybe a FQDN of the > home domain - don't you think one can easily say that "MIP6 > bootstrapping relies on the fact that the NAI or the FQDN is known > whereas DHAAD does not" - and thus make it look as an inconvenient? But from a deployment point of view, having a statically configured FQDN or just the domain name of the mobility operator is better than an IPv6 prefix, no? >> Using DHAAD means first retrieving the home prefix by a to-be- >> defined way then using DHAAD, where a DNS lookup or SRV query is a >> more efficient and already existing protocol. > > But don't you think the same can be said about the FQDN? How does > MN retrieve its FQDN? I guess the FQDN or domain name would be given to the user when it subscribes to the service. Of course you may argue that the same could apply with the IPv6 home prefix, but I think the DNS and DNS SRV is more adapted to deployments precisely because the user is not provisioned with an address. romain _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 19 09:56: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 1Iu82t-0004ay-0x; Mon, 19 Nov 2007 09:56:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu82o-0004Ch-5Q for mext@ietf.org; Mon, 19 Nov 2007 09:56:14 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iu82l-0006lB-Jh for mext@ietf.org; Mon, 19 Nov 2007 09:56:14 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-153.messagelabs.com!1195484170!5181908!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 16780 invoked from network); 19 Nov 2007 14:56:10 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-10.tower-153.messagelabs.com with SMTP; 19 Nov 2007 14:56:10 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lAJEu9P8025470; Mon, 19 Nov 2007 07:56:09 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id lAJEu8c0007135; Mon, 19 Nov 2007 08:56:09 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id lAJEu63j007087; Mon, 19 Nov 2007 08:56:07 -0600 (CST) Message-ID: <4741A405.8070106@gmail.com> Date: Mon, 19 Nov 2007 15:56:05 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Romain KUNTZ References: <483735.10786.qm@web84112.mail.mud.yahoo.com> <470167CD.8020601@gmail.com> <8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr> <473DC6F2.9060509@gmail.com> <664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr> <47417205.7070805@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071118-1, 18/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: mext@ietf.org Subject: [MEXT] Re: [nemo] Prefix Delegation documents 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 Romain KUNTZ wrote: > On 2007/11/19, at 12:22, Alexandru Petrescu wrote: >>>> I see it differently. I see it as the MIP6 bootstrapping work >>>> _should_ rely on DHAAD to assign the HA address. >>>> >>>> (I've always wondered how could the MIP6 bootstrapping work >>>> simply ignore the existence of DHAAD.) >>> DHAAD relies on the fact that the home prefix is known whereas >>> MIP6 bootstrapping does not. >> >> But Romain, the MN always has to have some pre-configured >> information before being able to acquire the HA address and HoA. >> >> If MIP6 Bootstrapping pre-configures a NAI, or maybe a FQDN of the >> home domain - don't you think one can easily say that "MIP6 >> bootstrapping relies on the fact that the NAI or the FQDN is known >> whereas DHAAD does not" - and thus make it look as an inconvenient? >> > > But from a deployment point of view, having a statically configured > FQDN or just the domain name of the mobility operator is better than > an IPv6 prefix, no? YEs, let's think from a deployment standpoint. Why do you think pre-configuring a FQDN of the domain is better than the IPv6 prefix of the home link? Is it because the operator may take advantage of DNS and inserting a different IP prefix for same FQDN in the DNS when it changed the addresses? But this does not cover the case when the operator changes its FQDN names but keeps wants to keep the same addresses. Or else - why do you think pre-configured FQDN is better from a deployment point of view? >>> Using DHAAD means first retrieving the home prefix by a >>> to-be-defined way then using DHAAD, where a DNS lookup or SRV >>> query is a more efficient and already existing protocol. >> >> But don't you think the same can be said about the FQDN? How does >> MN retrieve its FQDN? > > I guess the FQDN or domain name would be given to the user when it > subscribes to the service. Of course you may argue that the same > could apply with the IPv6 home prefix, but I think the DNS and DNS > SRV is more adapted to deployments precisely because the user is not > provisioned with an address. You say so because you assume that the operator will always keep a stable name and may sometime change its addresses if it wants to. But I think that there are operators that change names and want to keep their addresses. Orange from FT is one example probably familiar. And this latter case can not be accustomed if MIPv6 Bootstrapping pre-configures the FQDN in the MN. It can be accommodated if MIPv6 Bootstrapping pre-configures the home prefix. I also think that it's the addresses that are the rare ressources not the FQDNs. Once one gets a block of addresses one is highly interested in keeping them regardless of the changes in one's employer's name. This has many reasons rooted in deployments, the difficulty in renumbering being one of them. Alex PS: besides, there may be a mixture method relying on both FQDN+DNS and prefix+DHAAD - thus helping many more types of deployments, why not. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From nemo-bounces@ietf.org Mon Nov 19 10:50: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 1Iu8tA-0000xA-ED; Mon, 19 Nov 2007 10:50:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu8t9-0000u8-1x; Mon, 19 Nov 2007 10:50:19 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu8t8-0001jx-JP; Mon, 19 Nov 2007 10:50:18 -0500 Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Nov 2007 07:50:17 -0800 Message-ID: <4741B0B5.6080602@azairenet.com> Date: Mon, 19 Nov 2007 07:50:13 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [nemo] Resolution of IKEv2 and DSMIPv6 issue References: <4740EE81.4020402@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Nov 2007 15:50:17.0414 (UTC) FILETIME=[E1BA6E60:01C82AC3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Pasi.Eronen@nokia.com wrote: > I think the discussion so far has shown that "MUST use > transport mode for BU" isn't sufficient -- based on > that information only, the reader can't really figure > out how this works (or might arrive at quite different > solution). > > Perhaps not all the details aren't necessary, but > as the interaction of local state updates for DSMIPv6, > local state updates for IPsec, (DS)MIPv6 messages, > and IPsec messages it a bit complex, explaining > what happens (and in what order it has to happen) > would be IMHO helpful. The problem is some of the steps are very implementation specific. I can try to come up with some text, in the next couple of days, that explains what needs to be done in sufficient detail without tying down someone to a specific implementation. Vijay > > Best regards, > Pasi > >> -----Original Message----- >> From: ext Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] >> Sent: 19 November, 2007 04:02 >> To: Hesham Soliman >> Cc: mip6@ietf.org; nemo@ietf.org; Eronen Pasi (Nokia-NRC/Helsinki) >> Subject: Re: [nemo] Resolution of IKEv2 and DSMIPv6 issue >> >> Hi, >> >> This looks good, So what are we going to add to the draft? >> Just mention that transport mode ESP SA MUST be negotiated >> for sending a Binding Update? Or are we planning to add all >> the details below (that Pasi sent) to the draft? I would >> prefer the former. >> >> A couple of minor comments on packet formats below. >> >> Hesham Soliman wrote: >> >>> 7. The MN sends a Binding Update, which looks like this: >>> >>> IPv4 header (src=V4CoA, dst=V4HA) >>> UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT) >>> IPv6 header (src=V6HoA, dst=V6HA) >>> Destination Options header >>> Home Address option (V6HoA) >>> ESP header (transport mode) >>> Mobility header >>> Binding Update >>> IPv4 Care-of Address option (V4CoA) >> The destination options header would not be present in this BU, >> since the home address is already present in the IPv6 header >> itself. >> >>> 15. HA replies with a Binding Acknowledgement. >>> >>> IPv4 header (src=V4HA, dst=NATTED_V4CoA) >>> UDP header (src=DSMIPv6-PORT, dst=NATTED_DSMIPv6-PORT) >>> IPv6 header (src=V6HA, dst=V6HoA) >>> Routing header (type 2): V6HoA >>> ESP header (transport mode) >>> Mobility header >>> Binding Acknowledgement >>> [NAT detection option] >> The routing header should not be present in this binding ack, >> since the binding ack is already destined to the IPv6 home >> address. >> >> Vijay >> From mext-bounces@ietf.org Mon Nov 19 13:02: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 1IuAwk-00027f-K9; Mon, 19 Nov 2007 13:02:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuAwi-00027B-RV for mext@ietf.org; Mon, 19 Nov 2007 13:02:08 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuAwe-0007zI-TM for mext@ietf.org; Mon, 19 Nov 2007 13:02:08 -0500 Received: (qmail 9532 invoked for bounce); 19 Nov 2007 20:07:15 -0000 Received: from unknown (HELO ?130.79.91.222?) (kuntz@unknown) by unknown with RC4-SHA encrypted SMTP; 19 Nov 2007 20:07:15 -0000 Message-Id: <1BEF203C-142F-4089-8DC3-49FF7EC88628@clarinet.u-strasbg.fr> From: Romain KUNTZ To: Alexandru Petrescu In-Reply-To: <4741A405.8070106@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 19 Nov 2007 19:02:03 +0100 References: <483735.10786.qm@web84112.mail.mud.yahoo.com> <470167CD.8020601@gmail.com> <8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr> <473DC6F2.9060509@gmail.com> <664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr> <47417205.7070805@gmail.com> <4741A405.8070106@gmail.com> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: mext@ietf.org Subject: [MEXT] Re: [nemo] Prefix Delegation documents 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 On 2007/11/19, at 15:56, Alexandru Petrescu wrote: >> But from a deployment point of view, having a statically configured >> FQDN or just the domain name of the mobility operator is better >> than an IPv6 prefix, no? > > YEs, let's think from a deployment standpoint. > > Why do you think pre-configuring a FQDN of the domain is better than > the > IPv6 prefix of the home link? > > Is it because the operator may take advantage of DNS and inserting a > different IP prefix for same FQDN in the DNS when it changed the > addresses? But this does not cover the case when the operator changes > its FQDN names but keeps wants to keep the same addresses. > > Or else - why do you think pre-configured FQDN is better from a > deployment point of view? I do not speak only about FQDN, but also and mostly about Domain Name + DNS SRV. With that, the client of the service only needs to know an usually stable domain name (ok, FT switched to orange for some of their services, but such operation is usually done with a huge advertisement campaign), and then the HA (hence the HA address) can be decided according to the location of the MN, the type of service it needs (we can imagine extending the SRV request to differentiate mip6, nemo or mcoa services) etc. >>>> Using DHAAD means first retrieving the home prefix by a to-be- >>>> defined way then using DHAAD, where a DNS lookup or SRV query is >>>> a more efficient and already existing protocol. >>> But don't you think the same can be said about the FQDN? How does >>> MN retrieve its FQDN? >> I guess the FQDN or domain name would be given to the user when it >> subscribes to the service. Of course you may argue that the same >> could apply with the IPv6 home prefix, but I think the DNS and DNS >> SRV is more adapted to deployments precisely because the user is >> not provisioned with an address. > > You say so because you assume that the operator will always keep a > stable name and may sometime change its addresses if it wants to. This is not a question of being able to renumber the home network, but being able to give to the MN the more suitable HA address. > But I think that there are operators that change names and want to > keep > their addresses. Orange from FT is one example probably familiar. > > And this latter case can not be accustomed if MIPv6 Bootstrapping > pre-configures the FQDN in the MN. It can be accommodated if MIPv6 > Bootstrapping pre-configures the home prefix. Maybe this could help to have some operator point of view on this list? > I also think that it's the addresses that are the rare ressources not > the FQDNs. Once one gets a block of addresses one is highly > interested > in keeping them regardless of the changes in one's employer's name. > This has many reasons rooted in deployments, the difficulty in > renumbering being one of them. > > Alex > PS: besides, there may be a mixture method relying on both FQDN+DNS > and > prefix+DHAAD - thus helping many more types of deployments, why > not. Yes, if there is a strong need for 2 solutions though I'd Ideally prefer one unique solution. -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr Louis Pasteur University - Networks and Protocols Team _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From nemo-bounces@ietf.org Mon Nov 19 17:22: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 1IuF0N-0004nt-39; Mon, 19 Nov 2007 17:22:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuF0L-0004n0-Gr; Mon, 19 Nov 2007 17:22:09 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuF0H-0006bO-Ti; Mon, 19 Nov 2007 17:22:09 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Nov 2007 14:22:04 -0800 Message-ID: <47420C8B.2000407@azairenet.com> Date: Mon, 19 Nov 2007 14:22:03 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [nemo] Security considerations text References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Nov 2007 22:22:04.0508 (UTC) FILETIME=[9D0C51C0:01C82AFA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: nemo@ietf.org, mip6@ietf.org, Pasi.Eronen@nokia.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham, Mostly looks good. A few comments below. Hesham Soliman wrote: > 5.1 Handover interactions for IPsec and IKE > > After the mobile node detects movement it updates its tunnel > information depending on the network capability. If the new link is > IPv4-only then the mobile node updates its tunnel to UDP using the > DSMIPv6 port and the local IPv4 address. Furthermore, the mobile node > updates its local Security Association information to include its > local IPv4 address and with the remote address being the home agent's > IPv4 address. IMO, the mobile node should update the IKEv2 SA after receiving the binding acknowledgment. Not before. Not clear why it is required to update the IKEv2 SA before sending the binding update itself. > The mobile node also removes binding update list > entries for correspondent nodes since route optimisation cannot be > supported while the mobile node is in an IPv4-only network. This may > cause inbound packet losses as remote correspondent node are unaware > of such movement. I think we should require the mobile node to reserve tunnel binding updates to the CNs with zero lifetime to delete binding cache entries at the CNs. This should done once the DS-MIPv6 tunnel with the home agent is updated. Otherwise there might be a lot of packets lost. > Upon receiving the binding update message, the home agent updates it > security association locally to include the mobile node's remote > address as the IP address received in the outer header. When the > mobile node is located in a private IPv4 network (which is detected > as described above), this address is the public address allocated by > the NAT. Based on the setting of the K flag in the binding update, > the home agent updates its IKE security association to include the > remote address as that received in the outer header of the binding > update message. If the mobile node were located in a private IPv4 > network this address is likely to be wrong as the NAT would likely > allocate a different address to the IKE messages. Hence, the mobile > node MUST update the IKE SA in one of two ways as follows. The mobile > node SHOULD send an empty informational message, which results in the > IKE module in the home agent to dynamically update the SA > information. Alternatively, the IKE SA should be re-negotiated. When would this alternative be used? If the 'K' flag is not set, you would need a full IKEv2 exchange. You would need an empty Informational exchange only when the 'K' flag is set. This is to figure out the NATTED IP address and port for UDP port 4500. > Note > that updating the IKE SA MUST take place after the mobile node has > sent the binding update and received the acknowledgement from the > home agent. This says the IKE SA is updated after the BU/BAck exchange. Vijay From mext-bounces@ietf.org Mon Nov 19 17:31: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 1IuF9W-0004vM-LW; Mon, 19 Nov 2007 17:31:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuF9V-0004us-41 for mext@ietf.org; Mon, 19 Nov 2007 17:31:37 -0500 Received: from [2001:14b8:400::130] (helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuF9T-0006rN-Cz for mext@ietf.org; Mon, 19 Nov 2007 17:31:37 -0500 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id B939A1986B9 for ; Tue, 20 Nov 2007 00:31:34 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 4AAA3198670 for ; Tue, 20 Nov 2007 00:31:34 +0200 (EET) Message-ID: <47420EC7.80606@piuha.net> Date: Tue, 20 Nov 2007 00:31:35 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) 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: -1.4 (-) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Subject: [MEXT] MEXT charter 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 The charter that I sent to the secretary is shown below. I've updated the milestones plus taken some of the editorial comments from Thierry and Nicolas into account. However, I did not want to make any bigger changes due to the discussion we had with them in Chicago, because that would require a new IESG approval. But I note that given the interest for binding revocation, a charter update will probably be needed soon anyway. We can take care of remaining issues there. ---- Mobility EXTensions for IPv6 (MEXT) 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, network mobility (NEMO) 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 (Mobile IPv6) o RFC 3963 (NEMO) o RFC 4877 (Mobile IPv6 Operation with IKEv2) The MEXT Working Group continues the work of the former 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 Mobile IPv6 and NEMO 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 Mobile IPv6 or NEMO capable dual-stack hosts. (A.2) A protocol based solution for enhancing the reliability of home agents and a method to force a host/router 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: Done Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard Done Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard. Done Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard. Dec 2007 Submit Multiple CoA Registration to IESG Dec 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational. Dec 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard. Feb 2008 Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments Feb 2008 Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments Feb 2008 Submit -00 draft on Route Optimization needs for Personal Mobile Router Feb 2008 Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational. Mar 2008 Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard May 2008 Submit -00 draft for solution to aircraft/spacecraft problem May 2008 Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational May 2008 Submit final doc on Route Optimization Needs for Automobile and Highway Deployments, for Informational May 2008 Submit final doc on Route Optimization needs for Personal Mobile Router, for Informational Jun 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. Jun 2008 Determine how to proceed with 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 the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard Aug 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Oct 2008 Submit Flow/binding policy format to IESG, for Proposed Standard Oct 2008 Submit Flow/binding policy transport to IESG, for Proposed Standard Nov 2008 Submit final doc for solution to aircraft/spacecraft problem to the IESG, for Proposed Standard Nov 2008 Recharter to work on the remaining automotive/Personal Mobile Router solutions Dec 2008 Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. Dec 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 Mon Nov 19 17:31:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuF9L-0004WP-09; Mon, 19 Nov 2007 17:31:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuF9J-0004WH-Df for mext@ietf.org; Mon, 19 Nov 2007 17:31:25 -0500 Received: from [2001:14b8:400::130] (helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuF9J-0006r9-5B for mext@ietf.org; Mon, 19 Nov 2007 17:31:25 -0500 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 7FD6719867C; Tue, 20 Nov 2007 00:31:24 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 035B4198670; Tue, 20 Nov 2007 00:31:23 +0200 (EET) Message-ID: <47420EBD.8040303@piuha.net> Date: Tue, 20 Nov 2007 00:31:25 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: mext@ietf.org, Julien Laganier , marcelo bagnulo braun Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "Kniveton Timothy \(Nokia-ES/MtView\)" Subject: [MEXT] MEXT starts now 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 all, I'm happy to announce that MEXT is now finally created. Marcelo Braun and Julien Laganier are the new chairs. Please join me in welcoming them and thanking them for taking up this task! Their first task is to organize the agenda and meeting in Vancouver, so send mail to them for agenda slots and other requests. The IETF secretary is working on the WG web page updates and other practical details. The two slots for MIP6 in the current agenda will be renamed to MEXT slots. I would also like to thank the chairs of the three WGs that will now be merged into one: Thierry, Gopal, Basavaraj, TJ, and Nicolas -- big thanks for your hard work over the years! Jari Arkko _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From nemo-bounces@ietf.org Mon Nov 19 17:32: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 1IuF9x-0006Oi-Ae; Mon, 19 Nov 2007 17:32:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuF9v-0006MW-76; Mon, 19 Nov 2007 17:32:03 -0500 Received: from [2001:14b8:400::130] (helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuF9u-0006sT-Tg; Mon, 19 Nov 2007 17:32:03 -0500 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 48FE61986B9; Tue, 20 Nov 2007 00:32:02 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id E0472198670; Tue, 20 Nov 2007 00:32:01 +0200 (EET) Message-ID: <47420EE3.4010700@piuha.net> Date: Tue, 20 Nov 2007 00:32:03 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: Mobile IPv6 Mailing List , IETF NEMO WG , Monami6 WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [nemo] FW: MEXT starts now X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org FYI -- if you did not get the below message from mext@ietf.org then you are not subscribed on that list yet. All subscribers of the old three lists were moved to the mext list in the summer, but since then there may have been changes. I would like to ask everyone to start using the mext list from now on, for ease of tracking discussions. This includes even responses to old threads. Jari > Hi all, > > I'm happy to announce that MEXT is now finally created. Marcelo > Braun and Julien Laganier are the new chairs. Please join me > in welcoming them and thanking them for taking up this task! > > Their first task is to organize the agenda and meeting in > Vancouver, so send mail to them for agenda slots and other > requests. > > The IETF secretary is working on the WG web page updates and > other practical details. The two slots for MIP6 in the current > agenda will be renamed to MEXT slots. > > I would also like to thank the chairs of the three WGs that will > now be merged into one: Thierry, Gopal, Basavaraj, TJ, and > Nicolas -- big thanks for your hard work over the years! > > Jari Arkko From DewayneadaptAyala@howstuffworks.com Mon Nov 19 18:45:39 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuGJ9-0001P9-IF for nemo-archive@lists.ietf.org; Mon, 19 Nov 2007 18:45:39 -0500 Received: from pool-72-70-21-51.bstnma.east.verizon.net ([72.70.21.51] helo=userjo8276cc.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IuGJ9-0007UP-60 for nemo-archive@lists.ietf.org; Mon, 19 Nov 2007 18:45:39 -0500 Received: from frambesia by howstuffworks.com with SMTP id bpdYcBMVZX for ; Mon, 19 Nov 2007 18:44:59 +0500 From: "Teddy Cochran" To: Subject: Our safe, secure games will get you smiling Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Make Vegas your playing ground, wherever you are, with Vegas VIP. Play today and receive up to 555 in Welcome bonuses to make the experience that much sweeter! How does this great deal work? 1st deposit - 200% bonus, worth up to 200 2nd desposit - 100% bonus, worth up to 100 3rd deposit - 155% bonus, worth up to 155 4th deposit - 100% bonus, worth up to 100 Vegas VIP uses the securest and most realistic gaming software to guarantee you get the safest, most exciting playing experience available online today, and tomorrow! Take advantage today and you too could see your dreams come true http://eurocasinoav.com/ From mext-bounces@ietf.org Mon Nov 19 22:42: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 1IuJzb-0004Oo-Os; Mon, 19 Nov 2007 22:41:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuJza-00049c-CJ for mext@ietf.org; Mon, 19 Nov 2007 22:41:42 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuJzW-0005Pe-Tb for mext@ietf.org; Mon, 19 Nov 2007 22:41:42 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lAK3fbox008744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Nov 2007 19:41:37 -0800 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lAK3fark029224; Mon, 19 Nov 2007 19:41:37 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Nov 2007 19:41:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Nov 2007 19:41:32 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request to the admin to white list Pasi's email for MEXT Thread-Index: AcgrJz3zZ874M2oEQLKB2JiQ4MBYQA== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 20 Nov 2007 03:41:36.0634 (UTC) FILETIME=[408695A0:01C82B27] X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: -4.0 (----) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Pasi.Eronen@nokia.com Subject: [MEXT] Request to the admin to white list Pasi's email for 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, For a number of years now, someone or the other has been forwarding Pasi's email onto the MIP6 list. It is sometimes quite difficult to follow it, when the only email seen on the list is a reply to his email. Given that he isn't subscribed to the list and given that we don't see moderators forwarding the original email, it would help greatly if someone can white list his email on this list so that we can read his actual responses and not just rely on extracting info from responses to his responses :) =20 Thanks, Vidya _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From ElleninstallGagnon@rotax-owner.com Mon Nov 19 23:47:08 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuL0u-00055l-Ql for nemo-archive@lists.ietf.org; Mon, 19 Nov 2007 23:47:08 -0500 Received: from [200.94.194.143] (helo=user6239b25c87) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IuL0u-0005xI-Fl for nemo-archive@lists.ietf.org; Mon, 19 Nov 2007 23:47:08 -0500 Received: from tantrum by rotax-owner.com with SMTP id 2sNaRG12cx for ; Mon, 19 Nov 2007 22:46:37 +0600 From: "Amber Arrington" To: Subject: Relax and have fun with roulette Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Make Vegas your playing ground, wherever you are, with Vegas VIP. Play today and receive up to $555 in Welcome bonuses to make the experience that much sweeter! How does this great deal work? 1st deposit - 200% bonus, worth up to $200 2nd desposit - 100% bonus, worth up to $100 3rd deposit - 155% bonus, worth up to $155 4th deposit - 100% bonus, worth up to $100 Vegas VIP uses the securest and most realistic gaming software to guarantee you get the safest, most exciting playing experience available online today, and tomorrow! Take advantage today and you too could see your dreams come true http://eurocasinoav.com/ From mext-bounces@ietf.org Tue Nov 20 00:38: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 1IuLoH-0007ZV-A9; Tue, 20 Nov 2007 00:38:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuLoF-0007VX-3G for mext@ietf.org; Tue, 20 Nov 2007 00:38:07 -0500 Received: from deimos.multihop.net ([74.0.36.190] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuLoB-0007ZV-Ff for mext@ietf.org; Tue, 20 Nov 2007 00:38:07 -0500 Received: from [192.168.4.16] (vegas-eth.tehama.multihop.net [192.168.4.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 9E2DDA0A8CE; Mon, 19 Nov 2007 21:37:56 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <20A6A760-0F94-48B8-B167-57A2DC79F086@kniveton.com> Content-Transfer-Encoding: quoted-printable From: "T.J. Kniveton" Subject: Re: [MEXT] Request to the admin to white list Pasi's email for MEXT Date: Mon, 19 Nov 2007 21:37:57 -0800 To: "Narayanan, Vidya" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Pasi.Eronen@nokia.com, 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 Which message are you talking about? I don't see a forwarded message =20 from Pasi on the mext list. =10Anyway, I think Jari will have to add him to the whitelist at this =20= point. Of course, he could just subscribe.... ;-) TJ On Nov 19, 2007, at 7:41 PM, Narayanan, Vidya wrote: > Hi, > For a number of years now, someone or the other has been forwarding > Pasi's email onto the MIP6 list. It is sometimes quite difficult to > follow it, when the only email seen on the list is a reply to his =20 > email. > Given that he isn't subscribed to the list and given that we don't see > moderators forwarding the original email, it would help greatly if > someone can white list his email on this list so that we can read his > actual responses and not just rely on extracting info from =20 > responses to > his responses :) > > Thanks, > Vidya > > _______________________________________________ > 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 Nov 20 01:32: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 1IuMeI-0001Js-8i; Tue, 20 Nov 2007 01:31:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuMeG-00013P-B5 for mext@ietf.org; Tue, 20 Nov 2007 01:31:52 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuMeF-0008FK-Rp for mext@ietf.org; Tue, 20 Nov 2007 01:31:52 -0500 X-IronPort-AV: E=Sophos;i="4.21,439,1188770400"; d="scan'208";a="158203033" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Nov 2007 07:31:51 +0100 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 lAK6VoD6029209; Tue, 20 Nov 2007 07:31:50 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAK6VkUm020102; Tue, 20 Nov 2007 06:31:46 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 07:31:46 +0100 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: [MEXT] Re: [nemo] Prefix Delegation documents Date: Tue, 20 Nov 2007 07:31:40 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Re: [nemo] Prefix Delegation documents Thread-Index: Acgqs0RunasgViC5QVOFQgbJZrKvhQAi470w References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> From: "Pascal Thubert (pthubert)" To: "Romain KUNTZ" , "Alexandru Petrescu" X-OriginalArrivalTime: 20 Nov 2007 06:31:46.0724 (UTC) FILETIME=[0636AE40:01C82B3F] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15556.001 X-TM-AS-Result: No--15.332600-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2140; t=1195540310; x=1196404310; 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[MEXT]=20Re=3A=20[nemo]=20Prefix=20Delegation=20docum ents |Sender:=20; bh=9KAy0GDepcYYcBW+pq7Kxkgb5QfvfasIojXxPe7tF9U=; b=QIkUL117wAVFyZtxtT8jIWK+cPNXmxM0QC5tlO+gdBrY8LnTJAYPkTQcn4rhQ165xal4AAiP sHX8DzzmuBcRHLzwhGAGUJk0mXn+WS3UcI6c+40kBaRLeHq8eguPRxmy; 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: 538aad3a3c4f01d8b6a6477ca4248793 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 I'd say that one does not preclude the other. We could use DNS to get the anycast address and leave the dynamics of load balancing to the DHAAD process.=20 Pascal >-----Original Message----- >From: Romain KUNTZ [mailto:kuntz@clarinet.u-strasbg.fr] >Sent: Monday, November 19, 2007 2:51 PM >To: Alexandru Petrescu >Cc: mext@ietf.org >Subject: [MEXT] Re: [nemo] Prefix Delegation documents > >On 2007/11/19, at 12:22, Alexandru Petrescu wrote: >>>> I see it differently. I see it as the MIP6 bootstrapping work >>>> _should_ >>>> rely on DHAAD to assign the HA address. >>>> >>>> (I've always wondered how could the MIP6 bootstrapping work simply >>>> ignore the existence of DHAAD.) >>> DHAAD relies on the fact that the home prefix is known whereas MIP6 >>> bootstrapping does not. >> >> But Romain, the MN always has to have some pre-configured >> information before being able to acquire the HA address and HoA. >> >> If MIP6 Bootstrapping pre-configures a NAI, or maybe a FQDN of the >> home domain - don't you think one can easily say that "MIP6 >> bootstrapping relies on the fact that the NAI or the FQDN is known >> whereas DHAAD does not" - and thus make it look as an inconvenient? > >But from a deployment point of view, having a statically configured >FQDN or just the domain name of the mobility operator is better than >an IPv6 prefix, no? > >>> Using DHAAD means first retrieving the home prefix by a to-be- >>> defined way then using DHAAD, where a DNS lookup or SRV query is a >>> more efficient and already existing protocol. >> >> But don't you think the same can be said about the FQDN? How does >> MN retrieve its FQDN? > >I guess the FQDN or domain name would be given to the user when it >subscribes to the service. Of course you may argue that the same could >apply with the IPv6 home prefix, but I think the DNS and DNS SRV is >more adapted to deployments precisely because the user is not >provisioned with an address. > >romain > >_______________________________________________ >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 Nov 20 02:42: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 1IuNkT-0002r7-Mn; Tue, 20 Nov 2007 02:42:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuNkS-0002qx-Nh for mext@ietf.org; Tue, 20 Nov 2007 02:42:20 -0500 Received: from hpsmtp-eml20.kpnxchange.com ([213.75.38.85]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuNkR-0001IT-Q2 for mext@ietf.org; Tue, 20 Nov 2007 02:42:20 -0500 Received: from hpsmtp-eml07.kpnxchange.com ([213.75.38.107]) by hpsmtp-eml20.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 08:42:18 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml07.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 08:42:18 +0100 From: "Teco Boot" To: "'Pascal Thubert \(pthubert\)'" References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> Subject: RE: [MEXT] Re: [nemo] Prefix Delegation documents Date: Tue, 20 Nov 2007 08:42:14 +0100 Message-ID: <006a01c82b48$de794bb0$9b6be310$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgqs0RunasgViC5QVOFQgbJZrKvhQAi470wAAHbvwA= Content-Language: nl X-OriginalArrivalTime: 20 Nov 2007 07:42:18.0425 (UTC) FILETIME=[E0810290:01C82B48] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Pascal, Question on WG documents for prefix delegation. There are two of them: 1: draft-ietf-nemo-prefix-delegation-02.txt (August 21, 2007) 2: draft-ietf-nemo-dhcpv6-pd-02.txt (September 28, 2006) Are we still working on both solutions? This work is relevant to AUTOCONF WG, as some want to work on PD. And AUTOCONF shall verify existing specifications for being reused in a MANET environment. Teco. > -----Oorspronkelijk bericht----- > Van: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Verzonden: dinsdag 20 november 2007 7:32 > Aan: Romain KUNTZ; Alexandru Petrescu > CC: mext@ietf.org > Onderwerp: RE: [MEXT] Re: [nemo] Prefix Delegation documents > > I'd say that one does not preclude the other. We could use DNS to get > the anycast address and leave the dynamics of load balancing to the > DHAAD process. > > Pascal > >-----Original Message----- > >From: Romain KUNTZ [mailto:kuntz@clarinet.u-strasbg.fr] > >Sent: Monday, November 19, 2007 2:51 PM > >To: Alexandru Petrescu > >Cc: mext@ietf.org > >Subject: [MEXT] Re: [nemo] Prefix Delegation documents > > > >On 2007/11/19, at 12:22, Alexandru Petrescu wrote: > >>>> I see it differently. I see it as the MIP6 bootstrapping work > >>>> _should_ > >>>> rely on DHAAD to assign the HA address. > >>>> > >>>> (I've always wondered how could the MIP6 bootstrapping work simply > >>>> ignore the existence of DHAAD.) > >>> DHAAD relies on the fact that the home prefix is known whereas MIP6 > >>> bootstrapping does not. > >> > >> But Romain, the MN always has to have some pre-configured > >> information before being able to acquire the HA address and HoA. > >> > >> If MIP6 Bootstrapping pre-configures a NAI, or maybe a FQDN of the > >> home domain - don't you think one can easily say that "MIP6 > >> bootstrapping relies on the fact that the NAI or the FQDN is known > >> whereas DHAAD does not" - and thus make it look as an inconvenient? > > > >But from a deployment point of view, having a statically configured > >FQDN or just the domain name of the mobility operator is better than > >an IPv6 prefix, no? > > > >>> Using DHAAD means first retrieving the home prefix by a to-be- > >>> defined way then using DHAAD, where a DNS lookup or SRV query is a > >>> more efficient and already existing protocol. > >> > >> But don't you think the same can be said about the FQDN? How does > >> MN retrieve its FQDN? > > > >I guess the FQDN or domain name would be given to the user when it > >subscribes to the service. Of course you may argue that the same could > >apply with the IPv6 home prefix, but I think the DNS and DNS SRV is > >more adapted to deployments precisely because the user is not > >provisioned with an address. > > > >romain > > > >_______________________________________________ > >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 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From nemo-bounces@ietf.org Tue Nov 20 02:50:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuNrv-0004Ia-8M; Tue, 20 Nov 2007 02:50:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuNrt-0004Hv-0q; Tue, 20 Nov 2007 02:50:01 -0500 Received: from datnt07.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuNro-000205-9D; Tue, 20 Nov 2007 02:50:01 -0500 X-AuditID: c26e2f18-00001940000014a4-62-474291900e28 Received: from camaro.eu.tieto.com ([192.176.143.43]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 09:49:36 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 08:49:53 +0100 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, 20 Nov 2007 08:49:52 +0100 Message-ID: In-Reply-To: <47420EE3.4010700@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Monami6] FW: MEXT starts now Thread-Index: Acgq/AkTBeop250ASqi5BKSxWPUsSQATcf4g References: <47420EE3.4010700@piuha.net> From: To: , , , X-OriginalArrivalTime: 20 Nov 2007 07:49:53.0915 (UTC) FILETIME=[EFFF44B0:01C82B49] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Subject: [nemo] RE: [Monami6] FW: MEXT starts now X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Jari, How to subscribe ? BR, Karen > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Monday, November 19, 2007 11:32 PM > To: Mobile IPv6 Mailing List; IETF NEMO WG; Monami6 WG > Subject: [Monami6] FW: MEXT starts now >=20 > FYI -- if you did not get the below message from mext@ietf.org then > you are not subscribed on that list yet. All subscribers of the old > three lists were moved to the mext list in the summer, but since > then there may have been changes. >=20 > I would like to ask everyone to start using the mext list from now > on, for ease of tracking discussions. This includes even responses > to old threads. >=20 > Jari >=20 > > Hi all, > > > > I'm happy to announce that MEXT is now finally created. Marcelo > > Braun and Julien Laganier are the new chairs. Please join me > > in welcoming them and thanking them for taking up this task! > > > > Their first task is to organize the agenda and meeting in > > Vancouver, so send mail to them for agenda slots and other > > requests. > > > > The IETF secretary is working on the WG web page updates and > > other practical details. The two slots for MIP6 in the current > > agenda will be renamed to MEXT slots. > > > > I would also like to thank the chairs of the three WGs that will > > now be merged into one: Thierry, Gopal, Basavaraj, TJ, and > > Nicolas -- big thanks for your hard work over the years! > > > > Jari Arkko >=20 >=20 > _______________________________________________ > Monami6 mailing list > Monami6@ietf.org > https://www1.ietf.org/mailman/listinfo/monami6 >=20 From nemo-bounces@ietf.org Tue Nov 20 02:57: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 1IuNzC-0001kz-5f; Tue, 20 Nov 2007 02:57:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuNzA-0001k7-1d; Tue, 20 Nov 2007 02:57:32 -0500 Received: from [2001:14b8:400::130] (helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuNz8-00028F-Jj; Tue, 20 Nov 2007 02:57:32 -0500 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id E6EF319867C; Tue, 20 Nov 2007 09:57:29 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 8A3DF198670; Tue, 20 Nov 2007 09:57:29 +0200 (EET) Message-ID: <4742936B.8000606@piuha.net> Date: Tue, 20 Nov 2007 09:57:31 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: Karen.Nielsen@tietoenator.com References: <47420EE3.4010700@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: nemo@ietf.org, mip6@ietf.org, monami6@ietf.org Subject: [nemo] Re: [Monami6] FW: MEXT starts now X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > How to subscribe ? > https://www1.ietf.org/mailman/listinfo/mext From nemo-bounces@ietf.org Tue Nov 20 03:19:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuOJs-00028u-29; Tue, 20 Nov 2007 03:18:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuOJq-00027G-Gw; Tue, 20 Nov 2007 03:18:54 -0500 Received: from mail1.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuOJp-0002FH-AK; Tue, 20 Nov 2007 03:18:54 -0500 X-AuditID: c26e2f18-0000140800001384-18-4742985a396a Received: from stingray.eu.tieto.com ([192.176.143.13]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 10:18:34 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 09:18:51 +0100 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, 20 Nov 2007 09:18:50 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Security considerations text Thread-Index: AcgqUDDWggKB3XbESNy3EZ1ND52YaQANM4RwAADdY5AAAIGScAAJoISgACZA4yA= References: From: To: , , X-OriginalArrivalTime: 20 Nov 2007 08:18:51.0761 (UTC) FILETIME=[FBD58610:01C82B4D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: Pasi.Eronen@nokia.com Subject: [nemo] RE: Security considerations text X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, =20 A few comments below.=20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Monday, November 19, 2007 2:37 PM > To: nemo@ietf.org; mip6@ietf.org > Cc: Nielsen Karen E; Pasi.Eronen@nokia.com > Subject: Security considerations text >=20 >=20 > Folks,=20 >=20 > This is the current text in the draft. If there are comments=20 > we can add them > to the IESG comments, provided there are no major problems=20 > here. Thanks for > all the comments. Special thanks to Pasi and Karen for developing the > solution. >=20 > Hesham > =20 > This specification allows a mobile node to send one binding update > for its IPv6 and IPv4 home addresses. This is a slight=20 > deviation from > [MIPv6] which requires one binding update per home=20 > address. However, > like [MIPv6], the IPsec security association needed to authenticate > the binding update is still based on the mobile node's IPv6 home > address. Therefore, in order to authorize the mobile=20 > node's IPv4 home > address binding, the home agent MUST store the IPv4 address > corresponding to the IPv6 address that is allocated to a=20 > mobile node. > Therefore, it is sufficient for the home agent to know=20 > that the IPsec > verification for the packet containing the binding update was valid > provided that it knows which IPv4 home address is associated with > which IPv6 home address. Hence, the security of the IPv4=20 > home address > binding is the same as the IPv6 binding. >=20 > In effect, associating the mobile node's IPv4 home address with its > IPv6 home address moves the authorization of the binding update for > the IPv4 address to the Mobile IPv6 implementation, which infers it > from the fact that mobile node has an IPv6 home address=20 > and the right > credentials for sending an authentic binding update for=20 > such address. >=20 > In cases where this specification is used for NAT traversal, it is > important to note that it has the same UNSAF vulnerabilities > associated with RFC 3519. An attacker is able to hijack the mobile > node's session with the home agent if it can modify the contents of > the outer IPv4 header. The contents of the header are not > authenticated and there is no way for the home agent to=20 > verify their > validity. Hence, a man in the middle attack where a change in the > contents of the IPv4 header can cause a legitimate mobile node's > traffic to be diverted to an illegitimate receiver independently of > the authenticity of the binding update message. >=20 > In this specification the binding update message MUST be protected > using ESP transport mode. When the mobile node is located=20 > in an IPv4- > only network, the binding update message is encapsulated in UDP as > described earlier. However, UDP MUST NOT be used to encapsulate the > binding update message when the mobile node is located in an IPv6- > enabled network. If protection of payload traffic is=20 > needed when the > mobile node is located in an IPv4-only network,=20 > encapsulation is done > using tunnel mode ESP over port 4500 as described in [TUNSEC]. >=20 > Handovers within private IPv4 networks or from IPv6 to=20 > IPv4 networks > will have impacts on the security association between the=20 > mobile node > and the home agent. The following section presents the expected > behaviour of the mobile node and home agent in those situations. >=20 > 5.1 Handover interactions for IPsec and IKE >=20 > After the mobile node detects movement it updates its tunnel > information depending on the network capability. If the new link is > IPv4-only then the mobile node updates its tunnel to UDP using the > DSMIPv6 port and the local IPv4 address.=20 I am still not sure that the tunnel (the MN=3DHA tunnel)=20 should be updated already before the BU/BACK exchange. I would much prefer a wording which says something like the following: "After the mobile node detects movement it must prepare to send a BU using the new care-of-address. How the binding update is sent depends on the network capability. If the new link is IPv4-only then the mobile node much send the BU in a tunnel to UDP using the DSMIPv6 port and the local care-of-address IPv4 address. This may be achived by the mobile node updating its tunnel to the HA in accordance with the new Ipv4 care-of-address and the UDP tunnelling or it may be achived by other means. Note that if the tunnel in between the mobile node and the home agent is updated, the mobile node MUST NOT accept any traffic om this tunnel, except for the BACK itself, before the BACK from the Home Agent has been received." Furthermore, the=20 > mobile node > updates its local Security Association information to include its > local IPv4 address and with the remote address being the=20 > home agent's > IPv4 address.=20 I think this should only be done after the receipt of the BACK from the Home Agent. IN FACT this needs to be done after the receipt of the BACK (or be completed at this time),=20 because only then will the MN know whether there is a NAT or not, so only at this point in time can it appropriately update the IPSEc SAs to be RFC 3948 ones (if required). >The mobile node also removes binding update list > entries for correspondent nodes since route optimisation cannot be > supported while the mobile node is in an IPv4-only=20 > network. This may > cause inbound packet losses as remote correspondent node=20 > are unaware > of such movement. Following this, the mobile node sends the binding > update message to the home agent. >=20 > Upon receiving the binding update message, the home agent=20 > updates it > security association=20 --> security associations - locally to include the mobile node's remote > address as the IP address received in the outer header. When the > mobile node is located in a private IPv4 network (which is detected > as described above), this address is the public address=20 > allocated by > the NAT. Based on the setting of the K flag in the binding update, > the home agent updates its IKE security association to include the > remote address as that received in the outer header of the binding > update message. If the mobile node were located in a private IPv4 > network this address is likely to be wrong as the NAT would likely > allocate a different address to the IKE messages.=20 There is no mentioning of the ports here. Shouldn't that also be mentioned ? Further shouldn't we also say that the type of the tunnel SAs may need to changed from=20 4301 ones to 3948 ones ( [TUNSEC] ?) Hence, the mobile > node MUST update the IKE SA in one of two ways as follows.=20 > The mobile > node SHOULD send an empty informational message, which=20 > results in the > IKE module in the home agent to dynamically update the SA > information. Alternatively, the IKE SA should be=20 > re-negotiated. Note > that updating the IKE SA MUST take place after the mobile node has > sent the binding update and received the acknowledgement from the > home agent. >=20 > The mobile node MAY use [MOBIKE] to update its IKE SA with the home > agent. Using MOBIKE requires negotiating this capability with the > home agent when establishing the SA. In this case, the mobile node > and the home agent need not update their IPsec SAs locally as this > step is performed by MOBIKE. Furthermore, the use of MOBIKE allows > the mobile node to update the SA independently of the=20 > binding update > exchange. Hence, there is no need for the mobile node to wait for a > binding acknowledgement before performing MOBIKE. The use of MOBIKE > is OPTIONAL in this specification. >=20 >=20 BR, Karen From KrisagreeingJacobsen@switchboard.com Tue Nov 20 05:43:30 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuQZm-0002JY-Eu for nemo-archive@lists.ietf.org; Tue, 20 Nov 2007 05:43:30 -0500 Received: from 75-167-248-1.dvnp.qwest.net ([75.167.248.1] helo=batley7u0axesf.domain.actdsltmp) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IuQZl-00064C-U1 for nemo-archive@lists.ietf.org; Tue, 20 Nov 2007 05:43:30 -0500 Received: from agreeing by switchboard.com with SMTP id N7qqAMDI2O for ; Tue, 20 Nov 2007 04:42:53 +0600 From: "Charmaine London" To: Subject: Hey, start seeing dollars pouring in. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Make Vegas your playing ground, wherever you are, with Vegas VIP. Play today and receive up to $555 in Welcome bonuses to make the experience that much sweeter! How does this great deal work? 1st deposit - 200% bonus, worth up to $200 2nd desposit - 100% bonus, worth up to $100 3rd deposit - 155% bonus, worth up to $155 4th deposit - 100% bonus, worth up to $100 Vegas VIP uses the securest and most realistic gaming software to guarantee you get the safest, most exciting playing experience available online today, and tomorrow! Take advantage today and you too could see your dreams come true http://eurocasinoav.com/ From mext-bounces@ietf.org Tue Nov 20 05:51: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 1IuQhT-0001t7-BN; Tue, 20 Nov 2007 05:51:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuQhS-0001sw-1d for mext@ietf.org; Tue, 20 Nov 2007 05:51:26 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuQhN-00065b-Tk for mext@ietf.org; Tue, 20 Nov 2007 05:51:26 -0500 Received: (qmail 22592 invoked for bounce); 20 Nov 2007 12:56:32 -0000 Received: from unknown (HELO ?130.79.91.222?) (kuntz@unknown) by unknown with RC4-SHA encrypted SMTP; 20 Nov 2007 12:56:32 -0000 Message-Id: <00D46131-6A88-484B-A4CA-845C76494F61@clarinet.u-strasbg.fr> From: Romain KUNTZ To: mext@ietf.org In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [MEXT] Re: [nemo] Prefix Delegation documents Date: Tue, 20 Nov 2007 11:51:19 +0100 References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 Pascal, On 2007/11/20, at 7:31, Pascal Thubert (pthubert) wrote: > I'd say that one does not preclude the other. We could use DNS to get > the anycast address and leave the dynamics of load balancing to the > DHAAD process. Ok, this might be useful to specify that in the MIP6 bootstrapping document. But Alex's point was more about provisioning statically the MN with an IPv6 prefix, and not a domain name or FQDN. romain >> -----Original Message----- >> From: Romain KUNTZ [mailto:kuntz@clarinet.u-strasbg.fr] >> Sent: Monday, November 19, 2007 2:51 PM >> To: Alexandru Petrescu >> Cc: mext@ietf.org >> Subject: [MEXT] Re: [nemo] Prefix Delegation documents >> >> On 2007/11/19, at 12:22, Alexandru Petrescu wrote: >>>>> I see it differently. I see it as the MIP6 bootstrapping work >>>>> _should_ >>>>> rely on DHAAD to assign the HA address. >>>>> >>>>> (I've always wondered how could the MIP6 bootstrapping work simply >>>>> ignore the existence of DHAAD.) >>>> DHAAD relies on the fact that the home prefix is known whereas MIP6 >>>> bootstrapping does not. >>> >>> But Romain, the MN always has to have some pre-configured >>> information before being able to acquire the HA address and HoA. >>> >>> If MIP6 Bootstrapping pre-configures a NAI, or maybe a FQDN of the >>> home domain - don't you think one can easily say that "MIP6 >>> bootstrapping relies on the fact that the NAI or the FQDN is known >>> whereas DHAAD does not" - and thus make it look as an inconvenient? >> >> But from a deployment point of view, having a statically configured >> FQDN or just the domain name of the mobility operator is better than >> an IPv6 prefix, no? >> >>>> Using DHAAD means first retrieving the home prefix by a to-be- >>>> defined way then using DHAAD, where a DNS lookup or SRV query is a >>>> more efficient and already existing protocol. >>> >>> But don't you think the same can be said about the FQDN? How does >>> MN retrieve its FQDN? >> >> I guess the FQDN or domain name would be given to the user when it >> subscribes to the service. Of course you may argue that the same >> could >> apply with the IPv6 home prefix, but I think the DNS and DNS SRV is >> more adapted to deployments precisely because the user is not >> provisioned with an address. >> >> romain >> >> _______________________________________________ >> 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 Nov 20 06:36:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuROx-0006ZT-F8; Tue, 20 Nov 2007 06:36:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuROw-0006ZM-Rk for mext@ietf.org; Tue, 20 Nov 2007 06:36:22 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuROu-0007Ih-B3 for mext@ietf.org; Tue, 20 Nov 2007 06:36:22 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-153.messagelabs.com!1195558578!5303981!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 12870 invoked from network); 20 Nov 2007 11:36:19 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-10.tower-153.messagelabs.com with SMTP; 20 Nov 2007 11:36:19 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lAKBaIqv007607; Tue, 20 Nov 2007 04:36:18 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lAKBaH7w017486; Tue, 20 Nov 2007 05:36:17 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lAKBaEfX017382; Tue, 20 Nov 2007 05:36:15 -0600 (CST) Message-ID: <4742C6A3.8020909@gmail.com> Date: Tue, 20 Nov 2007 12:36:03 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [MEXT] Re: [nemo] Prefix Delegation documents References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071119-1, 19/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 Pascal Thubert (pthubert) wrote: > I'd say that one does not preclude the other. We could use DNS to get > the anycast address and leave the dynamics of load balancing to the > DHAAD process. I agree. If an operator pre-configures the DNS name of the home link on the MN then the MN could resolve it into the anycast address and run DHAAD from there. If same operator pre-configures the home prefix then the MN will add the anycast extension to that prefix and run DHAAD from there too. Alex > > Pascal >> -----Original Message----- >> From: Romain KUNTZ [mailto:kuntz@clarinet.u-strasbg.fr] >> Sent: Monday, November 19, 2007 2:51 PM >> To: Alexandru Petrescu >> Cc: mext@ietf.org >> Subject: [MEXT] Re: [nemo] Prefix Delegation documents >> >> On 2007/11/19, at 12:22, Alexandru Petrescu wrote: >>>>> I see it differently. I see it as the MIP6 bootstrapping work >>>>> _should_ >>>>> rely on DHAAD to assign the HA address. >>>>> >>>>> (I've always wondered how could the MIP6 bootstrapping work simply >>>>> ignore the existence of DHAAD.) >>>> DHAAD relies on the fact that the home prefix is known whereas MIP6 >>>> bootstrapping does not. >>> But Romain, the MN always has to have some pre-configured >>> information before being able to acquire the HA address and HoA. >>> >>> If MIP6 Bootstrapping pre-configures a NAI, or maybe a FQDN of the >>> home domain - don't you think one can easily say that "MIP6 >>> bootstrapping relies on the fact that the NAI or the FQDN is known >>> whereas DHAAD does not" - and thus make it look as an inconvenient? >> But from a deployment point of view, having a statically configured >> FQDN or just the domain name of the mobility operator is better than >> an IPv6 prefix, no? >> >>>> Using DHAAD means first retrieving the home prefix by a to-be- >>>> defined way then using DHAAD, where a DNS lookup or SRV query is a >>>> more efficient and already existing protocol. >>> But don't you think the same can be said about the FQDN? How does >>> MN retrieve its FQDN? >> I guess the FQDN or domain name would be given to the user when it >> subscribes to the service. Of course you may argue that the same could >> apply with the IPv6 home prefix, but I think the DNS and DNS SRV is >> more adapted to deployments precisely because the user is not >> provisioned with an address. >> >> romain >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 20 06:38: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 1IuRQf-0006Jj-6V; Tue, 20 Nov 2007 06:38:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRQe-0006Ja-1C for mext@ietf.org; Tue, 20 Nov 2007 06:38:08 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuRQb-0007LR-Lh for mext@ietf.org; Tue, 20 Nov 2007 06:38:08 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-128.messagelabs.com!1195558684!18649829!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 31473 invoked from network); 20 Nov 2007 11:38:04 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-8.tower-128.messagelabs.com with SMTP; 20 Nov 2007 11:38:04 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id lAKBc4br020912; Tue, 20 Nov 2007 04:38:04 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lAKBc3RX018307; Tue, 20 Nov 2007 05:38:03 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lAKBc1P3018184; Tue, 20 Nov 2007 05:38:01 -0600 (CST) Message-ID: <4742C70E.4030300@gmail.com> Date: Tue, 20 Nov 2007 12:37:50 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Romain KUNTZ Subject: Re: [MEXT] Re: [nemo] Prefix Delegation documents References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <00D46131-6A88-484B-A4CA-845C76494F61@clarinet.u-strasbg.fr> In-Reply-To: <00D46131-6A88-484B-A4CA-845C76494F61@clarinet.u-strasbg.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071119-1, 19/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Romain KUNTZ wrote: > Hi Pascal, > > On 2007/11/20, at 7:31, Pascal Thubert (pthubert) wrote: >> I'd say that one does not preclude the other. We could use DNS to get >> the anycast address and leave the dynamics of load balancing to the >> DHAAD process. > > Ok, this might be useful to specify that in the MIP6 bootstrapping > document. > But Alex's point was more about provisioning statically the MN with an > IPv6 prefix, and not a domain name or FQDN. Yes - more like to leave open the choice of what an operator or human user wants to pre-configure on her/his MN: home prefix, DNS name of the home link, NAI, MAC address - a set of possibilities. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 20 06:41:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRTc-00070O-0T; Tue, 20 Nov 2007 06:41:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRTZ-00070I-Te for mext@ietf.org; Tue, 20 Nov 2007 06:41:09 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuRTW-0007Pk-9y for mext@ietf.org; Tue, 20 Nov 2007 06:41:09 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1195558865!16150647!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 11832 invoked from network); 20 Nov 2007 11:41:05 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-11.tower-153.messagelabs.com with SMTP; 20 Nov 2007 11:41:05 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lAKBf43j008148; Tue, 20 Nov 2007 04:41:04 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lAKBf4wH019714; Tue, 20 Nov 2007 05:41:04 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lAKBf28l019631; Tue, 20 Nov 2007 05:41:02 -0600 (CST) Message-ID: <4742C7C3.6030903@gmail.com> Date: Tue, 20 Nov 2007 12:40:51 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Romain KUNTZ References: <483735.10786.qm@web84112.mail.mud.yahoo.com> <470167CD.8020601@gmail.com> <8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr> <473DC6F2.9060509@gmail.com> <664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr> <47417205.7070805@gmail.com> <4741A405.8070106@gmail.com> <1BEF203C-142F-4089-8DC3-49FF7EC88628@clarinet.u-strasbg.fr> In-Reply-To: <1BEF203C-142F-4089-8DC3-49FF7EC88628@clarinet.u-strasbg.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071119-1, 19/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: mext@ietf.org Subject: [MEXT] Re: [nemo] Prefix Delegation documents 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 Romain KUNTZ wrote: > On 2007/11/19, at 15:56, Alexandru Petrescu wrote: >>> But from a deployment point of view, having a statically configured >>> FQDN or just the domain name of the mobility operator is better than >>> an IPv6 prefix, no? >> >> YEs, let's think from a deployment standpoint. >> >> Why do you think pre-configuring a FQDN of the domain is better than the >> IPv6 prefix of the home link? >> >> Is it because the operator may take advantage of DNS and inserting a >> different IP prefix for same FQDN in the DNS when it changed the >> addresses? But this does not cover the case when the operator changes >> its FQDN names but keeps wants to keep the same addresses. >> >> Or else - why do you think pre-configured FQDN is better from a >> deployment point of view? > > I do not speak only about FQDN, but also and mostly about Domain Name + > DNS SRV. With that, the client of the service only needs to know an > usually stable domain name (ok, FT switched to orange for some of their > services, but such operation is usually done with a huge advertisement > campaign), and then the HA (hence the HA address) can be decided > according to the location of the MN, the type of service it needs (we > can imagine extending the SRV request to differentiate mip6, nemo or > mcoa services) etc. Yes, but when an operator changes the server HA what's easier and quicker means to update the MN: change HAs SRV entry in DNS or rely on DHAAD and periodic MPD the MN does? >>>>> Using DHAAD means first retrieving the home prefix by a >>>>> to-be-defined way then using DHAAD, where a DNS lookup or SRV query >>>>> is a more efficient and already existing protocol. >>>> But don't you think the same can be said about the FQDN? How does >>>> MN retrieve its FQDN? >>> I guess the FQDN or domain name would be given to the user when it >>> subscribes to the service. Of course you may argue that the same >>> could apply with the IPv6 home prefix, but I think the DNS and DNS >>> SRV is more adapted to deployments precisely because the user is not >>> provisioned with an address. >> >> You say so because you assume that the operator will always keep a >> stable name and may sometime change its addresses if it wants to. > > This is not a question of being able to renumber the home network, but > being able to give to the MN the more suitable HA address. Sounds as a good requirement. Another one would be to more efficiently and quickly update the MNs about a change in the home network. Alex >> But I think that there are operators that change names and want to keep >> their addresses. Orange from FT is one example probably familiar. >> >> And this latter case can not be accustomed if MIPv6 Bootstrapping >> pre-configures the FQDN in the MN. It can be accommodated if MIPv6 >> Bootstrapping pre-configures the home prefix. > > Maybe this could help to have some operator point of view on this list? > >> I also think that it's the addresses that are the rare ressources not >> the FQDNs. Once one gets a block of addresses one is highly interested >> in keeping them regardless of the changes in one's employer's name. >> This has many reasons rooted in deployments, the difficulty in >> renumbering being one of them. >> >> Alex >> PS: besides, there may be a mixture method relying on both FQDN+DNS and >> prefix+DHAAD - thus helping many more types of deployments, why not. > > Yes, if there is a strong need for 2 solutions though I'd Ideally prefer > one unique solution. > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 20 08:25: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 1IuT6S-0007E8-2Y; Tue, 20 Nov 2007 08:25:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuT6Q-0007E1-V8 for mext@ietf.org; Tue, 20 Nov 2007 08:25:22 -0500 Received: from rv-out-0910.google.com ([209.85.198.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuT6M-0001oU-NH for mext@ietf.org; Tue, 20 Nov 2007 08:25:22 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1549552rvb for ; Tue, 20 Nov 2007 05:25:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=iH4wwNph7/9Hzkc9h83maQ2dhpGSbR9QaYPqUmNz0g8=; b=NmNqg8pwf+rWbucdJ9IBB0spqNVoqAg/Kdi0+68be6A8UWINMQkMBCVIvTOQqognhp5HuShHyjB3orNLRo+E4jU6H2WF6zyTwvZ7Gbi09X/OHEzIvqqvZqCxQW7OV9YoWOAnt5jotAM+Gz1gu+FEV3MgxiNQSeo+C2pcsexMyBo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=B+p7uExI5T/pLKllksQt64ST5t4QJnRjZ3RZX1lzmbPP3nJV2blNrJElpLe0Qd9/YpVPpsmLRaQf60uGXEezdL7P+BnNCCZ++hTXFY0V2aDpxzUc3BngladBLCbrzWtFAJ5EgHU7D/oyzP7lv3Y9PgvxuEFUbI3mcENR/PiETsM= Received: by 10.141.99.4 with SMTP id b4mr2668647rvm.1195565117799; Tue, 20 Nov 2007 05:25:17 -0800 (PST) Received: by 10.141.177.11 with HTTP; Tue, 20 Nov 2007 05:25:17 -0800 (PST) Message-ID: Date: Tue, 20 Nov 2007 13:25:17 +0000 From: "George Tsirtsis" To: "Karen.Nielsen@tietoenator.com" In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Cc: mext@ietf.org, Pasi.Eronen@nokia.com, Hesham@elevatemobile.com Subject: [MEXT] Re: [nemo] RE: Security considerations text 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="===============2101639335==" Errors-To: mext-bounces@ietf.org --===============2101639335== Content-Type: multipart/alternative; boundary="----=_Part_12865_32563874.1195565117776" ------=_Part_12865_32563874.1195565117776 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Hesham, As both Karen and Vijay already indicated, when MOBIKE is not available, the SA renegotiation can only start after the MN receives the BACK from the HA. This is already clear at the end of the text you provided but maybe the first paragraph causes some confusion and could be clarified...possibly as follows: "> 5.1 Handover interactions for IPsec and IKE > > After the mobile node detects movement it updates its tunnel > information depending on the network capability. If the new link is > IPv4-only then the mobile node updates its tunnel to UDP using the > DSMIPv6 port and the local IPv4 address. After the mobile node registers its IPv4-CoA to the HA, it also updates its local Security Association information to include its local IPv4 address, with the remote address being the home agent's IPv4 address." Finally, for what is worth, I also agree with Vijay (had the same thought while reading your text) that when the MN moves to IPv4 network, it should revtunnel BUs to CNs to delete any RO sessions. Thanks George P.S.: Per Jari's suggestion I am moving this to mext mailing list. Good lack to the new chairs ;-) On 11/20/07, Karen.Nielsen@tietoenator.com wrote: > Hi, > > A few comments below. > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Monday, November 19, 2007 2:37 PM > > To: nemo@ietf.org; mip6@ietf.org > > Cc: Nielsen Karen E; Pasi.Eronen@nokia.com > > Subject: Security considerations text > > > > > > Folks, > > > > This is the current text in the draft. If there are comments > > we can add them > > to the IESG comments, provided there are no major problems > > here. Thanks for > > all the comments. Special thanks to Pasi and Karen for developing the > > solution. > > > > Hesham > > > > This specification allows a mobile node to send one binding update > > for its IPv6 and IPv4 home addresses. This is a slight > > deviation from > > [MIPv6] which requires one binding update per home > > address. However, > > like [MIPv6], the IPsec security association needed to authenticate > > the binding update is still based on the mobile node's IPv6 home > > address. Therefore, in order to authorize the mobile > > node's IPv4 home > > address binding, the home agent MUST store the IPv4 address > > corresponding to the IPv6 address that is allocated to a > > mobile node. > > Therefore, it is sufficient for the home agent to know > > that the IPsec > > verification for the packet containing the binding update was valid > > provided that it knows which IPv4 home address is associated with > > which IPv6 home address. Hence, the security of the IPv4 > > home address > > binding is the same as the IPv6 binding. > > > > In effect, associating the mobile node's IPv4 home address with its > > IPv6 home address moves the authorization of the binding update for > > the IPv4 address to the Mobile IPv6 implementation, which infers it > > from the fact that mobile node has an IPv6 home address > > and the right > > credentials for sending an authentic binding update for > > such address. > > > > In cases where this specification is used for NAT traversal, it is > > important to note that it has the same UNSAF vulnerabilities > > associated with RFC 3519. An attacker is able to hijack the mobile > > node's session with the home agent if it can modify the contents of > > the outer IPv4 header. The contents of the header are not > > authenticated and there is no way for the home agent to > > verify their > > validity. Hence, a man in the middle attack where a change in the > > contents of the IPv4 header can cause a legitimate mobile node's > > traffic to be diverted to an illegitimate receiver independently of > > the authenticity of the binding update message. > > > > In this specification the binding update message MUST be protected > > using ESP transport mode. When the mobile node is located > > in an IPv4- > > only network, the binding update message is encapsulated in UDP as > > described earlier. However, UDP MUST NOT be used to encapsulate the > > binding update message when the mobile node is located in an IPv6- > > enabled network. If protection of payload traffic is > > needed when the > > mobile node is located in an IPv4-only network, > > encapsulation is done > > using tunnel mode ESP over port 4500 as described in [TUNSEC]. > > > > Handovers within private IPv4 networks or from IPv6 to > > IPv4 networks > > will have impacts on the security association between the > > mobile node > > and the home agent. The following section presents the expected > > behaviour of the mobile node and home agent in those situations. > > > > 5.1 Handover interactions for IPsec and IKE > > > > After the mobile node detects movement it updates its tunnel > > information depending on the network capability. If the new link is > > IPv4-only then the mobile node updates its tunnel to UDP using the > > DSMIPv6 port and the local IPv4 address. > > I am still not sure that the tunnel (the MN=HA tunnel) > should be updated already before the BU/BACK exchange. > I would much prefer a wording which says something like the following: > > "After the mobile node detects movement it must prepare to send a BU > using the new care-of-address. > How the binding update is sent depends on the network capability. If > the new link is > IPv4-only then the mobile node much send the BU in a tunnel to UDP > using the > DSMIPv6 port and the local care-of-address IPv4 address. This may be > achived by the mobile node updating > its tunnel to the HA in accordance with the new Ipv4 care-of-address > and the UDP tunnelling or it may be achived > by other means. Note that if the tunnel in between the mobile node > and the home agent is updated, the mobile node MUST NOT accept > any traffic om this tunnel, except for the BACK itself, before the > BACK from the Home Agent has been received." > > Furthermore, the > > mobile node > > updates its local Security Association information to include its > > local IPv4 address and with the remote address being the > > home agent's > > IPv4 address. > > I think this should only be done after the receipt of the BACK from the > Home Agent. > IN FACT this needs to be done after the receipt of the BACK (or be > completed at this time), > because only then will > the MN know whether there is a NAT or not, so only at this point in time > can it appropriately update > the IPSEc SAs to be RFC 3948 ones (if required). > > >The mobile node also removes binding update list > > entries for correspondent nodes since route optimisation cannot be > > supported while the mobile node is in an IPv4-only > > network. This may > > cause inbound packet losses as remote correspondent node > > are unaware > > of such movement. Following this, the mobile node sends the binding > > update message to the home agent. > > > > Upon receiving the binding update message, the home agent > > updates it > > security association > > --> security associations > - > > locally to include the mobile node's remote > > address as the IP address received in the outer header. When the > > mobile node is located in a private IPv4 network (which is detected > > as described above), this address is the public address > > allocated by > > the NAT. Based on the setting of the K flag in the binding update, > > the home agent updates its IKE security association to include the > > remote address as that received in the outer header of the binding > > update message. If the mobile node were located in a private IPv4 > > network this address is likely to be wrong as the NAT would likely > > allocate a different address to the IKE messages. > > There is no mentioning of the ports here. Shouldn't that also be > mentioned ? > Further shouldn't we also say that the type of the tunnel SAs may need > to changed from > 4301 ones to 3948 ones ( [TUNSEC] ?) > > Hence, the mobile > > node MUST update the IKE SA in one of two ways as follows. > > The mobile > > node SHOULD send an empty informational message, which > > results in the > > IKE module in the home agent to dynamically update the SA > > information. Alternatively, the IKE SA should be > > re-negotiated. Note > > that updating the IKE SA MUST take place after the mobile node has > > sent the binding update and received the acknowledgement from the > > home agent. > > > > The mobile node MAY use [MOBIKE] to update its IKE SA with the home > > agent. Using MOBIKE requires negotiating this capability with the > > home agent when establishing the SA. In this case, the mobile node > > and the home agent need not update their IPsec SAs locally as this > > step is performed by MOBIKE. Furthermore, the use of MOBIKE allows > > the mobile node to update the SA independently of the > > binding update > > exchange. Hence, there is no need for the mobile node to wait for a > > binding acknowledgement before performing MOBIKE. The use of MOBIKE > > is OPTIONAL in this specification. > > > > > BR, Karen > > ------=_Part_12865_32563874.1195565117776 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Hesham,
As both Karen and Vijay already indicated, when MOBIKE is not available, the SA renegotiation can only start after the MN receives the BACK from the HA. This is already clear at the end of the text you provided but maybe the first paragraph causes some confusion and could be clarified...possibly as follows:
"> 5.1 Handover interactions for IPsec and IKE
>
>    After the mobile node detects movement it updates its tunnel
>    information depending on the network capability. If the new link is
>    IPv4-only then the mobile node updates its tunnel to UDP using the
>    DSMIPv6 port and the local IPv4 address.
After the mobile node registers its IPv4-CoA to the HA, it also updates its local Security Association information to include its local IPv4 address, with the remote address being the home agent's IPv4 address."

Finally, for what is worth, I also agree with Vijay (had the same thought while reading your text) that when the MN moves to IPv4 network, it should revtunnel BUs to CNs to delete any RO sessions.

Thanks
George
P.S.: Per Jari's suggestion I am moving this to mext mailing list. Good lack to the new chairs ;-)

On 11/20/07, Karen.Nielsen@tietoenator.com <Karen.Nielsen@tietoenator.com> wrote:
> Hi,
>
> A few comments below.
>
> > -----Original Message-----
> > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]
> > Sent: Monday, November 19, 2007 2:37 PM
> > To: nemo@ietf.org; mip6@ietf.org
> > Cc: Nielsen Karen E; Pasi.Eronen@nokia.com
> > Subject: Security considerations text
> >
> >
> > Folks,
> >
> > This is the current text in the draft. If there are comments
> > we can add them
> > to the IESG comments, provided there are no major problems
> > here. Thanks for
> > all the comments. Special thanks to Pasi and Karen for developing the
> > solution.
> >
> > Hesham
> >
> >    This specification allows a mobile node to send one binding update
> >    for its IPv6 and IPv4 home addresses. This is a slight
> > deviation from
> >    [MIPv6] which requires one binding update per home
> > address. However,
> >    like [MIPv6], the IPsec security association needed to authenticate
> >    the binding update is still based on the mobile node's IPv6 home
> >    address. Therefore, in order to authorize the mobile
> > node's IPv4 home
> >    address binding, the home agent MUST store the IPv4 address
> >    corresponding to the IPv6 address that is allocated to a
> > mobile node.
> >    Therefore, it is sufficient for the home agent to know
> > that the IPsec
> >    verification for the packet containing the binding update was valid
> >    provided that it knows which IPv4 home address is associated with
> >    which IPv6 home address. Hence, the security of the IPv4
> > home address
> >    binding is the same as the IPv6 binding.
> >
> >    In effect, associating the mobile node's IPv4 home address with its
> >    IPv6 home address moves the authorization of the binding update for
> >    the IPv4 address to the Mobile IPv6 implementation, which infers it
> >    from the fact that mobile node has an IPv6 home address
> > and the right
> >    credentials for sending an authentic binding update for
> > such address.
> >
> >    In cases where this specification is used for NAT traversal, it is
> >    important to note that it has the same UNSAF vulnerabilities
> >    associated with RFC 3519. An attacker is able to hijack the mobile
> >    node's session with the home agent if it can modify the contents of
> >    the outer IPv4 header. The contents of the header are not
> >    authenticated and there is no way for the home agent to
> > verify their
> >    validity. Hence, a man in the middle attack where a change in the
> >    contents of the IPv4 header can cause a legitimate mobile node's
> >    traffic to be diverted to an illegitimate receiver independently of
> >    the authenticity of the binding update message.
> >
> >    In this specification the binding update message MUST be protected
> >    using ESP transport mode. When the mobile node is located
> > in an IPv4-
> >    only network, the binding update message is encapsulated in UDP as
> >    described earlier. However, UDP MUST NOT be used to encapsulate the
> >    binding update message when the mobile node is located in an IPv6-
> >    enabled network. If protection of payload traffic is
> > needed when the
> >    mobile node is located in an IPv4-only network,
> > encapsulation is done
> >    using tunnel mode ESP over port 4500 as described in [TUNSEC].
> >
> >    Handovers within private IPv4 networks or from IPv6 to
> > IPv4 networks
> >    will have impacts on the security association between the
> > mobile node
> >    and the home agent. The following section presents the expected
> >    behaviour of the mobile node and home agent in those situations.
> >
> > 5.1 Handover interactions for IPsec and IKE
> >
> >    After the mobile node detects movement it updates its tunnel
> >    information depending on the network capability. If the new link is
> >    IPv4-only then the mobile node updates its tunnel to UDP using the
> >    DSMIPv6 port and the local IPv4 address.
>
> I am still not sure that the tunnel (the MN=HA tunnel)
> should be updated already before the BU/BACK exchange.
> I would much prefer a wording which says something like the following:
>
>   "After the mobile node detects movement it must prepare to send a BU
> using the new care-of-address.
>    How the binding update is sent depends on the network capability. If
> the new link is
>    IPv4-only then the mobile node much send the BU in a tunnel to UDP
> using the
>    DSMIPv6 port and the local care-of-address IPv4 address. This may be
> achived by the mobile node updating
>    its tunnel to the HA in accordance with the new Ipv4 care-of-address
> and the UDP tunnelling or it may be achived
>    by other means. Note that if the tunnel in between the mobile node
> and the home agent is updated, the mobile node MUST NOT accept
>    any traffic om this tunnel, except for the BACK itself, before the
> BACK from the Home Agent has been received."
>
> Furthermore, the
> > mobile node
> >    updates its local Security Association information to include its
> >    local IPv4 address and with the remote address being the
> > home agent's
> >    IPv4 address.
>
> I think this should only be done after the receipt of the BACK from the
> Home Agent.
> IN FACT this needs to be done after the receipt of the BACK (or be
> completed at this time),
> because only then will
> the MN know whether there is a NAT or not, so only at this point in time
> can it appropriately update
> the IPSEc SAs to be RFC 3948 ones (if required).
>
> >The mobile node also removes binding update list
> >    entries for correspondent nodes since route optimisation cannot be
> >    supported while the mobile node is in an IPv4-only
> > network. This may
> >    cause inbound packet losses as remote correspondent node
> > are unaware
> >    of such movement. Following this, the mobile node sends the binding
> >    update message to the home agent.
> >
> >    Upon receiving the binding update message, the home agent
> > updates it
> >    security association
>
> --> security associations
>                        -
>
> locally to include the mobile node's remote
> >    address as the IP address received in the outer header. When the
> >    mobile node is located in a private IPv4 network (which is detected
> >    as described above), this address is the public address
> > allocated by
> >    the NAT. Based on the setting of the K flag in the binding update,
> >    the home agent updates its IKE security association to include the
> >    remote address as that received in the outer header of the binding
> >    update message. If the mobile node were located in a private IPv4
> >    network this address is likely to be wrong as the NAT would likely
> >    allocate a different address to the IKE messages.
>
> There is no mentioning of the ports here. Shouldn't that also be
> mentioned ?
> Further shouldn't we also say that the type of the tunnel SAs may need
> to changed from
> 4301 ones to 3948 ones ( [TUNSEC] ?)
>
> Hence, the mobile
> >    node MUST update the IKE SA in one of two ways as follows.
> > The mobile
> >    node SHOULD send an empty informational message, which
> > results in the
> >    IKE module in the home agent to dynamically update the SA
> >    information. Alternatively, the IKE SA should be
> > re-negotiated. Note
> >    that updating the IKE SA MUST take place after the mobile node has
> >    sent the binding update and received the acknowledgement from the
> >    home agent.
> >
> >    The mobile node MAY use [MOBIKE] to update its IKE SA with the home
> >    agent. Using MOBIKE requires negotiating this capability with the
> >    home agent when establishing the SA. In this case, the mobile node
> >    and the home agent need not update their IPsec SAs locally as this
> >    step is performed by MOBIKE. Furthermore, the use of MOBIKE allows
> >    the mobile node to update the SA independently of the
> > binding update
> >    exchange. Hence, there is no need for the mobile node to wait for a
> >    binding acknowledgement before performing MOBIKE. The use of MOBIKE
> >    is OPTIONAL in this specification.
> >
> >
> BR, Karen
>
>

 
 ------=_Part_12865_32563874.1195565117776-- --===============2101639335== 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 --===============2101639335==-- From mext-bounces@ietf.org Tue Nov 20 08:42:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTMy-0008D7-Jn; Tue, 20 Nov 2007 08:42:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTMw-0008D1-Qp for mext@ietf.org; Tue, 20 Nov 2007 08:42:26 -0500 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuTMs-0002GM-6g for mext@ietf.org; Tue, 20 Nov 2007 08:42:26 -0500 Received: from oaamta05ps.mx.bigpond.com ([124.190.106.219]) by omta01ps.mx.bigpond.com with ESMTP id <20071120134216.IPYX16290.omta01ps.mx.bigpond.com@oaamta05ps.mx.bigpond.com> for ; Tue, 20 Nov 2007 13:42:16 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta05ps.mx.bigpond.com with ESMTP id <20071120134214.DHPF14439.oaamta05ps.mx.bigpond.com@PC20005>; Tue, 20 Nov 2007 13:42:14 +0000 From: "Hesham Soliman" To: "'George Tsirtsis'" , Subject: RE: [MEXT] Re: [nemo] RE: Security considerations text Date: Wed, 21 Nov 2007 00:42:01 +1000 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgreQG5pseB32tuRJaIYQvIDERS7AACmWhQ In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b6c13497db1e4e7b275c86cfcdad7bb Cc: Pasi.Eronen@nokia.com, 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="===============1474753108==" Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1474753108== Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01C82BD7.549B8360" This is a multi-part message in MIME format. ------=_NextPart_000_004A_01C82BD7.549B8360 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thanks George, I must be missing some emails because I only saw one email from Karen on this. I'm noting all these comments for the meeting. Hesham _____ From: George Tsirtsis [mailto:tsirtsis@googlemail.com] Sent: Tuesday, November 20, 2007 11:25 PM To: Karen.Nielsen@tietoenator.com Cc: mext@ietf.org; Pasi.Eronen@nokia.com; Hesham@elevatemobile.com Subject: [MEXT] Re: [nemo] RE: Security considerations text Hi Hesham, As both Karen and Vijay already indicated, when MOBIKE is not available, the SA renegotiation can only start after the MN receives the BACK from the HA. This is already clear at the end of the text you provided but maybe the first paragraph causes some confusion and could be clarified...possibly as follows: "> 5.1 Handover interactions for IPsec and IKE > > After the mobile node detects movement it updates its tunnel > information depending on the network capability. If the new link is > IPv4-only then the mobile node updates its tunnel to UDP using the > DSMIPv6 port and the local IPv4 address. After the mobile node registers its IPv4-CoA to the HA, it also updates its local Security Association information to include its local IPv4 address, with the remote address being the home agent's IPv4 address." Finally, for what is worth, I also agree with Vijay (had the same thought while reading your text) that when the MN moves to IPv4 network, it should revtunnel BUs to CNs to delete any RO sessions. Thanks George P.S.: Per Jari's suggestion I am moving this to mext mailing list. Good lack to the new chairs ;-) On 11/20/07, Karen.Nielsen@tietoenator.com wrote: > Hi, > > A few comments below. > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Monday, November 19, 2007 2:37 PM > > To: nemo@ietf.org; mip6@ietf.org > > Cc: Nielsen Karen E; Pasi.Eronen@nokia.com > > Subject: Security considerations text > > > > > > Folks, > > > > This is the current text in the draft. If there are comments > > we can add them > > to the IESG comments, provided there are no major problems > > here. Thanks for > > all the comments. Special thanks to Pasi and Karen for developing the > > solution. > > > > Hesham > > > > This specification allows a mobile node to send one binding update > > for its IPv6 and IPv4 home addresses. This is a slight > > deviation from > > [MIPv6] which requires one binding update per home > > address. However, > > like [MIPv6], the IPsec security association needed to authenticate > > the binding update is still based on the mobile node's IPv6 home > > address. Therefore, in order to authorize the mobile > > node's IPv4 home > > address binding, the home agent MUST store the IPv4 address > > corresponding to the IPv6 address that is allocated to a > > mobile node. > > Therefore, it is sufficient for the home agent to know > > that the IPsec > > verification for the packet containing the binding update was valid > > provided that it knows which IPv4 home address is associated with > > which IPv6 home address. Hence, the security of the IPv4 > > home address > > binding is the same as the IPv6 binding. > > > > In effect, associating the mobile node's IPv4 home address with its > > IPv6 home address moves the authorization of the binding update for > > the IPv4 address to the Mobile IPv6 implementation, which infers it > > from the fact that mobile node has an IPv6 home address > > and the right > > credentials for sending an authentic binding update for > > such address. > > > > In cases where this specification is used for NAT traversal, it is > > important to note that it has the same UNSAF vulnerabilities > > associated with RFC 3519. An attacker is able to hijack the mobile > > node's session with the home agent if it can modify the contents of > > the outer IPv4 header. The contents of the header are not > > authenticated and there is no way for the home agent to > > verify their > > validity. Hence, a man in the middle attack where a change in the > > contents of the IPv4 header can cause a legitimate mobile node's > > traffic to be diverted to an illegitimate receiver independently of > > the authenticity of the binding update message. > > > > In this specification the binding update message MUST be protected > > using ESP transport mode. When the mobile node is located > > in an IPv4- > > only network, the binding update message is encapsulated in UDP as > > described earlier. However, UDP MUST NOT be used to encapsulate the > > binding update message when the mobile node is located in an IPv6- > > enabled network. If protection of payload traffic is > > needed when the > > mobile node is located in an IPv4-only network, > > encapsulation is done > > using tunnel mode ESP over port 4500 as described in [TUNSEC]. > > > > Handovers within private IPv4 networks or from IPv6 to > > IPv4 networks > > will have impacts on the security association between the > > mobile node > > and the home agent. The following section presents the expected > > behaviour of the mobile node and home agent in those situations. > > > > 5.1 Handover interactions for IPsec and IKE > > > > After the mobile node detects movement it updates its tunnel > > information depending on the network capability. If the new link is > > IPv4-only then the mobile node updates its tunnel to UDP using the > > DSMIPv6 port and the local IPv4 address. > > I am still not sure that the tunnel (the MN=HA tunnel) > should be updated already before the BU/BACK exchange. > I would much prefer a wording which says something like the following: > > "After the mobile node detects movement it must prepare to send a BU > using the new care-of-address. > How the binding update is sent depends on the network capability. If > the new link is > IPv4-only then the mobile node much send the BU in a tunnel to UDP > using the > DSMIPv6 port and the local care-of-address IPv4 address. This may be > achived by the mobile node updating > its tunnel to the HA in accordance with the new Ipv4 care-of-address > and the UDP tunnelling or it may be achived > by other means. Note that if the tunnel in between the mobile node > and the home agent is updated, the mobile node MUST NOT accept > any traffic om this tunnel, except for the BACK itself, before the > BACK from the Home Agent has been received." > > Furthermore, the > > mobile node > > updates its local Security Association information to include its > > local IPv4 address and with the remote address being the > > home agent's > > IPv4 address. > > I think this should only be done after the receipt of the BACK from the > Home Agent. > IN FACT this needs to be done after the receipt of the BACK (or be > completed at this time), > because only then will > the MN know whether there is a NAT or not, so only at this point in time > can it appropriately update > the IPSEc SAs to be RFC 3948 ones (if required). > > >The mobile node also removes binding update list > > entries for correspondent nodes since route optimisation cannot be > > supported while the mobile node is in an IPv4-only > > network. This may > > cause inbound packet losses as remote correspondent node > > are unaware > > of such movement. Following this, the mobile node sends the binding > > update message to the home agent. > > > > Upon receiving the binding update message, the home agent > > updates it > > security association > > --> security associations > - > > locally to include the mobile node's remote > > address as the IP address received in the outer header. When the > > mobile node is located in a private IPv4 network (which is detected > > as described above), this address is the public address > > allocated by > > the NAT. Based on the setting of the K flag in the binding update, > > the home agent updates its IKE security association to include the > > remote address as that received in the outer header of the binding > > update message. If the mobile node were located in a private IPv4 > > network this address is likely to be wrong as the NAT would likely > > allocate a different address to the IKE messages. > > There is no mentioning of the ports here. Shouldn't that also be > mentioned ? > Further shouldn't we also say that the type of the tunnel SAs may need > to changed from > 4301 ones to 3948 ones ( [TUNSEC] ?) > > Hence, the mobile > > node MUST update the IKE SA in one of two ways as follows. > > The mobile > > node SHOULD send an empty informational message, which > > results in the > > IKE module in the home agent to dynamically update the SA > > information. Alternatively, the IKE SA should be > > re-negotiated. Note > > that updating the IKE SA MUST take place after the mobile node has > > sent the binding update and received the acknowledgement from the > > home agent. > > > > The mobile node MAY use [MOBIKE] to update its IKE SA with the home > > agent. Using MOBIKE requires negotiating this capability with the > > home agent when establishing the SA. In this case, the mobile node > > and the home agent need not update their IPsec SAs locally as this > > step is performed by MOBIKE. Furthermore, the use of MOBIKE allows > > the mobile node to update the SA independently of the > > binding update > > exchange. Hence, there is no need for the mobile node to wait for a > > binding acknowledgement before performing MOBIKE. The use of MOBIKE > > is OPTIONAL in this specification. > > > > > BR, Karen > > ------=_NextPart_000_004A_01C82BD7.549B8360 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Thanks George,
 
I must be missing some emails because I only = saw one email=20 from Karen on this. I'm noting all these comments for the meeting.=20
 
Hesham

From: George Tsirtsis=20 [mailto:tsirtsis@googlemail.com]
Sent: Tuesday, November = 20, 2007=20 11:25 PM
To: Karen.Nielsen@tietoenator.com
Cc:=20 mext@ietf.org; Pasi.Eronen@nokia.com;=20 Hesham@elevatemobile.com
Subject: [MEXT] Re: [nemo] RE: = Security=20 considerations text

Hi Hesham,
As both Karen = and Vijay=20 already indicated, when MOBIKE is not available, the SA = renegotiation can=20 only start after the MN receives the BACK from the HA. This is already = clear=20 at the end of the text you provided but maybe the first paragraph = causes some=20 confusion and could be clarified...possibly as follows:
"> 5.1 = Handover=20 interactions for IPsec and IKE
>
>    After the = mobile=20 node detects movement it updates its tunnel
>   =  information=20 depending on the network capability. If the new link is
>   =  IPv4-only then the mobile node updates its tunnel to UDP using=20 the
>    DSMIPv6 port and the local IPv4 address.=20
After the mobile node = registers its=20 IPv4-CoA to the HA, it also updates its local Security = Association=20 information to include its local IPv4 address, with the remote = address=20 being the home agent's IPv4 address."

Finally, for what = is worth,=20 I also agree with Vijay (had the same thought while reading your text) = that=20 when the MN moves to IPv4 network, it should revtunnel BUs to CNs to = delete=20 any RO sessions.

Thanks
George
P.S.: Per Jari's suggestion I am moving = this to=20 mext mailing list. Good lack to the new chairs ;-)

On 11/20/07, Karen.Nielsen@tietoenator.c= om=20 <Karen.Nielsen@tietoenator.c= om>=20 wrote:
> Hi,
>
> A few comments below.
> =
>=20 > -----Original Message-----
> > From: Hesham Soliman = [mailto:Hesham@elevatemobile.com]>=20 > Sent: Monday, November 19, 2007 2:37 PM
> > To: nemo@ietf.org; mip6@ietf.org
> > Cc: = Nielsen Karen=20 E; Pasi.Eronen@nokia.com
>=20 > Subject: Security considerations text
> >
> = >
>=20 > Folks,
> >
> > This is the current text in the = draft.=20 If there are comments
> > we can add them
> > to the = IESG=20 comments, provided there are no major problems
> > here. = Thanks=20 for
> > all the comments. Special thanks to Pasi and Karen = for=20 developing the
> > solution.
> >
> > = Hesham
>=20 >
> >    This specification allows a = mobile=20 node to send one binding update
> = >    for its=20 IPv6 and IPv4 home addresses. This is a slight
> > deviation=20 from
> >    [MIPv6] which requires one = binding=20 update per home
> > address. However,
>=20 >    like [MIPv6], the IPsec security = association=20 needed to authenticate
> >    the = binding update=20 is still based on the mobile node's IPv6 home
>=20 >    address. Therefore, in order to authorize = the=20 mobile
> > node's IPv4 home
>=20 >    address binding, the home agent MUST store = the=20 IPv4 address
> >    corresponding to the = IPv6=20 address that is allocated to a
> > mobile node.
>=20 >    Therefore, it is sufficient for the home = agent to=20 know
> > that the IPsec
>=20 >    verification for the packet containing the = binding=20 update was valid
> >    provided that it = knows=20 which IPv4 home address is associated with
>=20 >    which IPv6 home address. Hence, the = security of=20 the IPv4
> > home address
> = >    binding=20 is the same as the IPv6 binding.
> >
>=20 >    In effect, associating the mobile node's = IPv4 home=20 address with its
> >    IPv6 home address = moves=20 the authorization of the binding update for
>=20 >    the IPv4 address to the Mobile IPv6=20 implementation, which infers it
> = >    from the=20 fact that mobile node has an IPv6 home address
> > and the=20 right
> >    credentials for sending an = authentic=20 binding update for
> > such address.
> >
>=20 >    In cases where this specification is used = for NAT=20 traversal, it is
> >    important to = note that=20 it has the same UNSAF vulnerabilities
>=20 >    associated with RFC 3519. An attacker is = able to=20 hijack the mobile
> >    node's session = with the=20 home agent if it can modify the contents of
>=20 >    the outer IPv4 header. The contents of the = header=20 are not
> >    authenticated and there is = no way=20 for the home agent to
> > verify their
>=20 >    validity. Hence, a man in the middle = attack where=20 a change in the
> >    contents of the = IPv4=20 header can cause a legitimate mobile node's
>=20 >    traffic to be diverted to an illegitimate = receiver=20 independently of
> >    the authenticity = of the=20 binding update message.
> >
> = >    In=20 this specification the binding update message MUST be = protected
>=20 >    using ESP transport mode. When the mobile = node is=20 located
> > in an IPv4-
> = >    only=20 network, the binding update message is encapsulated in UDP as
> = >    described earlier. However, UDP MUST NOT = be used=20 to encapsulate the
> >    binding update = message=20 when the mobile node is located in an IPv6-
>=20 >    enabled network. If protection of payload = traffic=20 is
> > needed when the
> = >    mobile=20 node is located in an IPv4-only network,
> > encapsulation is = done
> >    using tunnel mode ESP over = port 4500=20 as described in [TUNSEC].
> >
>=20 >    Handovers within private IPv4 networks or = from=20 IPv6 to
> > IPv4 networks
> = >    will=20 have impacts on the security association between the
> > = mobile=20 node
> >    and the home agent. The = following=20 section presents the expected
> = >    behaviour=20 of the mobile node and home agent in those situations.
> = >
>=20 > 5.1 Handover interactions for IPsec and IKE
> >
>=20 >    After the mobile node detects movement it = updates=20 its tunnel
> >    information depending = on the=20 network capability. If the new link is
>=20 >    IPv4-only then the mobile node updates its = tunnel=20 to UDP using the
> >    DSMIPv6 port and = the=20 local IPv4 address.
>
> I am still not sure that the = tunnel (the=20 MN=3DHA tunnel)
> should be updated already before the BU/BACK=20 exchange.
> I would much prefer a wording which says something = like the=20 following:
>
>   "After the mobile node detects = movement it must prepare to send a BU
> using the new=20 care-of-address.
>    How the binding update is sent = depends=20 on the network capability. If
> the new link is
> =   =20 IPv4-only then the mobile node much send the BU in a tunnel to = UDP
>=20 using the
>    DSMIPv6 port and the local = care-of-address IPv4=20 address. This may be
> achived by the mobile node = updating
>=20    its tunnel to the HA in accordance with the new Ipv4=20 care-of-address
> and the UDP tunnelling or it may be = achived
>=20    by other means. Note that if the tunnel in between the = mobile=20 node
> and the home agent is updated, the mobile node MUST NOT = accept=20
>    any traffic om this tunnel, except for the BACK = itself,=20 before the
> BACK from the Home Agent has been = received."
>=20
> Furthermore, the
> > mobile node
>=20 >    updates its local Security Association = information=20 to include its
> >    local IPv4 address = and=20 with the remote address being the
> > home agent's
>=20 >    IPv4 address.
>
> I think = this should=20 only be done after the receipt of the BACK from the
> Home=20 Agent.
> IN FACT this needs to be done after the receipt of the = BACK (or=20 be
> completed at this time),
> because only then = will
> the=20 MN know whether there is a NAT or not, so only at this point in time =
>=20 can it appropriately update
> the IPSEc SAs to be RFC 3948 ones = (if=20 required).
>
> >The mobile node also removes binding = update=20 list
> >    entries for correspondent = nodes since=20 route optimisation cannot be
> = >    supported=20 while the mobile node is in an IPv4-only
> > network. This=20 may
> >    cause inbound packet losses as = remote=20 correspondent node
> > are unaware
>=20 >    of such movement. Following this, the = mobile node=20 sends the binding
> >    update message = to the=20 home agent.
> >
> >    Upon = receiving=20 the binding update message, the home agent
> > updates = it
>=20 >    security association
>
> = -->=20 security associations
>=20 =             &= nbsp;         =20 -
>
> locally to include the mobile node's remote
> = >    address as the IP address received in the = outer=20 header. When the
> >    mobile node is = located in=20 a private IPv4 network (which is detected
>=20 >    as described above), this address is the = public=20 address
> > allocated by
> = >    the NAT.=20 Based on the setting of the K flag in the binding update,
>=20 >    the home agent updates its IKE security=20 association to include the
> >    remote = address=20 as that received in the outer header of the binding
>=20 >    update message. If the mobile node were = located in=20 a private IPv4
> >    network this = address is=20 likely to be wrong as the NAT would likely
>=20 >    allocate a different address to the IKE=20 messages.
>
> There is no mentioning of the ports here. = Shouldn't=20 that also be
> mentioned ?
> Further shouldn't we also say = that=20 the type of the tunnel SAs may need
> to changed from
> = 4301 ones=20 to 3948 ones ( [TUNSEC] ?)
>
> Hence, the mobile
>=20 >    node MUST update the IKE SA in one of two = ways as=20 follows.
> > The mobile
> = >    node=20 SHOULD send an empty informational message, which
> > = results in=20 the
> >    IKE module in the home agent = to=20 dynamically update the SA
> = >    information.=20 Alternatively, the IKE SA should be
> > re-negotiated. = Note
>=20 >    that updating the IKE SA MUST take place = after the=20 mobile node has
> >    sent the binding = update=20 and received the acknowledgement from the
>=20 >    home agent.
> >
>=20 >    The mobile node MAY use [MOBIKE] to update = its IKE=20 SA with the home
> >    agent. Using = MOBIKE=20 requires negotiating this capability with the
>=20 >    home agent when establishing the SA. In = this case,=20 the mobile node
> >    and the home agent = need=20 not update their IPsec SAs locally as this
>=20 >    step is performed by MOBIKE. Furthermore, = the use=20 of MOBIKE allows
> >    the mobile node = to=20 update the SA independently of the
> > binding update
> = >    exchange. Hence, there is no need for the = mobile=20 node to wait for a
> >    binding = acknowledgement=20 before performing MOBIKE. The use of MOBIKE
>=20 >    is OPTIONAL in this specification.
> = >
> >
> BR, Karen
>
>=20

 
------=_NextPart_000_004A_01C82BD7.549B8360-- --===============1474753108== 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 --===============1474753108==-- From mext-bounces@ietf.org Tue Nov 20 09:46:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUMU-0006Eb-Au; Tue, 20 Nov 2007 09:46:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUMQ-0006DA-Bo for mext@ietf.org; Tue, 20 Nov 2007 09:45:58 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuUMN-00044x-HW for mext@ietf.org; Tue, 20 Nov 2007 09:45:58 -0500 Received: (qmail 26038 invoked for bounce); 20 Nov 2007 16:51:06 -0000 Received: from unknown (HELO ?130.79.91.222?) (kuntz@unknown) by unknown with RC4-SHA encrypted SMTP; 20 Nov 2007 16:51:06 -0000 Message-Id: From: Romain KUNTZ To: Alexandru Petrescu In-Reply-To: <4742C7C3.6030903@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 20 Nov 2007 15:45:53 +0100 References: <483735.10786.qm@web84112.mail.mud.yahoo.com> <470167CD.8020601@gmail.com> <8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr> <473DC6F2.9060509@gmail.com> <664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr> <47417205.7070805@gmail.com> <4741A405.8070106@gmail.com> <1BEF203C-142F-4089-8DC3-49FF7EC88628@clarinet.u-strasbg.fr> <4742C7C3.6030903@gmail.com> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: mext@ietf.org Subject: [MEXT] Re: [nemo] Prefix Delegation documents 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 On 2007/11/20, at 12:40, Alexandru Petrescu wrote: >> I do not speak only about FQDN, but also and mostly about Domain >> Name + DNS SRV. With that, the client of the service only needs to >> know an usually stable domain name (ok, FT switched to orange for >> some of their services, but such operation is usually done with a >> huge advertisement campaign), and then the HA (hence the HA >> address) can be decided according to the location of the MN, the >> type of service it needs (we can imagine extending the SRV request >> to differentiate mip6, nemo or mcoa services) etc. > > Yes, but when an operator changes the server HA what's easier and > quicker means to update the MN: change HAs SRV entry in DNS or rely > on DHAAD and periodic MPD the MN does? What do you mean by changing the server HA? changing the HA address? I don't really understand what would be the motivation for that, but I don't think an operator would change an HA address without any transition period. So changing the HA SRV entry in DNS is not really a problem. BTW what does MDP would do in that case? If I understand your thoughts, the Home Link prefix is not supposed to change over the time. >>>>>> Using DHAAD means first retrieving the home prefix by a to-be- >>>>>> defined way then using DHAAD, where a DNS lookup or SRV query >>>>>> is a more efficient and already existing protocol. >>>>> But don't you think the same can be said about the FQDN? How >>>>> does MN retrieve its FQDN? >>>> I guess the FQDN or domain name would be given to the user when >>>> it subscribes to the service. Of course you may argue that the >>>> same could apply with the IPv6 home prefix, but I think the DNS >>>> and DNS SRV is more adapted to deployments precisely because the >>>> user is not provisioned with an address. >>> >>> You say so because you assume that the operator will always keep a >>> stable name and may sometime change its addresses if it wants to. >> This is not a question of being able to renumber the home network, >> but being able to give to the MN the more suitable HA address. > > Sounds as a good requirement. > > Another one would be to more efficiently and quickly update the MNs > about a change in the home network. What are the changes you refer to? HA failure? In that case local HA- HA can do the job. I agree DHAAD can also help, but to achieve this we do not need to have the home link IPv6 prefix statically provisionned on the MN. In that case I'd prefer Pascal's proposal (ie retrieving the anycast address using DNS at the bootstrapping, and not provision statically the MN with that address). romain _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 20 10:01: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 1IuUbU-0004Oa-L5; Tue, 20 Nov 2007 10:01:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUbT-0004NB-KK for mext@ietf.org; Tue, 20 Nov 2007 10:01:31 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IuUbT-0005Al-0L for mext@ietf.org; Tue, 20 Nov 2007 10:01:31 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-128.messagelabs.com!1195570889!165490!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29956 invoked from network); 20 Nov 2007 15:01:29 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-128.messagelabs.com with SMTP; 20 Nov 2007 15:01:29 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAKF1Ssu022747; Tue, 20 Nov 2007 08:01:28 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lAKF1SFc020829; Tue, 20 Nov 2007 09:01:28 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lAKF1QDP020806; Tue, 20 Nov 2007 09:01:27 -0600 (CST) Message-ID: <4742F6C6.7040809@gmail.com> Date: Tue, 20 Nov 2007 16:01:26 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Romain KUNTZ References: <483735.10786.qm@web84112.mail.mud.yahoo.com> <470167CD.8020601@gmail.com> <8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr> <473DC6F2.9060509@gmail.com> <664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr> <47417205.7070805@gmail.com> <4741A405.8070106@gmail.com> <1BEF203C-142F-4089-8DC3-49FF7EC88628@clarinet.u-strasbg.fr> <4742C7C3.6030903@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071119-1, 19/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: mext@ietf.org Subject: [MEXT] Re: [nemo] Prefix Delegation documents 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 Romain KUNTZ wrote: > On 2007/11/20, at 12:40, Alexandru Petrescu wrote: >>> I do not speak only about FQDN, but also and mostly about Domain >>> Name + DNS SRV. With that, the client of the service only needs >>> to know an usually stable domain name (ok, FT switched to orange >>> for some of their services, but such operation is usually done >>> with a huge advertisement campaign), and then the HA (hence the >>> HA address) can be decided according to the location of the MN, >>> the type of service it needs (we can imagine extending the SRV >>> request to differentiate mip6, nemo or mcoa services) etc. >> >> Yes, but when an operator changes the server HA what's easier and >> quicker means to update the MN: change HAs SRV entry in DNS or rely >> on DHAAD and periodic MPD the MN does? > > What do you mean by changing the server HA? changing the HA address? Yes. > I don't really understand what would be the motivation for that, but > I don't think an operator would change an HA address without any > transition period. So changing the HA SRV entry in DNS is not really > a problem. Well DNS propagation can take in the order of hours. > BTW what does MDP would do in that case? If I understand your > thoughts, the Home Link prefix is not supposed to change over the > time. Yes, MPD just in case. In case one wants to reuse MPD to obtain the most up to date prefix from the home link (before configuring the Home Address), maybe the home link is about to be renumbered. This was designed with the same transitioning period in mind you mention about DNS. >>>>>>> Using DHAAD means first retrieving the home prefix by a >>>>>>> to-be-defined way then using DHAAD, where a DNS lookup or >>>>>>> SRV query is a more efficient and already existing >>>>>>> protocol. >>>>>> But don't you think the same can be said about the FQDN? >>>>>> How does MN retrieve its FQDN? >>>>> I guess the FQDN or domain name would be given to the user >>>>> when it subscribes to the service. Of course you may argue >>>>> that the same could apply with the IPv6 home prefix, but I >>>>> think the DNS and DNS SRV is more adapted to deployments >>>>> precisely because the user is not provisioned with an >>>>> address. >>>> >>>> You say so because you assume that the operator will always >>>> keep a stable name and may sometime change its addresses if it >>>> wants to. >>> This is not a question of being able to renumber the home >>> network, but being able to give to the MN the more suitable HA >>> address. >> >> Sounds as a good requirement. >> >> Another one would be to more efficiently and quickly update the MNs >> about a change in the home network. > > What are the changes you refer to? HA failure? In that case local > HA-HA can do the job. :-) err... local HA-HA... new messages. Let's talk about a requirement that says minimal MIP6 implementation extension :-) > I agree DHAAD can also help, but to achieve this we do not need to > have the home link IPv6 prefix statically provisionned on the MN. In > that case I'd prefer Pascal's proposal (ie retrieving the anycast > address using DNS at the bootstrapping, and not provision statically > the MN with that address). Sounds as a good possibility to which I'd agree. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 20 10:52:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuVO6-0008Ke-7o; Tue, 20 Nov 2007 10:51:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuVO3-0008KU-CX for mext@ietf.org; Tue, 20 Nov 2007 10:51:43 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuVO0-00068o-RF for mext@ietf.org; Tue, 20 Nov 2007 10:51:43 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lAKFpcP26850 for ; Tue, 20 Nov 2007 15:51:39 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C82B8D.3ADC055A" Date: Tue, 20 Nov 2007 09:51:34 -0600 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-muhanna-mip6-binding-revocation-02.txt Thread-Index: AcgqgThaRU7gpCm3QcmQL+DW5ZID8ABCwX0A From: "Ahmad Muhanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Subject: [MEXT] FW: I-D Action:draft-muhanna-mip6-binding-revocation-02.txt 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C82B8D.3ADC055A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, Please take a look at the new revision of Binding Revocation draft. We added the following: ----------------------- 1. support for Monami6 (Revocation of Multi-Care of addresses bindings)=20 2. Allowing the MAG to send de-registration (P-BU with lifetime=3Dzero) = in case of a single binding revocation. 3. Explicit definition of what options are used to identify each specific revocation scenario 3. Incorporated many comments as per the MIP6 mailing list discussion. We appreciate your review and comments. Thanks in advance! Regards, Ahmad -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Monday, November 19, 2007 1:50 AM To: i-d-announce@ietf.org Subject: I-D Action:draft-muhanna-mip6-binding-revocation-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-muhanna-mip6-binding-revocation-02.txt Pages : 22 Date : 2007-11-19 This document defines the revocation semantics for terminating a mobile node's mobility session. These semantics are generic enough and can be applied in both client-based and network-based mobility management protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revocatio n-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-muhanna-mip6-binding-revocation-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-muhanna-mip6-binding-revocation-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_001_01C82B8D.3ADC055A Content-Type: application/octet-stream; name="ATT4524779.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT4524779.TXT Content-Disposition: attachment; filename="ATT4524779.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNy0xMS0xOTAyNDMwMC5JLURAaWV0Zi5vcmc+DQoNCkVO Q09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tdWhhbm5hLW1pcDYtYmlu ZGluZy1yZXZvY2F0aW9uLTAyLnR4dA0K ------_=_NextPart_001_01C82B8D.3ADC055A Content-Type: application/octet-stream; name="draft-muhanna-mip6-binding-revocation-02.URL" Content-Transfer-Encoding: base64 Content-Description: draft-muhanna-mip6-binding-revocation-02.URL Content-Disposition: attachment; filename="draft-muhanna-mip6-binding-revocation-02.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1tdWhhbm5hLW1pcDYtYmluZGluZy1yZXZvY2F0aW9uLTAyLnR4dA0K ------_=_NextPart_001_01C82B8D.3ADC055A Content-Type: text/plain; name="ATT4524780.txt" Content-Transfer-Encoding: base64 Content-Description: ATT4524780.txt Content-Disposition: attachment; filename="ATT4524780.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C82B8D.3ADC055A 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 ------_=_NextPart_001_01C82B8D.3ADC055A-- From mext-bounces@ietf.org Tue Nov 20 11:51: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 1IuWJX-0007u3-D9; Tue, 20 Nov 2007 11:51:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuWJW-0007l1-HY; Tue, 20 Nov 2007 11:51:06 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuWJU-0000Hi-4x; Tue, 20 Nov 2007 11:51:04 -0500 Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Nov 2007 08:51:02 -0800 Message-ID: <4743106B.6000601@azairenet.com> Date: Tue, 20 Nov 2007 08:50:51 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: mext@ietf.org, mip6@ietf.org, Basavaraj Patil Subject: Re: [MEXT] MEXT starts now References: <47420EBD.8040303@piuha.net> In-Reply-To: <47420EBD.8040303@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Nov 2007 16:51:02.0942 (UTC) FILETIME=[890B9BE0:01C82B95] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 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 Special thanks to Raj for chairing the MIP6 WG (and the earlier Mobile IP WG) for 8 years! Mobile IP and MIP6 have always been "exciting" WGs and Raj had always had his hands full. :) Vijay Jari Arkko wrote: > Hi all, > > I'm happy to announce that MEXT is now finally created. Marcelo > Braun and Julien Laganier are the new chairs. Please join me > in welcoming them and thanking them for taking up this task! > > Their first task is to organize the agenda and meeting in > Vancouver, so send mail to them for agenda slots and other > requests. > > The IETF secretary is working on the WG web page updates and > other practical details. The two slots for MIP6 in the current > agenda will be renamed to MEXT slots. > > I would also like to thank the chairs of the three WGs that will > now be merged into one: Thierry, Gopal, Basavaraj, TJ, and > Nicolas -- big thanks for your hard work over the years! > > Jari Arkko > > > _______________________________________________ > 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 Nov 20 12:01: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 1IuWTD-0000iB-Jj; Tue, 20 Nov 2007 12:01:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuWTB-0000gc-G0; Tue, 20 Nov 2007 12:01:05 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuWT9-0008A0-98; Tue, 20 Nov 2007 12:01:05 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lAKH0ua12079; Tue, 20 Nov 2007 17:00:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] MEXT starts now Date: Tue, 20 Nov 2007 11:00:20 -0600 Message-ID: In-Reply-To: <4743106B.6000601@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] MEXT starts now Thread-Index: AcgrlbLAGawV1qPhTvC/b/X2UOa9ewAABAxQ References: <47420EBD.8040303@piuha.net> <4743106B.6000601@azairenet.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , , , "Basavaraj Patil" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: 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 >=20 > Special thanks to Raj for chairing the MIP6 WG (and the=20 > earlier Mobile IP WG) for 8 years! Mobile IP and MIP6 have=20 > always been "exciting" WGs and Raj had always had his hands full. :) [Ahmad] Agree completely.=20 Many thanks to you Raj! >=20 > Vijay >=20 > Jari Arkko wrote: > > Hi all, > >=20 > > I'm happy to announce that MEXT is now finally created.=20 > Marcelo Braun=20 > > and Julien Laganier are the new chairs. Please join me in welcoming=20 > > them and thanking them for taking up this task! > >=20 > > Their first task is to organize the agenda and meeting in=20 > Vancouver,=20 > > so send mail to them for agenda slots and other requests. > >=20 > > The IETF secretary is working on the WG web page updates and other=20 > > practical details. The two slots for MIP6 in the current=20 > agenda will=20 > > be renamed to MEXT slots. > >=20 > > I would also like to thank the chairs of the three WGs that=20 > will now=20 > > be merged into one: Thierry, Gopal, Basavaraj, TJ, and=20 > Nicolas -- big=20 > > thanks for your hard work over the years! > >=20 > > Jari Arkko > >=20 > >=20 > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 20 12:24: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 1IuWpH-0004Bf-GO; Tue, 20 Nov 2007 12:23:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuWpG-0004BV-V0 for mext@ietf.org; Tue, 20 Nov 2007 12:23:54 -0500 Received: from rv-out-0910.google.com ([209.85.198.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuWpD-0000hs-Q7 for mext@ietf.org; Tue, 20 Nov 2007 12:23:54 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1610548rvb for ; Tue, 20 Nov 2007 09:23:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=+t0vo1Ds5/XKZvRHO14C5zmOyQUfjtI3Hi2rWByujTI=; b=gVeooahZqtzWu6cen7khkdTMWmwPMMUOeWeC22Vs3dtUrNrldBH62lwP8OszCuzxEvUE5Tn1oFg7zsk38urzARBdYmg2iJ9jV/Km5weM36EiFCAXVnhNszNnB/C9oLB0e9bWpl1jnoTlrZPqpdewB8raZlpIKkQeXs/wZ4BZDNQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=FfSemQ35BScd7iXJHOx9KhXIPIv+/ZgS2MlhL6nmK8LEF1OqefO3vUH+xJq5Si1O2O9nNTBplZIfX4V/GfGJ2X5tPjNMHAPXscuBvx/JEsapGvZmlqjZXmmyrZylpb6uDNdL1f5+Rxy/PijtITWrNJyZNGkqGA+EwT3vgIRvdf8= Received: by 10.140.188.10 with SMTP id l10mr2480408rvf.1195579430761; Tue, 20 Nov 2007 09:23:50 -0800 (PST) Received: by 10.141.177.11 with HTTP; Tue, 20 Nov 2007 09:23:50 -0800 (PST) Message-ID: Date: Tue, 20 Nov 2007 17:23:50 +0000 From: "George Tsirtsis" To: mext@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [MEXT] Comments on draft-ietf-monami6-mipv6-analysis-04 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="===============2086087816==" Errors-To: mext-bounces@ietf.org --===============2086087816== Content-Type: multipart/alternative; boundary="----=_Part_14076_15886807.1195579430741" ------=_Part_14076_15886807.1195579430741 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, I have been reading draft-ietf-monami6-mipv6-analysis-04 and I have to say I am a bit confused. The draft certainly contains a lot of interesting material but the information contained may not be structured as well as it could or should. The following comments might seem a bit too generic and I apologize in advance if some of these issues have already been discussed or if the authors are in the process of fixing. Section 5 provides a comprehensive list of multi-homing scenarios. For each case a description of the scenario is given e.g., (1,1), (1,n) etc and then the "current situation with MIPv6" is discussed. This latter part, I think, needs to be split in two parts. One part really discussing what MIPv6 offers in the given scenario and then possibly at a high level what improvements or additional functionality could be considered. At the moment these two things are done together resulting in a lot of confusion...at least to me :-) In general a possible restructuring of the document would discuss specific scenarios, identify how MIPv6 deals (or does not deal) with each scenario ( i.e., section 5) and then a mini problem statement for each MIPv6 "inadequacy" could be provided (section 6...more or less). Another general observation is that some terms are used lightly and are not defined properly. For example, the terms "transparent", and "load sharing" are causing me concern in the context of the document. Certain events are characterized as "transparent" or "non-transparent" but it is not obvious to who the transparency refers to (the MN? the HA? the CN? other?). "Load sharing" some times seems to refer to running apps on different HoAs, or even interfaces (?), and other times seems to refer to pointing flows running on the same HoA to different CoAs (but then how is this different from Flow Distribution?). "Reliability" also means different things at different times e.g., ability to survive CoA failure, HoA failure, HA failure etc....but it is not always clear which type of reliability is talked about. Finally, the document discusses multiple HoAs for the same MN as if MIPv6 is already somehow covering this case. It is not, for example, made clear that as far as MIPv6 is concerned, each HoA represent a separate MIPv6 session, and that an MN with multiple HoAs has to maintain multiple MIPv6 session, which from the HA's perspective look like they belong to different MNs altogether. This is implied if you read between the lines but the significance of the point is lost, while the discussion also fails to make clear whether such an assumption should be reexamined. Best Regards George P.S.: Just so I know...are the monami6 (and drafts of other WGs now under MEXT) be republished as draft-ietf-mext-? ------=_Part_14076_15886807.1195579430741 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi All,
 
I have been reading draft-ietf-monami6-mipv6-analysis-04 and I have to say I am a bit confused.
The draft certainly contains a lot of interesting material but the information contained may not be structured as well as it could or should.
The following comments might seem a bit too generic and I apologize in advance if some of these issues have already been discussed or if the authors are in the process of fixing.
 
Section 5 provides a comprehensive list of multi-homing scenarios. For each case a description of the scenario is given e.g., (1,1), (1,n) etc and then the "current situation with MIPv6" is discussed. This latter part, I think, needs to be split in two parts. One part really discussing what MIPv6 offers in the given scenario and then possibly at a high level what improvements or additional functionality could be considered. At the moment these two things are done together resulting in a lot of confusion...at least to me :-) In general a possible restructuring of the document would discuss specific scenarios, identify how MIPv6 deals (or does not deal) with each scenario ( i.e., section 5) and then a mini problem statement for each MIPv6 "inadequacy" could be provided (section 6...more or less).
 
Another general observation is that some terms are used lightly and are not defined properly. For example, the terms "transparent", and "load sharing" are causing me concern in the context of the document. Certain events are characterized as "transparent" or "non-transparent" but it is not obvious to who the transparency refers to (the MN? the HA? the CN? other?). "Load sharing" some times seems to refer to running apps on different HoAs, or even interfaces (?), and other times seems to refer to pointing flows running on the same HoA to different CoAs (but then how is this different from Flow Distribution?). "Reliability" also means different things at different times e.g., ability to survive CoA failure, HoA failure, HA failure etc....but it is not always clear which type of reliability is talked about.
 
Finally, the document discusses multiple HoAs for the same MN as if MIPv6 is already somehow covering this case. It is not, for example, made clear that as far as MIPv6 is concerned, each HoA represent a separate MIPv6 session, and that an MN with multiple HoAs has to maintain multiple MIPv6 session, which from the HA's perspective look like they belong to different MNs altogether. This is implied if you read between the lines but the significance of the point is lost, while the discussion also fails to make clear whether such an assumption should be reexamined.
 
Best Regards
George
P.S.: Just so I know...are the monami6 (and drafts of other WGs now under MEXT) be republished as draft-ietf-mext-?
 
------=_Part_14076_15886807.1195579430741-- --===============2086087816== 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 --===============2086087816==-- From mext-bounces@ietf.org Tue Nov 20 12:36: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 1IuX11-0004by-Rt; Tue, 20 Nov 2007 12:36:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuX0z-0004Ta-EB; Tue, 20 Nov 2007 12:36:01 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuX0x-0001Bz-La; Tue, 20 Nov 2007 12:36:01 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lAKHZgiv031306; Tue, 20 Nov 2007 19:35:50 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 19:34:49 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 11:34:42 -0600 Received: from 10.241.58.186 ([10.241.58.186]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Nov 2007 17:34:41 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Tue, 20 Nov 2007 09:34:47 -0800 Subject: Re: [MEXT] MEXT starts now From: Rajeev Koodli To: ext Vijay Devarapalli , , , Basavaraj Patil Message-ID: Thread-Topic: [MEXT] MEXT starts now Thread-Index: Acgrm6Ub48xOo5eOEdy2twAWy5YJpw== In-Reply-To: <4743106B.6000601@azairenet.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Nov 2007 17:34:42.0495 (UTC) FILETIME=[A26BACF0:01C82B9B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: 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. -Rajeev -- http://people.nokia.net/~rajeev On 11/20/07 8:50 AM, "ext Vijay Devarapalli" wrote: > Special thanks to Raj for chairing the MIP6 WG (and the earlier > Mobile IP WG) for 8 years! Mobile IP and MIP6 have always been > "exciting" WGs and Raj had always had his hands full. :) > > Vijay > > Jari Arkko wrote: >> Hi all, >> >> I'm happy to announce that MEXT is now finally created. Marcelo >> Braun and Julien Laganier are the new chairs. Please join me >> in welcoming them and thanking them for taking up this task! >> >> Their first task is to organize the agenda and meeting in >> Vancouver, so send mail to them for agenda slots and other >> requests. >> >> The IETF secretary is working on the WG web page updates and >> other practical details. The two slots for MIP6 in the current >> agenda will be renamed to MEXT slots. >> >> I would also like to thank the chairs of the three WGs that will >> now be merged into one: Thierry, Gopal, Basavaraj, TJ, and >> Nicolas -- big thanks for your hard work over the years! >> >> Jari Arkko >> >> >> _______________________________________________ >> 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 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 20 13:17:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXfE-0000Q1-7f; Tue, 20 Nov 2007 13:17:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXfC-0000Mi-To; Tue, 20 Nov 2007 13:17:34 -0500 Received: from p130.piuha.net ([2001:14b8:400::130] helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuXfA-0002kX-U9; Tue, 20 Nov 2007 13:17:33 -0500 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 4028219867C; Tue, 20 Nov 2007 20:17:32 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id D2F02198670; Tue, 20 Nov 2007 20:17:31 +0200 (EET) Message-ID: <474324BB.5050305@piuha.net> Date: Tue, 20 Nov 2007 20:17:31 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: Vijay Devarapalli , Basavaraj Patil Subject: Re: [MEXT] MEXT starts now References: <47420EBD.8040303@piuha.net> <4743106B.6000601@azairenet.com> In-Reply-To: <4743106B.6000601@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: mip6@ietf.org, 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 Indeed. Its a long time. Thanks, Raj. Jari Vijay Devarapalli kirjoitti: > Special thanks to Raj for chairing the MIP6 WG (and the earlier > Mobile IP WG) for 8 years! Mobile IP and MIP6 have always been > "exciting" WGs and Raj had always had his hands full. :) > > Vijay > > Jari Arkko wrote: >> Hi all, >> >> I'm happy to announce that MEXT is now finally created. Marcelo >> Braun and Julien Laganier are the new chairs. Please join me >> in welcoming them and thanking them for taking up this task! >> >> Their first task is to organize the agenda and meeting in >> Vancouver, so send mail to them for agenda slots and other >> requests. >> >> The IETF secretary is working on the WG web page updates and >> other practical details. The two slots for MIP6 in the current >> agenda will be renamed to MEXT slots. >> >> I would also like to thank the chairs of the three WGs that will >> now be merged into one: Thierry, Gopal, Basavaraj, TJ, and >> Nicolas -- big thanks for your hard work over the years! >> >> Jari Arkko >> >> >> _______________________________________________ >> 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 Nov 20 13:23: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 1IuXl0-000184-B3; Tue, 20 Nov 2007 13:23:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXky-00017I-R7; Tue, 20 Nov 2007 13:23:32 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuXky-0004Ev-A0; Tue, 20 Nov 2007 13:23:32 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lAKINNuC025539; Tue, 20 Nov 2007 20:23:25 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 20:23:18 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 12:23:15 -0600 Received: from 10.241.58.4 ([10.241.58.4]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Nov 2007 18:23:15 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 20 Nov 2007 12:23:16 -0600 Subject: Re: [MEXT] MEXT starts now From: Basavaraj Patil To: ext Jari Arkko , Vijay Devarapalli Message-ID: Thread-Topic: [MEXT] MEXT starts now Thread-Index: AcgromsBqU6cJpeVEdyXpQARJNUNiA== In-Reply-To: <474324BB.5050305@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Nov 2007 18:23:15.0473 (UTC) FILETIME=[6AB0D810:01C82BA2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: mip6@ietf.org, 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 Much appreciated. It has been possible only because of an excellent support cast in the mobility area. It has been a pleasure working with all of you. I wish the MEXT chairs good luck. Cheers, -Raj On 11/20/07 12:17 PM, "ext Jari Arkko" wrote: > Indeed. Its a long time. Thanks, Raj. > > Jari > > Vijay Devarapalli kirjoitti: >> Special thanks to Raj for chairing the MIP6 WG (and the earlier >> Mobile IP WG) for 8 years! Mobile IP and MIP6 have always been >> "exciting" WGs and Raj had always had his hands full. :) >> >> Vijay >> >> Jari Arkko wrote: >>> Hi all, >>> >>> I'm happy to announce that MEXT is now finally created. Marcelo >>> Braun and Julien Laganier are the new chairs. Please join me >>> in welcoming them and thanking them for taking up this task! >>> >>> Their first task is to organize the agenda and meeting in >>> Vancouver, so send mail to them for agenda slots and other >>> requests. >>> >>> The IETF secretary is working on the WG web page updates and >>> other practical details. The two slots for MIP6 in the current >>> agenda will be renamed to MEXT slots. >>> >>> I would also like to thank the chairs of the three WGs that will >>> now be merged into one: Thierry, Gopal, Basavaraj, TJ, and >>> Nicolas -- big thanks for your hard work over the years! >>> >>> Jari Arkko >>> >>> >>> _______________________________________________ >>> 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 Nov 20 13:45: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 1IuY6A-000898-RJ; Tue, 20 Nov 2007 13:45:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuY6A-00088r-9w for mext@ietf.org; Tue, 20 Nov 2007 13:45:26 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuY69-0005Ty-VB for mext@ietf.org; Tue, 20 Nov 2007 13:45:26 -0500 Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Nov 2007 10:45:24 -0800 Message-ID: <47432B43.5020100@azairenet.com> Date: Tue, 20 Nov 2007 10:45:23 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: [MEXT] Re: [nemo] Prefix Delegation documents References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> In-Reply-To: <006a01c82b48$de794bb0$9b6be310$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Nov 2007 18:45:24.0820 (UTC) FILETIME=[830B1940:01C82BA5] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Teco Boot wrote: > Hi Pascal, > Question on WG documents for prefix delegation. There are two of them: > 1: draft-ietf-nemo-prefix-delegation-02.txt (August 21, 2007) > 2: draft-ietf-nemo-dhcpv6-pd-02.txt (September 28, 2006) > Are we still working on both solutions? We have a sort of stalemate on this. I believe Jari (AD) would prefer one solution in this space. I think the earlier decision by the NEMO WG was to standardize both solutions. Not sure what the consensus is right now. IMO, we should standardize one ASAP. Without a prefix delegation mechanism the only possible solution now is to pre-configure the mobile network prefix on the mobile router. This is not sufficient. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 20 15:02: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 1IuZId-0003Dj-3S; Tue, 20 Nov 2007 15:02:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZIa-0003DW-U2 for mext@ietf.org; Tue, 20 Nov 2007 15:02:20 -0500 Received: from an-out-0708.google.com ([209.85.132.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuZIW-0007Pr-EO for mext@ietf.org; Tue, 20 Nov 2007 15:02:20 -0500 Received: by an-out-0708.google.com with SMTP id d11so520014and for ; Tue, 20 Nov 2007 12:02:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=Y1RD2D4O1iTb8X834M2h2ytfk5luufeih2aGqFYaP4Q=; b=KeG/waG68nrww9So46t/7uaPz9U9EUnO4QtZ8pJUTGexhGXLB6CTo9YqrG4JYqtAk+KzMPumMTRkLtslHTV9nhuVlCoPsdRjM7j2gIs68PLXiiIwAGveQbkdqrrwg1JS4DyN00oor5fazIePT5XIiWd/sj+wQ+ZHRdnJlHfBDTU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=P9ehR03MYfFj20hytd5iFUwT/b39yFkKAEb0LMxN5icBpfOk8PRwGLsuNei2ADs6oolaQFGIGpe1EBUMHb1Dspm9hPj14/zHma6W/QroIYA+4hpS5My6WWzyVlax+W1bkd35t1xxKx6m9eaodW6fMUWBLkMGRj2/PJxUGHSx6sE= Received: by 10.100.107.7 with SMTP id f7mr8028563anc.1195588935930; Tue, 20 Nov 2007 12:02:15 -0800 (PST) Received: from ?10.105.16.31? ( [12.192.138.120]) by mx.google.com with ESMTPS id f78sm18447267pyh.2007.11.20.12.02.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Nov 2007 12:02:12 -0800 (PST) Message-ID: <47433D30.2020605@gmail.com> Date: Tue, 20 Nov 2007 14:01:52 -0600 From: Sebastian Thalanany User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pthubert@cisco.com Subject: Re: [MEXT] Re: [nemo] Prefix Delegation documents References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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, Pascal, Yes, I agree. The configuration options to use DNS for an anycast address resolution should be an operator choice. Thanks. Regards, Sebastian Pascal Thubert (pthubert) wrote: >I'd say that one does not preclude the other. We could use DNS to get >the anycast address and leave the dynamics of load balancing to the >DHAAD process. > >Pascal > > >>-----Original Message----- >>From: Romain KUNTZ [mailto:kuntz@clarinet.u-strasbg.fr] >>Sent: Monday, November 19, 2007 2:51 PM >>To: Alexandru Petrescu >>Cc: mext@ietf.org >>Subject: [MEXT] Re: [nemo] Prefix Delegation documents >> >>On 2007/11/19, at 12:22, Alexandru Petrescu wrote: >> >> >>>>>I see it differently. I see it as the MIP6 bootstrapping work >>>>>_should_ >>>>>rely on DHAAD to assign the HA address. >>>>> >>>>>(I've always wondered how could the MIP6 bootstrapping work simply >>>>>ignore the existence of DHAAD.) >>>>> >>>>> >>>>DHAAD relies on the fact that the home prefix is known whereas MIP6 >>>>bootstrapping does not. >>>> >>>> >>>But Romain, the MN always has to have some pre-configured >>>information before being able to acquire the HA address and HoA. >>> >>>If MIP6 Bootstrapping pre-configures a NAI, or maybe a FQDN of the >>>home domain - don't you think one can easily say that "MIP6 >>>bootstrapping relies on the fact that the NAI or the FQDN is known >>>whereas DHAAD does not" - and thus make it look as an inconvenient? >>> >>> >>But from a deployment point of view, having a statically configured >>FQDN or just the domain name of the mobility operator is better than >>an IPv6 prefix, no? >> >> >> >>>>Using DHAAD means first retrieving the home prefix by a to-be- >>>>defined way then using DHAAD, where a DNS lookup or SRV query is a >>>>more efficient and already existing protocol. >>>> >>>> >>>But don't you think the same can be said about the FQDN? How does >>>MN retrieve its FQDN? >>> >>> >>I guess the FQDN or domain name would be given to the user when it >>subscribes to the service. Of course you may argue that the same could >>apply with the IPv6 home prefix, but I think the DNS and DNS SRV is >>more adapted to deployments precisely because the user is not >>provisioned with an address. >> >>romain >> >>_______________________________________________ >>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 > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From GrahamfloridianOrr@suburbanchicagonews.com Wed Nov 21 05:00:02 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IumNG-00011y-Ds for nemo-archive@lists.ietf.org; Wed, 21 Nov 2007 05:00:02 -0500 Received: from pool-71-255-244-147.washdc.east.verizon.net ([71.255.244.147] helo=acerc28991bd48) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IumNG-0002DH-5A for nemo-archive@lists.ietf.org; Wed, 21 Nov 2007 05:00:02 -0500 Received: from gawk by suburbanchicagonews.com with SMTP id usIEoByX1V for ; Wed, 21 Nov 2007 04:59:22 +0500 From: "Joesph Carey" To: Subject: Get $555 you download our casino. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Make Vegas your playing ground, wherever you are, with Vegas VIP. Play today and receive up to $555 in Welcome bonuses to make the experience that much sweeter! How does this great deal work? 1st deposit - 200% bonus, worth up to $200 2nd desposit - 100% bonus, worth up to $100 3rd deposit - 155% bonus, worth up to $155 4th deposit - 100% bonus, worth up to $100 Vegas VIP uses the securest and most realistic gaming software to guarantee you get the safest, most exciting playing experience available online today, and tomorrow! Take advantage today and you too could see your dreams come true http://eurocasinoau.com/ From mext-bounces@ietf.org Wed Nov 21 05:34: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 1Iumtl-0004a7-89; Wed, 21 Nov 2007 05:33:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iumtj-0004a1-9G for mext@ietf.org; Wed, 21 Nov 2007 05:33:35 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iumti-0003Cz-MB for mext@ietf.org; Wed, 21 Nov 2007 05:33:35 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lALAXEBw004737; Wed, 21 Nov 2007 12:33:19 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 12:33:04 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 12:33: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 Date: Wed, 21 Nov 2007 12:33:03 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Security considerations text Thread-Index: AcgqUDDWggKB3XbESNy3EZ1ND52YaQANM4RwAADdY5AAAIGScAAJoISgAF2yPKA= References: From: To: , X-OriginalArrivalTime: 21 Nov 2007 10:33:04.0134 (UTC) FILETIME=[E5D5E260:01C82C29] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Subject: [MEXT] RE: Security considerations text 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 Hesham Soliman wrote: > Folks,=20 >=20 > This is the current text in the draft. If there are comments we can > add them to the IESG comments, provided there are no major problems > here. Thanks for all the comments. Special thanks to Pasi and Karen > for developing the solution. Couple of small comments: > In cases where this specification is used for NAT traversal, it > is important to note that it has the same UNSAF vulnerabilities > associated with RFC 3519. "The same NAT-related security vulnerabilities as RFC 3519" would=20 be more accurate, as neither this nor RFC 3519 is actually an=20 "Unilateral Self-Address Fixing" (UNSAF) mechanism. > 5.1 Handover interactions for IPsec and IKE >=20 > After the mobile node detects movement it updates its tunnel > information depending on the network capability. If the new link > is IPv4-only then the mobile node updates its tunnel to UDP using > the DSMIPv6 port and the local IPv4 address. Furthermore, the > mobile node updates its local Security Association information to > include its local IPv4 address and with the remote address being > the home agent's IPv4 address. Tunnel mode SAs have two distinct fields, "local address" and "tunnel header IP source address" (also "local tunnel header address" would be IMHO acceptable), and it's the latter we're updating here. Same bug occurs also later in the text (and also with "remote address"). > The mobile node also removes binding update list entries for > correspondent nodes since route optimisation cannot be supported > while the mobile node is in an IPv4-only network. And also "binding cache" entries. > If the mobile node were located in a private IPv4 > network this address is likely to be wrong as the NAT=20 > would likely allocate a different address to the IKE messages.=20 Should also mention port number, which is certain to be wrong. As Karen already pointed out, DSMIPv6 also needs to update the "NAT traversal" state of the IKE_SA, and "UDP encapsulation" mode of IPsec SAs. Best regards, Pasi _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Nov 21 08:41: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 1Iupp8-0005oT-1y; Wed, 21 Nov 2007 08:41:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iupp6-0005jc-IK for mext@ietf.org; Wed, 21 Nov 2007 08:41:00 -0500 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iupp3-0005Bp-S7 for mext@ietf.org; Wed, 21 Nov 2007 08:41:00 -0500 Received: by nz-out-0506.google.com with SMTP id n1so1873211nzf for ; Wed, 21 Nov 2007 05:40:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=8cfUUP5E7ZE0/AWODxXudf/PlOGcPnnh5WOtSaJGxgo=; b=gJoWX6mQF1sQU4OmKpAWguAONYItJ63clDb26hzrEI6SPTUI0iMtF5NYMsD/kzHhw/3qcIBLzCMt0R/hxd6S9ueSSfRDLuISy8Src/Vc9rqGi6gjrv26fL/79ZQeTxCw/KtnaXsD+Wmbe9NqTgYnwovVx8U+YjtF8pCnqfVisY0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=U5FDHXNsXCRsyWQiMzK3IYIKZ63qOqGX45mSo5ZNHhpUAEXkh0EazhOpeXda7czOjDvZ+s/bdUtSBIbzoePFfFQzFtoXnVUXmk3hH3YZL+PsEzfutNCSzf80qK9unEgGnQkjWmWn/CGVzqsmPlkeZvHQVuBGFDktkX3IYevypOI= Received: by 10.141.74.17 with SMTP id b17mr3308384rvl.1195652453863; Wed, 21 Nov 2007 05:40:53 -0800 (PST) Received: by 10.141.177.11 with HTTP; Wed, 21 Nov 2007 05:40:53 -0800 (PST) Message-ID: Date: Wed, 21 Nov 2007 13:40:53 +0000 From: "George Tsirtsis" To: mext@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9aa22b77adc37e7d33e29644e4dc0b33 Subject: [MEXT] was Re: [Monami6] returning home issue in MCoA 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="===============1113624792==" Errors-To: mext-bounces@ietf.org --===============1113624792== Content-Type: multipart/alternative; boundary="----=_Part_17414_32241127.1195652453842" ------=_Part_17414_32241127.1195652453842 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline To respond to Nikolas initial question on this issue I think that simultaneous home-foreign connectivity issues should be discussed and resolved as part of the MCoA draft. In any case Ryuji already listed a number of options, not all of which are too complex. It seems to me that ND proxying or not, by who, and when is the only remaining question :-) I have to say that the H flag and the description of this in MCoA-v4 is not yet clear enough so there is certainly more work to be done here. I am also going to send additional comments on the MCoA draft separately. Thanks George P.S.: I moved this to MEXT list now, and below is the last e-mail I received on this issue on monami6 list....not sure if I missed anything in between. -----Original Message----- From: Keigo Aso [mailto:asou.keigo@jp.panasonic.com] Sent: Monday, November 19, 2007 1:52 AM To: Monami6 WG Subject: Re: [Monami6] returning home issue in MCoA Hi Ryuji, On Sun, 18 Nov 2007 11:36:49 +0900 RYUJI WAKIKAWA wrote: > Hi Vijay, > > On 2007/11/18, at 7:05, Vijay Devarapalli wrote: > > > RYUJI WAKIKAWA wrote: > > > >>> But now I puzzled why the HA would be turning of proxy ND? I think > >>> the HA should still continue proxying the home address of the mobile > >>> node and intercept the packets. > >> Then, HA and MN will meet the address duplication. > >> MN tries to defend its HoA on the home link and HA also tries to do > >> the same by Proxy ND. > > > > No. The MN does not attempt to defend its address when it knows > > that it has another binding from a visited link. It knows that > > the HA will be proxying its home address. Basically the HA would > > defined whether to send the traffic directly to the home address > > on the link or tunnel to the CoA that the MN has registered at > > the HA. The HA would make the decision based on the type of > > packet/flow.. > > > >>> The HA then decides how to forward the packet. If the packet is > >>> meant the MN interface which is not attached to the home link, the > >>> packet should be tunneled to the mobile node on the visited link. If > >>> the packet is meant for the MN interface which is attached to the > >>> home link, the HA delivers it directly. The tricky part would be to > >>> create a neighbor cache entry for the mobile node so that the HA > >>> can deliver the packet on-link. The HA would need to know the L2 > >>> address of the interface with which the mobile node is attached to > >>> the home link. > >> Do you suggest to modify ND parts for this? > > > > Is there a need to modify neighbor discovery? As long as the > > HA has the layer 2 address that corresponds to the interface > > with which the mobile node is attached to the home link, it can > > construct a neighbor cache entry or for example construct the > > ether header. > > It sounds similar to the MN's operation of sending dereg-BU from home > link. > > - How can HA learn the MN's L2 address. > - when MN communicates with CN on the home link, the packets are > always routed through the HA > - Regardless of binding status, HA MUST defend the HoA at the home link. > While MN is back to home with multiple bindings, HA will intercept > all the packets and decides how to deliver the packets to MN. However, > if MN stop using the interfaces attached to foreign link, HA will no > longer defend the HoA. It means MN MUST start defending own HoA at the > home link. I think this is a bit tricky. HA should do proxy NDP for > HoA regardless of binding status of MN. > - From the implementation experience of returning home, it is very > hard to implement this;-p I think it is better to assume HA is a router on the home link as described in your draft no-ndp-00 in order to avoid to introduce needless complexity here. When MN connects to both home and foreign link, if HA can see all packets for the HoA of the MN by IP routing, it would not need to do proxy ND for intercepting packets. MN can do ND for own HoA here. While, when MN's both interfaces connects to foreign link, HA should do proxy ND for defending the HoA of the MN, according to RFC3775. And, I agree with Vijay's comments. Even when MN connects to both home and foreign link, HA can do proxy ND for the network which its egress interface connects to for intercepting packets for the HoA of the MN. In this case, I think it is better for HA to stop proxy ND for the home link. If so, MN can start ND for defeinding own HoA and HA can know MN's L2 address. There is no change on ProxyND in home link defined by RFC3775. Regards, Keigo > > ryuji > > > > > Vijay > > > >> ryuji > >>> > >>> > >>> Vijay > >>> > >>>> If you answer YES to the question above, > >>>> Should MCoA document support this feature? > >>>> [ ] YES > >>>> [ ] NO (not in MCoA, but in a separate document) > >>>> The deadline for this consensus call is October the 8th 2007. > >>>> Thank you, > >>>> Monami6 chairs > >>>> _______________________________________________ > >>>> Monami6 mailing list > >>>> Monami6@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/monami6 > >>> > >>> > >>> _______________________________________________ > >>> Monami6 mailing list > >>> Monami6@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/monami6 > >> _______________________________________________ > >> Monami6 mailing list > >> Monami6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/monami6 > > > > > > _______________________________________________ > > Monami6 mailing list > > Monami6@ietf.org > > https://www1.ietf.org/mailman/listinfo/monami6 > > > _______________________________________________ > Monami6 mailing list > Monami6@ietf.org > https://www1.ietf.org/mailman/listinfo/monami6 _______________________________________________ Monami6 mailing list Monami6@ietf.org https://www1.ietf.org/mailman/listinfo/monami6 ------=_Part_17414_32241127.1195652453842 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
To respond to Nikolas initial question on this issue I think that simultaneous home-foreign connectivity issues should be discussed and resolved as part of the MCoA draft. In any case Ryuji already listed a number of options, not all of which are too complex. It seems to me that ND proxying or not, by who, and when is the only remaining question :-)
 
I have to say that the H flag and the description of this in MCoA-v4 is not yet clear enough so there is certainly more work to be done here.

I am also going to send additional comments on the MCoA draft separately.
 
Thanks
George
P.S.: I moved this to MEXT list now, and below is the last e-mail I received on this issue on monami6 list....not sure if I missed anything in between.

 

-----Original Message-----
From: Keigo Aso [mailto:asou.keigo@jp.panasonic.com]
Sent: Monday, November 19, 2007 1:52 AM
To: Monami6 WG
Subject: Re: [Monami6] returning home issue in MCoA

 

Hi Ryuji,

 

On Sun, 18 Nov 2007 11:36:49 +0900

RYUJI WAKIKAWA <ryuji.wakikawa@gmail.com> wrote:

 

> Hi Vijay,

>

> On 2007/11/18, at 7:05, Vijay Devarapalli wrote:

>

> > RYUJI WAKIKAWA wrote:

> >

> >>> But now I puzzled why the HA would be turning of proxy ND? I think

> >>> the HA should still continue proxying the home address of the mobile

> >>> node and intercept the packets.

> >> Then, HA and MN will meet the address duplication.

> >> MN tries to defend its HoA on the home link and HA also tries to do 

> >> the same by Proxy ND.

> >

> > No. The MN does not attempt to defend its address when it knows

> > that it has another binding from a visited link. It knows that

> > the HA will be proxying its home address. Basically the HA would

> > defined whether to send the traffic directly to the home address

> > on the link or tunnel to the CoA that the MN has registered at

> > the HA. The HA would make the decision based on the type of

> > packet/flow..

> >

> >>> The HA then decides how to forward the packet. If the packet is

> >>> meant the MN interface which is not attached to the home link, the

> >>> packet should be tunneled to the mobile node on the visited link. If

> >>> the packet is meant for the MN interface which is attached to the

> >>> home link, the HA delivers it directly. The tricky part would be to

> >>> create a neighbor cache entry for the mobile node so that the HA

> >>> can deliver the packet on-link. The HA would need to know the L2

> >>> address of the interface with which the mobile node is attached to

> >>> the home link.

> >> Do you suggest to modify ND parts for this?

> >

> > Is there a need to modify neighbor discovery? As long as the

> > HA has the layer 2 address that corresponds to the interface

> > with which the mobile node is attached to the home link, it can

> > construct a neighbor cache entry or for example construct the

> > ether header.

>

> It sounds similar to the MN's operation of sending dereg-BU from home 

> link.

>

> - How can HA learn the MN's L2 address.

> - when MN communicates with CN on the home link, the packets are 

> always routed through the HA

> - Regardless of binding status, HA MUST defend the HoA at the home link.

>     While MN is back to home with multiple bindings, HA will intercept  

> all the packets and decides how to deliver the packets to MN. However, 

> if MN stop using the interfaces attached to foreign link, HA will no 

> longer defend the HoA. It means MN MUST start defending own HoA at the 

> home link. I think this is a bit tricky. HA should do proxy NDP for 

> HoA regardless of binding status of MN.

> - From the implementation experience of returning home, it is very 

> hard to implement this;-p

 

I think it is better to assume HA is a router on the home link as described in

your draft no-ndp-00 in order to avoid to introduce needless complexity here.

When MN connects to both home and foreign link, if HA can see all packets for

the HoA of the MN by IP routing, it would not need to do proxy ND for

intercepting packets. MN can do ND for own HoA here.

While, when MN's both interfaces connects to foreign link, HA should do proxy ND

for defending the HoA of the MN, according to RFC3775.

 

And, I agree with Vijay's comments.

Even when MN connects to both home and foreign link, HA can do proxy ND for the

network which its egress interface connects to for intercepting packets for the

HoA of the MN.

In this case, I think it is better for HA to stop proxy ND for the home link.

If so, MN can start ND for defeinding own HoA and HA can know MN's L2 address.

There is no change on ProxyND in home link defined by RFC3775.

 

Regards,

Keigo

 

>

> ryuji

>

>

>

> > Vijay

> >

> >> ryuji

> >>>

> >>>

> >>> Vijay

> >>>

> >>>> If you answer YES to the question above,

> >>>> Should MCoA document support this feature?

> >>>> [ ] YES

> >>>> [ ] NO (not in MCoA, but in a separate document)

> >>>> The deadline for this consensus call  is October the 8th 2007.

> >>>> Thank you,

> >>>> Monami6 chairs

> >>>> _______________________________________________

> >>>> Monami6 mailing list

> >>>> Monami6@ietf.org

> >>>> https://www1.ietf.org/mailman/listinfo/monami6

> >>>

> >>>

> >>> _______________________________________________

> >>> Monami6 mailing list

> >>> Monami6@ietf.org

> >>> https://www1.ietf.org/mailman/listinfo/monami6

> >> _______________________________________________

> >> Monami6 mailing list

> >> Monami6@ietf.org

> >> https://www1.ietf.org/mailman/listinfo/monami6

> >

> >

> > _______________________________________________

> > Monami6 mailing list

> > Monami6@ietf.org

> > https://www1.ietf.org/mailman/listinfo/monami6

>

>

> _______________________________________________

> Monami6 mailing list

> Monami6@ietf.org

> https://www1.ietf.org/mailman/listinfo/monami6

 

 

 

_______________________________________________

Monami6 mailing list

Monami6@ietf.org

https://www1.ietf.org/mailman/listinfo/monami6

------=_Part_17414_32241127.1195652453842-- --===============1113624792== 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 --===============1113624792==-- From mext-bounces@ietf.org Wed Nov 21 09:08: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 1IuqFT-0004FK-OC; Wed, 21 Nov 2007 09:08:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqFS-0004Bh-7U for mext@ietf.org; Wed, 21 Nov 2007 09:08:14 -0500 Received: from rv-out-0910.google.com ([209.85.198.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuqFR-0001xe-81 for mext@ietf.org; Wed, 21 Nov 2007 09:08:14 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1849727rvb for ; Wed, 21 Nov 2007 06:08:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=4tbaz+E9yvRh4Etz28ERHHOZKEHkTBRzPl1KUp5j5Jo=; b=qETFfLPoKtceMX7KwmwnI5bjC8DTBOHjxnvCeswR1cwmSI0y3bEL1ENOMM+8wF0bD0+dOp+ccgu2si4vz+W9xM/heklQT8iD9KhYcOUEDrRFX58zG5sl/9BhiuLPM1nqYNFMvlW6ZTfBW2LvyagERMhe+SariAfb0rMJdJzCYLg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Zd5kC4/iLQ8SrIoUFKzPiIZGM2T+Qz5UlUlcGhFJg36xJH5pIZDDt0/uvfBhX+4tBQl8lsexcE0tz/cqmvxXZx2hBwRvcGRpwyRGQSCC5kDCZifg9eyUIQ0hCxxd9+uhE5yN714HnjbAxtLsuuxBpZtgcyTeW+rJ5izxRVuED3U= Received: by 10.140.139.3 with SMTP id m3mr3317034rvd.1195654082109; Wed, 21 Nov 2007 06:08:02 -0800 (PST) Received: by 10.141.177.11 with HTTP; Wed, 21 Nov 2007 06:08:02 -0800 (PST) Message-ID: Date: Wed, 21 Nov 2007 14:08:02 +0000 From: "George Tsirtsis" To: mext@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: [MEXT] Comments on draft-ietf-monami6-multiplecoa-04.txt 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="===============0839703033==" Errors-To: mext-bounces@ietf.org --===============0839703033== Content-Type: multipart/alternative; boundary="----=_Part_17565_7647470.1195654082089" ------=_Part_17565_7647470.1195654082089 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I reviewed draft-ietf-monami6-multiplecoa-04.txt so here are some comments: 1) BID name: Not sure if I am missing some history behind this but I am not sure why BID does not simply mean "Binding ID" as opposed to "Binding Unique ID". Could we drop the work "unique" from BID and the corresponding sub-option? 2) BID uniqueness and scope: One needs to read almost the entire document before he can figure out that the BID's scope of uniqueness is exactly. The fact that a BID is unique to an HoA/CoA pair and the fact that the MN is responsible for managing the BID number space should be made clear up front, maybe as part of the BID definition in Section 2. 3) Bulk Registrations and CNs: It is not clear why bulk registrations are not allowed for CNs. Is it so much more complex to handle bulk registrations once that is defined for the HA and once the CNs handle MCoAs one at a time? 4) Deregistration/Returning_Home:These issues are described in Section 3 (protocol overview) and then more explicitly in other sections. I found the text in Section 3 with respect to these issues confusing to say the least. Maybe that text can be removed or re-written after the issues are resolved sufficiently (see separate thread of discussion on that). 5) In the definition of Care of address (C) flag (section 4.2.1) a "must", an "or", and a "MUST" are used in the same breath...please clean it up :-) 6) BID independence vs bulk registrations: It is hard to tell from the current text to what extend BIDs are managed independently and how that is affected by bulk registrations. In particular the discussion regarding sequence numbers in Section 5.4 is confusing. According to 3775, Section 11.1, the MN is keeping just one entry in its Binding Update List for each destination. If I understand correctly, with MCoAs, the MN needs to keep multiple entries in that list, one per BID. It should be made clear whether a separate sequence number space is required per BID or not. Separate space per BID seems incompatible with the idea of sending bulk registrations, so I would think that the same space should be used. 7) Interactions with DSMIPv6. I think at some point a new section needs to be added to talk about interactions with DSMIPv6. Beyond the obvious issue of whether MCoAs can include IPv4 CoAs etc the MCoA draft includes some interactions with IKEv2 and imposes some requirements to the use of alternate-CoA which may or may not conflict with DSMIPv6 (have not checked that myself yet). Regards George ------=_Part_17565_7647470.1195654082089 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi all,
 
I reviewed draft-ietf-monami6-multiplecoa-04.txt so here are some comments:
 
1) BID name: Not sure if I am missing some history behind this but I am not sure why BID does not simply mean "Binding ID" as opposed to "Binding Unique ID". Could we drop the work "unique" from BID and the corresponding sub-option?
 
2) BID uniqueness and scope: One needs to read almost the entire document before he can figure out that the BID's scope of uniqueness is exactly. The fact that a BID is unique to an HoA/CoA pair and the fact that the MN is responsible for managing the BID number space should be made clear up front, maybe as part of the BID definition in Section 2.
 
3) Bulk Registrations and CNs: It is not clear why bulk registrations are not allowed for CNs. Is it so much more complex to handle bulk registrations once that is defined for the HA and once the CNs handle MCoAs one at a time?
 
4) Deregistration/Returning_Home:These issues are described in Section 3 (protocol overview) and then more explicitly in other sections. I found the text in Section 3 with respect to these issues confusing to say the least. Maybe that text can be removed or re-written after the issues are resolved sufficiently (see separate thread of discussion on that).
 
5) In the definition of Care of address (C) flag (section 4.2.1) a "must", an "or", and a "MUST" are used in the same breath...please clean it up :-)
 
6) BID independence vs bulk registrations: It is hard to tell from the current text to what extend BIDs are managed independently and how that is affected by bulk registrations. In particular the discussion regarding sequence numbers in Section 5.4 is confusing. According to 3775, Section 11.1, the MN is keeping just one entry in its Binding Update List for each destination. If I understand correctly, with MCoAs, the MN needs to keep multiple entries in that list, one per BID.  It should be made clear whether a separate sequence number space is required per BID or not. Separate space per BID seems incompatible with the idea of sending bulk registrations, so I would think that the same space should be used.
 
7) Interactions with DSMIPv6. I think at some point a new section needs to be added to talk about interactions with DSMIPv6. Beyond the obvious issue of whether MCoAs can include IPv4 CoAs etc the MCoA draft includes some interactions with IKEv2 and imposes some requirements to the use of alternate-CoA which may or may not conflict with DSMIPv6 (have not checked that myself yet).
 
Regards
George
------=_Part_17565_7647470.1195654082089-- --===============0839703033== 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 --===============0839703033==-- From mext-bounces@ietf.org Wed Nov 21 09:38: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 1Iuqio-0007cd-8z; Wed, 21 Nov 2007 09:38:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuqin-0007cA-EL for mext@ietf.org; Wed, 21 Nov 2007 09:38:33 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iuqim-0002i6-VH for mext@ietf.org; Wed, 21 Nov 2007 09:38:33 -0500 X-IronPort-AV: E=Sophos;i="4.21,447,1188770400"; d="scan'208";a="158419461" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Nov 2007 15:38:32 +0100 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 lALEcWlM021195; Wed, 21 Nov 2007 15:38:32 +0100 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 lALEc5Zj020315; Wed, 21 Nov 2007 14:38:28 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, 21 Nov 2007 15:38:06 +0100 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: [MEXT] Prefix Delegation documents Date: Wed, 21 Nov 2007 15:38:02 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> In-Reply-To: <47432B43.5020100@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Prefix Delegation documents Thread-Index: AcgrpZEBTx8/HkgNRHGTd7fhRrZsjwApej3g References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Teco Boot" X-OriginalArrivalTime: 21 Nov 2007 14:38:06.0565 (UTC) FILETIME=[212AD150:01C82C4C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1560; t=1195655912; x=1196519912; 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[MEXT]=20=20Prefix=20Delegation=20documents |Sender:=20; bh=rvV0Z4SX2lQ6BYvV2CLiGzLrwkF53VHHgm791tjabeY=; b=eaobisaF5UTMudmOMSwltFXJfwUVPkdC+LdoMCBPD2uEDri2ikXKKe5zQKUqBbH9M6+jMJhz gTf6deQtf/xFahZnykbWIiFqh5eiAMzgou6iS1YNQqNufeKDYZ/SqJnS; 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: a7d6aff76b15f3f56fcb94490e1052e4 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 Vijay My proposal to break the tie is this: - move draft-ietf-nemo-dhcpv6-pd-02.txt to informational track as it documents a way to use DHCP-PD but does not need new exchanges. Last I checked, some components were still missing but Ralph knows better. - focus on draft-ietf-nemo-prefix-delegation-02.txt for standard track. The draft is agnostic to the delegation mechanism in the backend and does not have dependencies. It proposes an integrated mechanism that fits the general MIP6 / NEMO approach and formats. What do you think? Pascal >-----Original Message----- >From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] >Sent: Tuesday, November 20, 2007 7:45 PM >To: Teco Boot >Cc: Pascal Thubert (pthubert); mext@ietf.org >Subject: Re: [MEXT] Re: [nemo] Prefix Delegation documents > >Teco Boot wrote: >> Hi Pascal, >> Question on WG documents for prefix delegation. There are two of them: >> 1: draft-ietf-nemo-prefix-delegation-02.txt (August 21, 2007) >> 2: draft-ietf-nemo-dhcpv6-pd-02.txt (September 28, 2006) >> Are we still working on both solutions? > >We have a sort of stalemate on this. I believe Jari (AD) would prefer >one solution in this space. I think the earlier decision by the NEMO >WG was to standardize both solutions. Not sure what the consensus is >right now. > >IMO, we should standardize one ASAP. Without a prefix delegation >mechanism the only possible solution now is to pre-configure the >mobile network prefix on the mobile router. This is not sufficient. > >Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Nov 21 11:34: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 1IusWe-0007mP-9N; Wed, 21 Nov 2007 11:34:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IusWd-0007lA-Dj for mext@ietf.org; Wed, 21 Nov 2007 11:34:07 -0500 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 1IusWZ-0002gu-VE for mext@ietf.org; Wed, 21 Nov 2007 11:34:07 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lALGXuYn015379 for ; Wed, 21 Nov 2007 18:33:58 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 18:29:22 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 10:29:16 -0600 Received: from 10.162.253.10 ([10.162.253.10]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Nov 2007 16:29:16 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 21 Nov 2007 10:29:17 -0600 From: Basavaraj Patil To: Message-ID: Thread-Topic: IETF70 agenda: 2nd meeting slot for MEXT Thread-Index: AcgsW6kO53dVIphOEdyXpQARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Nov 2007 16:29:16.0465 (UTC) FILETIME=[A8BCCA10:01C82C5B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [MEXT] IETF70 agenda: 2nd meeting slot for 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 Hello, I had requested that the MIP6 slot (intended for MEXT) be scheduled for an earlier day. I have been told by the secretary (Dinara) that the slot has been rescheduled to the last slot on Tuesday. Hopefully the revised agenda will reflect this change soon. Just a heads up for people planning their travel and meeting participation. -Raj _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Nov 21 12:33: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 1IutS1-000733-2c; Wed, 21 Nov 2007 12:33:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IutRz-00072w-H2 for mext@ietf.org; Wed, 21 Nov 2007 12:33:23 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IutRt-0004q4-2l for mext@ietf.org; Wed, 21 Nov 2007 12:33:23 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1195666395!6270799!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 7864 invoked from network); 21 Nov 2007 17:33:15 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-153.messagelabs.com with SMTP; 21 Nov 2007 17:33:15 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lALHX2ac011510; Wed, 21 Nov 2007 10:33:02 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id lALHX1lH015677; Wed, 21 Nov 2007 11:33:01 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id lALHWxiQ015655; Wed, 21 Nov 2007 11:33:00 -0600 (CST) Message-ID: <47446BCB.5000000@gmail.com> Date: Wed, 21 Nov 2007 18:32:59 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [MEXT] Prefix Delegation documents References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071120-0, 20/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Vijay Devarapalli , 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 Pascal Thubert (pthubert) wrote: > Hi Vijay > > My proposal to break the tie is this: > > - move draft-ietf-nemo-dhcpv6-pd-02.txt to informational track as it > documents a way to use DHCP-PD but does not need new exchanges. But as Romain pointed out, DHCP-PD as specified in this draft extends DHAAD by adding a new D flag. If we want to avoid the use of the new D flag then we should (probably) say in the DHCP-NEMO-PD draft how that DHCPv6 Solicit is sent through the MR-HA tunnel (or not through tunnel) and then relayed by the HA on the home link (or the HA is the DHCPv6 Server). I think even if we move it to the Informational track then we still need to improve some stuff in it according to implementation. Or just let it float... I don't know. > Last I checked, some components were still missing but Ralph knows > better. > > - focus on draft-ietf-nemo-prefix-delegation-02.txt for standard > track. The draft is agnostic to the delegation mechanism in the > backend and does not have dependencies. But it extends MIP6, right? (adds flags in messages). > It proposes an integrated mechanism that fits the general MIP6 / NEMO > approach and formats. > > What do you think? I think we should not extend MIP6 to do prefix allocation. BEcause: -I think addressing autoconfiguration mechanisms DHCP and others are already there for us to reuse and enhance eventually, no need to extend MIP6. -what happens when MIPv6 allocates a prefix and PMIPv6 allocates one as well, but in a different way? (currently PMIPv6 doesn't seem to use NEMO-MIP6-PD flags neither does NEMO-MIP6-PD use PMIPv6 way of putting 0 to mean request prefix). Are the MIP6 and PMIP6 means to allocate prefixes equivalent? -what happens when we want the prefix delegated to the MR to be accompanied by a delegation of responsibility of the DNS reverse resolution as well? Can we reuse DHCP-DNS interactions (e.g. DNS update RFC2136)? Or should we design a new MIP6-DNS interaction? That's simply opinion. I'm not sure about other criteria that came to give the suggestion you made. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From Liane@ambachtel.ch Wed Nov 21 13:21:11 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuuCE-0002VB-V6 for nemo-archive@lists.ietf.org; Wed, 21 Nov 2007 13:21:10 -0500 Received: from aaia213.neoplus.adsl.tpnet.pl ([83.4.208.213] helo=cco71.neoplus.adsl.tpnet.pl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuuCE-0002u6-Cx for nemo-archive@lists.ietf.org; Wed, 21 Nov 2007 13:21:10 -0500 Received: from dom ([175.187.127.113] helo=dom) by cco71.neoplus.adsl.tpnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1gtDHb-000SKK-Pm for nemo-archive@lists.ietf.org; Wed, 21 Nov 2007 19:21:43 +0100 Message-ID: <000b01c82c6b$4ad401b0$478a1e53@dom> From: "Liane Kemper" To: Subject: n{hydarb Date: Wed, 21 Nov 2007 19:21:10 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C82C73.AC9869B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.8 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0004_01C82C73.AC9869B0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable No man would be happy to be told by his gf in the b-room "Oh, how small = it is" jarrad Gerlings http://occurhand.com/ ------=_NextPart_000_0004_01C82C73.AC9869B0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
No man would be happy to be = told by=20 his gf in the b-room "Oh, how small it is"
jarrad Gerlings
http://occurhand.com/
------=_NextPart_000_0004_01C82C73.AC9869B0-- From mext-bounces@ietf.org Wed Nov 21 13:57: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 1IuulI-00066e-8n; Wed, 21 Nov 2007 13:57:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuulF-000618-Eu for mext@ietf.org; Wed, 21 Nov 2007 13:57:21 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuulE-0003ul-VH for mext@ietf.org; Wed, 21 Nov 2007 13:57:21 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Nov 2007 10:57:19 -0800 Message-ID: <47447F8F.3050103@azairenet.com> Date: Wed, 21 Nov 2007 10:57:19 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [MEXT] Prefix Delegation documents References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2007 18:57:19.0699 (UTC) FILETIME=[578EBA30:01C82C70] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 Pascal Thubert (pthubert) wrote: > Hi Vijay > > My proposal to break the tie is this: > > - move draft-ietf-nemo-dhcpv6-pd-02.txt to informational track as it > documents a way to use DHCP-PD but does not need new exchanges. Last I > checked, some components were still missing but Ralph knows better. > > - focus on draft-ietf-nemo-prefix-delegation-02.txt for standard track. > The draft is agnostic to the delegation mechanism in the backend and > does not have dependencies. It proposes an integrated mechanism that > fits the general MIP6 / NEMO approach and formats. > > What do you think? I am fine with this approach. For draft-ietf-nemo-prefix-delegation-02.txt, I would like to simplify the mechanism a bit, by removing the Mobile Network Prefix Confirm option. Just use the Mobile Network Prefix option for the home agent to send the prefix to the mobile router. I actually don't understand the need for the Mobile Network Prefix Confirm option. Vijay > > Pascal > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] >> Sent: Tuesday, November 20, 2007 7:45 PM >> To: Teco Boot >> Cc: Pascal Thubert (pthubert); mext@ietf.org >> Subject: Re: [MEXT] Re: [nemo] Prefix Delegation documents >> >> Teco Boot wrote: >>> Hi Pascal, >>> Question on WG documents for prefix delegation. There are two of > them: >>> 1: draft-ietf-nemo-prefix-delegation-02.txt (August 21, 2007) >>> 2: draft-ietf-nemo-dhcpv6-pd-02.txt (September 28, 2006) >>> Are we still working on both solutions? >> We have a sort of stalemate on this. I believe Jari (AD) would prefer >> one solution in this space. I think the earlier decision by the NEMO >> WG was to standardize both solutions. Not sure what the consensus is >> right now. >> >> IMO, we should standardize one ASAP. Without a prefix delegation >> mechanism the only possible solution now is to pre-configure the >> mobile network prefix on the mobile router. This is not sufficient. >> >> Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From MagdalenalaunderWolff@williecrawford.com Wed Nov 21 14:01:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuup4-0002jB-Ve for nemo-archive@lists.ietf.org; Wed, 21 Nov 2007 14:01:19 -0500 Received: from [190.80.184.42] (helo=pc3a467048a61a.domain.invalid) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iuup4-00045X-IW for nemo-archive@lists.ietf.org; Wed, 21 Nov 2007 14:01:18 -0500 Received: from rust by williecrawford.com with SMTP id jXPsojxeDa for ; Wed, 21 Nov 2007 15:00:34 +0400 From: "Leila Fournier" To: Subject: After that Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Make Vegas your playing ground, wherever you are, with Vegas VIP. Play today and receive up to $555 in Welcome bonuses to make the experience that much sweeter! How does this great deal work? 1st deposit - 200% bonus, worth up to $200 2nd desposit - 100% bonus, worth up to $100 3rd deposit - 155% bonus, worth up to $155 4th deposit - 100% bonus, worth up to $100 Vegas VIP uses the securest and most realistic gaming software to guarantee you get the safest, most exciting playing experience available online today, and tomorrow! Take advantage today and you too could see your dreams come true http://eurocasinoau.com/ From mext-bounces@ietf.org Wed Nov 21 18:15: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 1Iuym3-0002uC-QU; Wed, 21 Nov 2007 18:14:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuym2-0002u7-Fh for mext@ietf.org; Wed, 21 Nov 2007 18:14:26 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iuym1-00073j-DZ for mext@ietf.org; Wed, 21 Nov 2007 18:14:26 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Nov 2007 15:14:24 -0800 Message-ID: <4744BBCF.4070409@azairenet.com> Date: Wed, 21 Nov 2007 15:14:23 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: George Tsirtsis , Ryuji Wakikawa Subject: Re: [MEXT] was Re: [Monami6] returning home issue in MCoA References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2007 23:14:24.0366 (UTC) FILETIME=[416020E0:01C82C94] X-Spam-Score: 0.0 (/) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e 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 Ryuji and George, George Tsirtsis wrote: > To respond to Nikolas initial question on this issue I think that > simultaneous home-foreign connectivity issues should be discussed and > resolved as part of the MCoA draft. In any case Ryuji already listed a > number of options, not all of which are too complex. It seems to me that > ND proxying or not, by who, and when is the only remaining question :-) Right, we need to figure this out. :) I think we should go with the home agent intercepting the packets all the time in this scenario. This means the home agent would proxy the mobile node's home address. Once the home agent receives the packet, it decides whether to deliver the packets locally on if1 or tunnel to CoA on if2. If we let the mobile node respond to neighbor solicitations, then I don't see how packets meant for if2 will ever get tunneled to the CoA. The mobile node will always receive the packets on-link on if1. Vijay > > I have to say that the H flag and the description of this in MCoA-v4 is > not yet clear enough so there is certainly more work to be done here. > > I am also going to send additional comments on the MCoA draft separately. > > Thanks > George > P.S.: I moved this to MEXT list now, and below is the last e-mail I > received on this issue on monami6 list....not sure if I missed anything > in between. > > > > -----Original Message----- > From: Keigo Aso [mailto:asou.keigo@jp.panasonic.com > ] > Sent: Monday, November 19, 2007 1:52 AM > To: Monami6 WG > Subject: Re: [Monami6] returning home issue in MCoA > > > > Hi Ryuji, > > > > On Sun, 18 Nov 2007 11:36:49 +0900 > > RYUJI WAKIKAWA > wrote: > > > > > Hi Vijay, > > > > > > On 2007/11/18, at 7:05, Vijay Devarapalli wrote: > > > > > > > RYUJI WAKIKAWA wrote: > > > > > > > >>> But now I puzzled why the HA would be turning of proxy ND? I think > > > >>> the HA should still continue proxying the home address of the mobile > > > >>> node and intercept the packets. > > > >> Then, HA and MN will meet the address duplication. > > > >> MN tries to defend its HoA on the home link and HA also tries to do > > > >> the same by Proxy ND. > > > > > > > > No. The MN does not attempt to defend its address when it knows > > > > that it has another binding from a visited link. It knows that > > > > the HA will be proxying its home address. Basically the HA would > > > > defined whether to send the traffic directly to the home address > > > > on the link or tunnel to the CoA that the MN has registered at > > > > the HA. The HA would make the decision based on the type of > > > > packet/flow.. > > > > > > > >>> The HA then decides how to forward the packet. If the packet is > > > >>> meant the MN interface which is not attached to the home link, the > > > >>> packet should be tunneled to the mobile node on the visited link. If > > > >>> the packet is meant for the MN interface which is attached to the > > > >>> home link, the HA delivers it directly. The tricky part would be to > > > >>> create a neighbor cache entry for the mobile node so that the HA > > > >>> can deliver the packet on-link. The HA would need to know the L2 > > > >>> address of the interface with which the mobile node is attached to > > > >>> the home link. > > > >> Do you suggest to modify ND parts for this? > > > > > > > > Is there a need to modify neighbor discovery? As long as the > > > > HA has the layer 2 address that corresponds to the interface > > > > with which the mobile node is attached to the home link, it can > > > > construct a neighbor cache entry or for example construct the > > > > ether header. > > > > > > It sounds similar to the MN's operation of sending dereg-BU from home > > > link. > > > > > > - How can HA learn the MN's L2 address. > > > - when MN communicates with CN on the home link, the packets are > > > always routed through the HA > > > - Regardless of binding status, HA MUST defend the HoA at the home link. > > > While MN is back to home with multiple bindings, HA will intercept > > > all the packets and decides how to deliver the packets to MN. However, > > > if MN stop using the interfaces attached to foreign link, HA will no > > > longer defend the HoA. It means MN MUST start defending own HoA at the > > > home link. I think this is a bit tricky. HA should do proxy NDP for > > > HoA regardless of binding status of MN. > > > - From the implementation experience of returning home, it is very > > > hard to implement this;-p > > > > I think it is better to assume HA is a router on the home link as > described in > > your draft no-ndp-00 in order to avoid to introduce needless complexity > here. > > When MN connects to both home and foreign link, if HA can see all > packets for > > the HoA of the MN by IP routing, it would not need to do proxy ND for > > intercepting packets. MN can do ND for own HoA here. > > While, when MN's both interfaces connects to foreign link, HA should do > proxy ND > > for defending the HoA of the MN, according to RFC3775. > > > > And, I agree with Vijay's comments. > > Even when MN connects to both home and foreign link, HA can do proxy ND > for the > > network which its egress interface connects to for intercepting packets > for the > > HoA of the MN. > > In this case, I think it is better for HA to stop proxy ND for the home > link. > > If so, MN can start ND for defeinding own HoA and HA can know MN's L2 > address. > > There is no change on ProxyND in home link defined by RFC3775. > > > > Regards, > > Keigo > > > > > > > > ryuji > > > > > > > > > > > > > Vijay > > > > > > > >> ryuji > > > >>> > > > >>> > > > >>> Vijay > > > >>> > > > >>>> If you answer YES to the question above, > > > >>>> Should MCoA document support this feature? > > > >>>> [ ] YES > > > >>>> [ ] NO (not in MCoA, but in a separate document) > > > >>>> The deadline for this consensus call is October the 8th 2007. > > > >>>> Thank you, > > > >>>> Monami6 chairs > > > >>>> _______________________________________________ > > > >>>> Monami6 mailing list > > > >>>> Monami6@ietf.org > > > >>>> https://www1.ietf.org/mailman/listinfo/monami6 > > > >>> > > > >>> > > > >>> _______________________________________________ > > > >>> Monami6 mailing list > > > >>> Monami6@ietf.org > > > >>> https://www1.ietf.org/mailman/listinfo/monami6 > > > >> _______________________________________________ > > > >> Monami6 mailing list > > > >> Monami6@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/monami6 > > > > > > > > > > > > _______________________________________________ > > > > Monami6 mailing list > > > > Monami6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/monami6 > > > > > > > > > _______________________________________________ > > > Monami6 mailing list > > > Monami6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/monami6 > > > > > > > > _______________________________________________ > > Monami6 mailing list > > Monami6@ietf.org > > https://www1.ietf.org/mailman/listinfo/monami6 > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Wed Nov 21 18:25: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 1Iuywv-00018r-N4; Wed, 21 Nov 2007 18:25:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuywt-00018g-Pk for mext@ietf.org; Wed, 21 Nov 2007 18:25:39 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuywq-0002dV-JG for mext@ietf.org; Wed, 21 Nov 2007 18:25:39 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Nov 2007 15:25:35 -0800 Message-ID: <4744BE6F.5040408@azairenet.com> Date: Wed, 21 Nov 2007 15:25:35 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: George Tsirtsis , Ryuji Wakikawa Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-04.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2007 23:25:35.0783 (UTC) FILETIME=[D1923B70:01C82C95] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 George Tsirtsis wrote: > 7) Interactions with DSMIPv6. I think at some point a new section needs > to be added to talk about interactions with DSMIPv6. Beyond the obvious > issue of whether MCoAs can include IPv4 CoAs etc the MCoA draft includes > some interactions with IKEv2 I think the IKEv2 interactions are inline with what we decided for DS-MIPv6 last week. Transport mode IPsec SA for the binding update, and tunnel mode SAs updated either by MIPv6 (K flag) or running IKEv2 again. and imposes some requirements to the use of > alternate-CoA which may or may not conflict with DSMIPv6 (have not > checked that myself yet). In DS-MIPv6, the IPv4 CoA option is a new mobility option, not related to the alt CoA option in RFC 3775. draft-ietf-monami6-multiplecoa says the alt CoA option should not be included whenever the CoA is carried in the BID mobility option. The BID option as defined in the draft currently seems to allow only for an IPv6 address. I think, we need to extend the BID option to carry an IPv4 or an IPv6 address. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 22 02:20: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 1Iv6Lg-0005Sa-BE; Thu, 22 Nov 2007 02:19:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv6Le-0005S3-2o for mext@ietf.org; Thu, 22 Nov 2007 02:19:42 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iv6Ld-0000t3-2u for mext@ietf.org; Thu, 22 Nov 2007 02:19:41 -0500 Received: (qmail 1748 invoked from network); 22 Nov 2007 08:19:39 +0100 Received: from unknown (HELO M90Teco) (217.169.232.211) by server9.hosting2go.nl with SMTP; 22 Nov 2007 08:19:38 +0100 From: "Teco Boot" To: "'Vijay Devarapalli'" , "'Pascal Thubert \(pthubert\)'" References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> <47447F8F.3050103@azairenet.com> In-Reply-To: <47447F8F.3050103@azairenet.com> Subject: RE: [MEXT] Prefix Delegation documents Date: Thu, 22 Nov 2007 08:18:59 +0100 Message-ID: <005f01c82cd8$062d2880$12877980$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgscFjtJMR+v5f4S32anoKfQLuvyAAZW4pA Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: autoconf@ietf.org, 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 Thanks for the clarifications. I wanted to know, as Prefix Delegation is being worked on in Autoconf also. If Autoconf comes up with a third solution, it could be difficult to manage in environments with equipment is both Mobile Router (NEMO) and MANET Router (Autoconf). Are others also studying this overlap in functionality? Maybe there are some issues with PD and DSMIPv6. Has anyone looked at this? I suggest to keep the PD discussion in MEXT. Teco. > -----Oorspronkelijk bericht----- > Van: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Verzonden: woensdag 21 november 2007 19:57 > Aan: Pascal Thubert (pthubert) > CC: Teco Boot; mext@ietf.org > Onderwerp: Re: [MEXT] Prefix Delegation documents > > Pascal Thubert (pthubert) wrote: > > Hi Vijay > > > > My proposal to break the tie is this: > > > > - move draft-ietf-nemo-dhcpv6-pd-02.txt to informational track as it > > documents a way to use DHCP-PD but does not need new exchanges. Last > I > > checked, some components were still missing but Ralph knows better. > > > > - focus on draft-ietf-nemo-prefix-delegation-02.txt for standard > track. > > The draft is agnostic to the delegation mechanism in the backend and > > does not have dependencies. It proposes an integrated mechanism that > > fits the general MIP6 / NEMO approach and formats. > > > > What do you think? > > I am fine with this approach. > > For draft-ietf-nemo-prefix-delegation-02.txt, I would like to > simplify the mechanism a bit, by removing the Mobile Network > Prefix Confirm option. Just use the Mobile Network Prefix > option for the home agent to send the prefix to the mobile > router. I actually don't understand the need for the Mobile > Network Prefix Confirm option. > > Vijay > > > > > Pascal > > > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > >> Sent: Tuesday, November 20, 2007 7:45 PM > >> To: Teco Boot > >> Cc: Pascal Thubert (pthubert); mext@ietf.org > >> Subject: Re: [MEXT] Re: [nemo] Prefix Delegation documents > >> > >> Teco Boot wrote: > >>> Hi Pascal, > >>> Question on WG documents for prefix delegation. There are two of > > them: > >>> 1: draft-ietf-nemo-prefix-delegation-02.txt (August 21, 2007) > >>> 2: draft-ietf-nemo-dhcpv6-pd-02.txt (September 28, 2006) > >>> Are we still working on both solutions? > >> We have a sort of stalemate on this. I believe Jari (AD) would > prefer > >> one solution in this space. I think the earlier decision by the NEMO > >> WG was to standardize both solutions. Not sure what the consensus is > >> right now. > >> > >> IMO, we should standardize one ASAP. Without a prefix delegation > >> mechanism the only possible solution now is to pre-configure the > >> mobile network prefix on the mobile router. This is not sufficient. > >> > >> Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 22 04:15:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv89T-0005JJ-8v; Thu, 22 Nov 2007 04:15:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv89R-0005J2-KC for mext@ietf.org; Thu, 22 Nov 2007 04:15:13 -0500 Received: from rv-out-0910.google.com ([209.85.198.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv89P-00006h-C7 for mext@ietf.org; Thu, 22 Nov 2007 04:15:13 -0500 Received: by rv-out-0910.google.com with SMTP id l15so2086459rvb for ; Thu, 22 Nov 2007 01:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=K2PrersXJ6Pgr/seFegW37zI0Plxm7ukUihTYwROGtI=; b=YWTEVC8m74vxheQYxPO2U0KzFvDIU2kWzNZ8kiFvDXofdPXLqSidevnChGGFk3VhLJmiSBhu9tshA6fQECO9vyIfpeCW4SFfy8CJg2LFf07Oh3wC2IlKSh26T8kD4ti3sVtTOXmk+tbOSHhZ8xv52SEPXRHpJ6EC1YQ6nDpWdEg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=H1LvrgwqRrAytyNUP97v+LGBANxCA+jT6DT/OeqYVNQhppa6qK05cNOVjaQ9ib+u0pgtLVXnszBPiydd3a5h8/OY2wN/2YFRlF4tJr5BRG1GRdsA3k1bwcDUKgIPFi915n0ZrZrs8ymLwYyr0nePaMThnB7Hc1paBUlUrSdmkBc= Received: by 10.141.145.11 with SMTP id x11mr3807127rvn.1195722910737; Thu, 22 Nov 2007 01:15:10 -0800 (PST) Received: by 10.141.177.11 with HTTP; Thu, 22 Nov 2007 01:15:10 -0800 (PST) Message-ID: Date: Thu, 22 Nov 2007 09:15:10 +0000 From: "George Tsirtsis" To: mext@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a Subject: [MEXT] Re: was Re: [Monami6] returning home issue in MCoA 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 allowing the HA to continue intercepting the packets is necessary if the HA is supposed to direct at least some of them away from the home link. The question then is how packets are sent by the HA to the mobile over the home link. If the home link is a p2p link there should be no issue, but on shared links how is the l2 address of the mobile discovered by the HA? One way would be the mobile to add it in the BU it sends to the HA to indicate such a partial deregistration but it sounds like too much of a layer violation. Another could be for the HA to do a reverse lookup one the address on the link to discover the mac address of the mobile. George On 21/11/2007, George Tsirtsis wrote: > To respond to Nikolas initial question on this issue I think that > simultaneous home-foreign connectivity issues should be discussed and > resolved as part of the MCoA draft. In any case Ryuji already listed a > number of options, not all of which are too complex. It seems to me that ND > proxying or not, by who, and when is the only remaining question :-) > > I have to say that the H flag and the description of this in MCoA-v4 is not > yet clear enough so there is certainly more work to be done here. > > I am also going to send additional comments on the MCoA draft separately. > > Thanks > George > P.S.: I moved this to MEXT list now, and below is the last e-mail I received > on this issue on monami6 list....not sure if I missed anything in between. > > > > -----Original Message----- > From: Keigo Aso [mailto:asou.keigo@jp.panasonic.com] > Sent: Monday, November 19, 2007 1:52 AM > To: Monami6 WG > Subject: Re: [Monami6] returning home issue in MCoA > > > > Hi Ryuji, > > > > On Sun, 18 Nov 2007 11:36:49 +0900 > > RYUJI WAKIKAWA wrote: > > > > > Hi Vijay, > > > > > > On 2007/11/18, at 7:05, Vijay Devarapalli wrote: > > > > > > > RYUJI WAKIKAWA wrote: > > > > > > > >>> But now I puzzled why the HA would be turning of proxy ND? I think > > > >>> the HA should still continue proxying the home address of the mobile > > > >>> node and intercept the packets. > > > >> Then, HA and MN will meet the address duplication. > > > >> MN tries to defend its HoA on the home link and HA also tries to do > > > >> the same by Proxy ND. > > > > > > > > No. The MN does not attempt to defend its address when it knows > > > > that it has another binding from a visited link. It knows that > > > > the HA will be proxying its home address. Basically the HA would > > > > defined whether to send the traffic directly to the home address > > > > on the link or tunnel to the CoA that the MN has registered at > > > > the HA. The HA would make the decision based on the type of > > > > packet/flow.. > > > > > > > >>> The HA then decides how to forward the packet. If the packet is > > > >>> meant the MN interface which is not attached to the home link, the > > > >>> packet should be tunneled to the mobile node on the visited link. If > > > >>> the packet is meant for the MN interface which is attached to the > > > >>> home link, the HA delivers it directly. The tricky part would be to > > > >>> create a neighbor cache entry for the mobile node so that the HA > > > >>> can deliver the packet on-link. The HA would need to know the L2 > > > >>> address of the interface with which the mobile node is attached to > > > >>> the home link. > > > >> Do you suggest to modify ND parts for this? > > > > > > > > Is there a need to modify neighbor discovery? As long as the > > > > HA has the layer 2 address that corresponds to the interface > > > > with which the mobile node is attached to the home link, it can > > > > construct a neighbor cache entry or for example construct the > > > > ether header. > > > > > > It sounds similar to the MN's operation of sending dereg-BU from home > > > link. > > > > > > - How can HA learn the MN's L2 address. > > > - when MN communicates with CN on the home link, the packets are > > > always routed through the HA > > > - Regardless of binding status, HA MUST defend the HoA at the home link. > > > While MN is back to home with multiple bindings, HA will intercept > > > all the packets and decides how to deliver the packets to MN. However, > > > if MN stop using the interfaces attached to foreign link, HA will no > > > longer defend the HoA. It means MN MUST start defending own HoA at the > > > home link. I think this is a bit tricky. HA should do proxy NDP for > > > HoA regardless of binding status of MN. > > > - From the implementation experience of returning home, it is very > > > hard to implement this;-p > > > > I think it is better to assume HA is a router on the home link as described > in > > your draft no-ndp-00 in order to avoid to introduce needless complexity > here. > > When MN connects to both home and foreign link, if HA can see all packets > for > > the HoA of the MN by IP routing, it would not need to do proxy ND for > > intercepting packets. MN can do ND for own HoA here. > > While, when MN's both interfaces connects to foreign link, HA should do > proxy ND > > for defending the HoA of the MN, according to RFC3775. > > > > And, I agree with Vijay's comments. > > Even when MN connects to both home and foreign link, HA can do proxy ND for > the > > network which its egress interface connects to for intercepting packets for > the > > HoA of the MN. > > In this case, I think it is better for HA to stop proxy ND for the home > link. > > If so, MN can start ND for defeinding own HoA and HA can know MN's L2 > address. > > There is no change on ProxyND in home link defined by RFC3775. > > > > Regards, > > Keigo > > > > > > > > ryuji > > > > > > > > > > > > > Vijay > > > > > > > >> ryuji > > > >>> > > > >>> > > > >>> Vijay > > > >>> > > > >>>> If you answer YES to the question above, > > > >>>> Should MCoA document support this feature? > > > >>>> [ ] YES > > > >>>> [ ] NO (not in MCoA, but in a separate document) > > > >>>> The deadline for this consensus call is October the 8th 2007. > > > >>>> Thank you, > > > >>>> Monami6 chairs > > > >>>> _______________________________________________ > > > >>>> Monami6 mailing list > > > >>>> Monami6@ietf.org > > > >>>> https://www1.ietf.org/mailman/listinfo/monami6 > > > >>> > > > >>> > > > >>> _______________________________________________ > > > >>> Monami6 mailing list > > > >>> Monami6@ietf.org > > > >>> https://www1.ietf.org/mailman/listinfo/monami6 > > > >> _______________________________________________ > > > >> Monami6 mailing list > > > >> Monami6@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/monami6 > > > > > > > > > > > > _______________________________________________ > > > > Monami6 mailing list > > > > Monami6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/monami6 > > > > > > > > > _______________________________________________ > > > Monami6 mailing list > > > Monami6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/monami6 > > > > > > > > _______________________________________________ > > Monami6 mailing list > > Monami6@ietf.org > > https://www1.ietf.org/mailman/listinfo/monami6 > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From tomekBurge@cliffcreekbuilders.com Thu Nov 22 06:08:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv9vM-0004yJ-7i for nemo-archive@lists.ietf.org; Thu, 22 Nov 2007 06:08:48 -0500 Received: from c9155dd8.virtua.com.br ([201.21.93.216]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iv9vL-0001Wk-M4 for nemo-archive@lists.ietf.org; Thu, 22 Nov 2007 06:08:48 -0500 Received: by 10.158.54.80 with SMTP id ECTdoEDDXpkel; Thu, 22 Nov 2007 09:08:53 -0200 (GMT) Received: by 192.168.222.100 with SMTP id gWkKWDuXmJjQhX.6734082245576; Thu, 22 Nov 2007 09:08:51 -0200 (GMT) Message-ID: <000701c82cf8$0e7e02f0$d85d15c9@cpu> From: "tomek Burge" To: nemo-archive@lists.ietf.org Subject: niinotgn Date: Thu, 22 Nov 2007 09:08:48 -0200 Message-ID: <000701c82cf8$0e7e02f0$d85d15c9@cpu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 No man would be happy to be told by his gf in the b-room "Oh, how small it is" http://historycold.com/ From mext-bounces@ietf.org Thu Nov 22 08: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 1IvCYH-0007OT-Gu; Thu, 22 Nov 2007 08:57:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCYG-0007IH-6C; Thu, 22 Nov 2007 08:57:08 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvCYF-0007au-FX; Thu, 22 Nov 2007 08:57:08 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1195739826!10688844!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 16348 invoked from network); 22 Nov 2007 13:57:06 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 22 Nov 2007 13:57:06 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAMDv5oN029702; Thu, 22 Nov 2007 06:57:05 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id lAMDv5Ut012250; Thu, 22 Nov 2007 07:57:05 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id lAMDv45m012138; Thu, 22 Nov 2007 07:57:04 -0600 (CST) Message-ID: <47458AA5.2070009@gmail.com> Date: Thu, 22 Nov 2007 14:56:53 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 Subject: Re: [Autoconf] RE: [MEXT] Prefix Delegation documents References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> <47447F8F.3050103@azairenet.com> <005f01c82cd8$062d2880$12877980$@nl> In-Reply-To: <005f01c82cd8$062d2880$12877980$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071121-0, 21/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 1.6 (+) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: autoconf@ietf.org, 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 Teco Boot wrote: > Thanks for the clarifications. > > I wanted to know, as Prefix Delegation is being worked on in Autoconf > also. If Autoconf comes up with a third solution, it could be > difficult to manage in environments with equipment is both Mobile > Router (NEMO) and MANET Router (Autoconf). Are others also studying > this overlap in functionality? > > Maybe there are some issues with PD and DSMIPv6. Has anyone looked at > this? DS-MIPv6... I don't think it allocates prefixes in any way. I think DS-MIPv6 assumes that the underlying MIP6 implementation could allocate prefixes. Ie I take a MIP6 implementation, I enhance it with NEMOv6-MIP6-PD messages and then I enhance it further with DS-MIPv6 extensions. IPv6-IPv4... "Prefix Delegation" is somehow called "Subnet Allocation" for IPv4 in the DHCP WG. Status-wise the IPv4 "DHCP Subnet Allocation" has less impact, it's Informational, than DHCPv6-PD StdsTrack. However, technically on paper it seems to have more advanced features than DHCPv6-PD (I haven't checked "DHCP Subnet Allocation" implementation). > I suggest to keep the PD discussion in MEXT. What is "Prefix Delegation"? Is it DHCPv6-PD? Is it MIP6-based Prefix Delegation? Is it PMIPv6-based prefix allocation? I'd suggest for "Prefix Delegation" to mean "DHCPv6-PD" and only that, but can't enforce it I know. As such I think it can be discussed anywhere where people need a mechanism to autoconfigure prefixes (instead of just addresses). Alex > > Teco. > >> -----Oorspronkelijk bericht----- Van: Vijay Devarapalli >> [mailto:vijay.devarapalli@azairenet.com] Verzonden: woensdag 21 >> november 2007 19:57 Aan: Pascal Thubert (pthubert) CC: Teco Boot; >> mext@ietf.org Onderwerp: Re: [MEXT] Prefix Delegation documents >> >> Pascal Thubert (pthubert) wrote: >>> Hi Vijay >>> >>> My proposal to break the tie is this: >>> >>> - move draft-ietf-nemo-dhcpv6-pd-02.txt to informational track as >>> it documents a way to use DHCP-PD but does not need new >>> exchanges. Last >> I >>> checked, some components were still missing but Ralph knows >>> better. >>> >>> - focus on draft-ietf-nemo-prefix-delegation-02.txt for standard >> track. >>> The draft is agnostic to the delegation mechanism in the backend >>> and does not have dependencies. It proposes an integrated >>> mechanism that fits the general MIP6 / NEMO approach and formats. >>> >>> >>> What do you think? >> I am fine with this approach. >> >> For draft-ietf-nemo-prefix-delegation-02.txt, I would like to simplify the mechanism a bit, by removing the Mobile Network Prefix >> Confirm option. Just use the Mobile Network Prefix option for the >> home agent to send the prefix to the mobile router. I actually >> don't understand the need for the Mobile Network Prefix Confirm >> option. >> >> Vijay >> >>> Pascal >>> >>>> -----Original Message----- From: Vijay Devarapalli >>>> [mailto:vijay.devarapalli@AzaireNet.com] Sent: Tuesday, >>>> November 20, 2007 7:45 PM To: Teco Boot Cc: Pascal Thubert >>>> (pthubert); mext@ietf.org Subject: Re: [MEXT] Re: [nemo] Prefix >>>> Delegation documents >>>> >>>> Teco Boot wrote: >>>>> Hi Pascal, Question on WG documents for prefix delegation. >>>>> There are two of >>> them: >>>>> 1: draft-ietf-nemo-prefix-delegation-02.txt (August 21, 2007) >>>>> 2: draft-ietf-nemo-dhcpv6-pd-02.txt (September 28, 2006) Are >>>>> we still working on both solutions? >>>> We have a sort of stalemate on this. I believe Jari (AD) would >> prefer >>>> one solution in this space. I think the earlier decision by the >>>> NEMO WG was to standardize both solutions. Not sure what the >>>> consensus is right now. >>>> >>>> IMO, we should standardize one ASAP. Without a prefix >>>> delegation mechanism the only possible solution now is to >>>> pre-configure the mobile network prefix on the mobile router. >>>> This is not sufficient. >>>> >>>> Vijay > > > > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 22 09:33: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 1IvD6z-0002LE-Ne; Thu, 22 Nov 2007 09:33:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvD6y-0002Kn-ID; Thu, 22 Nov 2007 09:33:00 -0500 Received: from datnt07.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvD6y-0000IV-4t; Thu, 22 Nov 2007 09:33:00 -0500 X-AuditID: c26e2f18-00001fd800001938-83-474593087e15 Received: from camaro.eu.tieto.com ([192.176.143.43]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 16:32:40 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 15:32:57 +0100 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, 22 Nov 2007 15:32:56 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-mip6-nemo-v4traversal-06.txt Thread-Index: AcgtFJKL/l5uLNkJRuGpGLQVYdX/QA== From: To: X-OriginalArrivalTime: 22 Nov 2007 14:32:57.0860 (UTC) FILETIME=[9393EC40:01C82D14] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: mip6@ietf.org, mext@ietf.org Subject: [MEXT] Comments on draft-ietf-mip6-nemo-v4traversal-06.txt 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 A few comments on draft-ietf-mip6-nemo-v4traversal-06.txt o section 2.3.1, para 1, line 10: suggestion to change "it will be tunneled" to "the home agent will tunnel the packet" (just to ease the reading first time). o section 2.3.1, para 4, line 1: I think "routing header" should be "destination option". o section 2.3.2.2, para 3, line 9: change "IP v4" to "IPv4". o section 4.2, para 2, line 3: it does not read right that an IPv4 address can be compared to an IPv4 address in an IPv6 header. The packet diagram in the A paragraph below indicates the IPv4 address should be compared to the IPv4 CoA option. o section 4.2, para 8: Remove the "V6HOA (IPv6 home address)", a left over from previous revision, and instead insert "ESP-header", similar to the what is done in the binding update packet above. o section 4.3, para 1, line 10: The parameter NATKATIMEOUT is given the default value 110 seconds. However, RFC 3948 defining NAT keepalives, suggest 20 seconds. Not clear the reason for the=20 difference. o section 4.4.1 and section 4.5.1: in the two packets, just as UDP=20 header is shown as optional, also show ESP-tunnel headers as optional. o section 7: Change "Neilsen" to "Nielsen" (two places). =20 Thanks for honoring me in the acknowledgements. Christian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From Emanuele@albertdelahaye.nl Thu Nov 22 10:19:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvDpt-0003UP-Ao for nemo-archive@lists.ietf.org; Thu, 22 Nov 2007 10:19:25 -0500 Received: from [151.56.14.247] (helo=[151.56.14.247]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvDps-00026d-OM for nemo-archive@lists.ietf.org; Thu, 22 Nov 2007 10:19:25 -0500 Received: from martins ([162.160.23.31]:27945 "EHLO martins" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by adsl-87-93.37-151.net24.it with ESMTP id S22NRFWYESRUFEEX (ORCPT ); Thu, 22 Nov 2007 16:17:54 +0100 Message-ID: <000801c82d1a$c7556080$575d2597@martins> From: "Emanuele Lozin" To: Subject: prosuper Date: Thu, 22 Nov 2007 16:17:21 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C82D23.2919C880" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d ------=_NextPart_000_0007_01C82D23.2919C880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Do you believe in wonders? Neither had we We believed, ..till we = discovered newED treatmentset http://tinyhear.com/ ------=_NextPart_000_0007_01C82D23.2919C880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Do you believe in wonders? = Neither had we=20 We believed, ..till we discovered newED treatmentset
http://tinyhear.com/
------=_NextPart_000_0007_01C82D23.2919C880-- From BrettnicotineRichards@zabasearch.com Thu Nov 22 10:56:56 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvEQC-0005sJ-OO; Thu, 22 Nov 2007 10:56:56 -0500 Received: from pool-141-151-22-137.phlapa.east.verizon.net ([141.151.22.137] helo=family.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvEQC-0003G0-DW; Thu, 22 Nov 2007 10:56:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host25047837.zabasearch.com (8.13.1/8.13.1) with SMTP id 1bfqSsl505.139055.wYn.6G8.3190576278749 for ; Thu, 22 Nov 2007 10:56:18 +0500 Message-ID: From: "Nathaniel Banks" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_B6AA5_01C82D20.4755AE20-- From mext-bounces@ietf.org Thu Nov 22 11:58: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 1IvFNK-0001HF-9A; Thu, 22 Nov 2007 11:58:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFNI-0001GX-7N for mext@ietf.org; Thu, 22 Nov 2007 11:58:00 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvFNH-0005SN-FT for mext@ietf.org; Thu, 22 Nov 2007 11:58:00 -0500 X-IronPort-AV: E=Sophos;i="4.21,452,1188770400"; d="scan'208";a="158548587" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 Nov 2007 17:57:58 +0100 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 lAMGvwpW011542; Thu, 22 Nov 2007 17:57:58 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAMGvuZZ016924; Thu, 22 Nov 2007 16:57:58 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 17:57:56 +0100 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: [MEXT] Prefix Delegation documents Date: Thu, 22 Nov 2007 17:57:52 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04D3D35D@xmb-ams-337.emea.cisco.com> In-Reply-To: <47446BCB.5000000@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Prefix Delegation documents Thread-Index: AcgsZLAHqFY+waSTTqeayQq9vc1BWAAws4Qg References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> <47446BCB.5000000@gmail.com> From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 22 Nov 2007 16:57:56.0270 (UTC) FILETIME=[D43BF4E0:01C82D28] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3743; t=1195750678; x=1196614678; 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[MEXT]=20=20Prefix=20Delegation=20documents |Sender:=20; bh=TRueu/KV1T+pmR8asXsMkN61T0NGpEhAjCMsWI+YL+8=; b=YXWid61bglW6TKbQyOCBVKvbARWrzAzTyGixAvbMdDYsWrrjBZatQG3SV5DfQuKUF2S1NJYc pRd9TfVR1I4QvRixu1YdofBv6TAxENLG5t89bHmaoITkCFtFPz2NUL2S; 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: b5d20af10c334b36874c0264b10f59f1 Cc: Vijay Devarapalli , 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 Alex My take is that similar DHAAD flags should be present in both drafts for similar reasons; last I proposed it was rejected; I think that the argument was that locating the HA should be a DNS issue anyway. From the discussion we had recently with Romain, I still think that DHAAD and DNS can be complementary. You have some good points on DNS. But at this time we address prefixes not hosts. How the hosts on the MNP get names and publish those is an interesting issue but out of scope at this time. The fact that the HA uses NEMO extensions to pass the prefix to the MR does not preclude the use of a DHCP-PD server in the back end. It's just abstracting and simplifying that interaction. One problem with the DHCP-PD draft is lifetime of the lease: should it die with the MR-HA tunnel? The Nemo based draft is conscious of the volatility of the tunnel and the HA proxies the PD process for the MR based on the MR demands. =20 Pascal >-----Original Message----- >From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >Sent: Wednesday, November 21, 2007 6:33 PM >To: Pascal Thubert (pthubert) >Cc: Vijay Devarapalli; Teco Boot; mext@ietf.org >Subject: Re: [MEXT] Prefix Delegation documents > >Pascal Thubert (pthubert) wrote: >> Hi Vijay >> >> My proposal to break the tie is this: >> >> - move draft-ietf-nemo-dhcpv6-pd-02.txt to informational track as it >> documents a way to use DHCP-PD but does not need new exchanges. > >But as Romain pointed out, DHCP-PD as specified in this draft extends >DHAAD by adding a new D flag. If we want to avoid the use of the new D >flag then we should (probably) say in the DHCP-NEMO-PD draft how that >DHCPv6 Solicit is sent through the MR-HA tunnel (or not through tunnel) >and then relayed by the HA on the home link (or the HA is the DHCPv6 >Server). > >I think even if we move it to the Informational track then we still need >to improve some stuff in it according to implementation. Or just let it >float... I don't know. > >> Last I checked, some components were still missing but Ralph knows >> better. >> >> - focus on draft-ietf-nemo-prefix-delegation-02.txt for standard >> track. The draft is agnostic to the delegation mechanism in the >> backend and does not have dependencies. > >But it extends MIP6, right? (adds flags in messages). > >> It proposes an integrated mechanism that fits the general MIP6 / NEMO >> approach and formats. >> >> What do you think? > >I think we should not extend MIP6 to do prefix allocation. BEcause: > >-I think addressing autoconfiguration mechanisms DHCP and others are > already there for us to reuse and enhance eventually, no need to extend > MIP6. >-what happens when MIPv6 allocates a prefix and PMIPv6 allocates one > as well, but in a different way? (currently PMIPv6 doesn't seem to use > NEMO-MIP6-PD flags neither does NEMO-MIP6-PD use PMIPv6 way of putting > 0 to mean request prefix). Are the MIP6 and PMIP6 means to allocate > prefixes equivalent? >-what happens when we want the prefix delegated to the MR to be > accompanied by a delegation of responsibility of the DNS reverse > resolution as well? Can we reuse DHCP-DNS interactions (e.g. DNS > update RFC2136)? Or should we design a new MIP6-DNS interaction? > >That's simply opinion. I'm not sure about other criteria that came to >give the suggestion you made. > >Alex > > >______________________________________________________________________ >This email has been scanned by the MessageLabs Email Security System. >For more information please visit http://www.messagelabs.com/email >______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 22 12:11:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFal-0001Ne-Qi; Thu, 22 Nov 2007 12:11:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFaj-0001N9-O8 for mext@ietf.org; Thu, 22 Nov 2007 12:11:53 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvFag-0007cL-8z for mext@ietf.org; Thu, 22 Nov 2007 12:11:53 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-128.messagelabs.com!1195751508!7993209!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 10072 invoked from network); 22 Nov 2007 17:11:49 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-2.tower-128.messagelabs.com with SMTP; 22 Nov 2007 17:11:49 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id lAMHBhJR029542; Thu, 22 Nov 2007 10:11:43 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id lAMHBg09016033; Thu, 22 Nov 2007 11:11:42 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id lAMHBdIA016017; Thu, 22 Nov 2007 11:11:40 -0600 (CST) Message-ID: <4745B84B.6070002@gmail.com> Date: Thu, 22 Nov 2007 18:11:39 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [MEXT] Prefix Delegation documents References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> <47446BCB.5000000@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D35D@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04D3D35D@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071121-0, 21/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Vijay Devarapalli , 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 Pascal Thubert (pthubert) wrote: > Hi Alex > > My take is that similar DHAAD flags should be present in both drafts > for similar reasons; last I proposed it was rejected; I think that > the argument was that locating the HA should be a DNS issue anyway. > From the discussion we had recently with Romain, I still think that > DHAAD and DNS can be complementary. > > You have some good points on DNS. But at this time we address > prefixes not hosts. How the hosts on the MNP get names and publish > those is an interesting issue but out of scope at this time. How does CN reverse resolve the LFN's IPv6 address (for e.g. when it receives mail from it, to avoid spam)? I think MR or other DNS server _in_ the moving network should ultimately be in charge for that resolution (and not HA or some entities in the home net). And that can only be achieved if the mechanism of prefix allocation is tightly coupled with DNS. Otherwise, if you make MIP6 to delegate the prefix to MR then you should extend MIP6 to update the DNS server as well. I'm not saying this should be done, but that's the consequence, as I see it. I understand people may want to do everything with MIP6 (PMIP6, DS-MIP6, Monami6, NEMO, etc) but at some point there are some existing things that could be reused too. > The fact that the HA uses NEMO extensions to pass the prefix to the > MR does not preclude the use of a DHCP-PD server in the back end. > It's just abstracting and simplifying that interaction. I'm wondering of the necessity of this (a NEMO-MIP6 extension to support DHCPv6-PD). I doubt that's needed, DHCPv6-PD would work all by itself, I think. > One problem with the DHCP-PD draft is lifetime of the lease: should > it die with the MR-HA tunnel? The Nemo based draft is conscious of > the volatility of the tunnel and the HA proxies the PD process for > the MR based on the MR demands. Right problem leasetime I think. I think if either MIP6-NEMO-PD extensions or DHCPv6-PD is used then in any case the DHCPv6 binding lease at the DHCPv6 Server should not expire, I don't want another moving network to be allocated the same prefix, because I may connect my moving network to that other moving network and addresses may collide. I think overall it is important to stick to one mechanism for dynamically allocating prefixes. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 22 12:36: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 1IvFyd-00063r-2I; Thu, 22 Nov 2007 12:36:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFyb-00063m-Q2 for mext@ietf.org; Thu, 22 Nov 2007 12:36:33 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvFyb-0006tv-3Z for mext@ietf.org; Thu, 22 Nov 2007 12:36:33 -0500 X-IronPort-AV: E=Sophos;i="4.21,452,1188770400"; d="scan'208";a="158552222" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 Nov 2007 18:36:22 +0100 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 lAMHaMfZ021661; Thu, 22 Nov 2007 18:36:22 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAMHaAZb000052; Thu, 22 Nov 2007 17:36:17 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 18:35:40 +0100 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: [MEXT] Prefix Delegation documents Date: Thu, 22 Nov 2007 18:35:31 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04D3D392@xmb-ams-337.emea.cisco.com> In-Reply-To: <4745B84B.6070002@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Prefix Delegation documents Thread-Index: AcgtKtIwzMwzYHWXRl6jRqoh2lg6zQAAiISg References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> <47446BCB.5000000@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D35D@xmb-ams-337.emea.cisco.com> <4745B84B.6070002@gmail.com> From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 22 Nov 2007 17:35:40.0094 (UTC) FILETIME=[199415E0:01C82D2E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3710; t=1195752982; x=1196616982; 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[MEXT]=20=20Prefix=20Delegation=20documents |Sender:=20; bh=H5vdnzK3VEVni6lDkTqcysSAJD+7XeMe3JNRYASQiMU=; b=EpSNBNOsAZivddyafv9Qv5nevX5mQ5MnJEhmhb0ExP68twGN1JNafL1qs10D/O0eVT036CD6 orqnVuWPInjJxLc6JoKn7RiFSFOqzkSTkoWkdeFhEugiWxUIqQHYGXuZ; 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: 10d3e4e3c32e363f129e380e644649be Cc: Vijay Devarapalli , 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 Alex: There are actually examples where a short time lease is just what's needed. It's good for privacy and a number of other reasons like getting a prefix that is topologically correct not-too-far. One of those examples is that of a MR visiting a MANET and getting a local prefix for activity within that MANET that is topologically correct in the area (AUTOCONF) and from which the MR can form a CoA that it can keep as it moves around.=20 Using NEMO to get the prefix enables the mobility of the delegated prefix in and out the MANET - using or not the MANET protocol while in the MANET space - till the MR finds that the prefix is useless and forgets about it all. Pascal >-----Original Message----- >From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >Sent: Thursday, November 22, 2007 6:12 PM >To: Pascal Thubert (pthubert) >Cc: Vijay Devarapalli; Teco Boot; mext@ietf.org >Subject: Re: [MEXT] Prefix Delegation documents > >Pascal Thubert (pthubert) wrote: >> Hi Alex >> >> My take is that similar DHAAD flags should be present in both drafts >> for similar reasons; last I proposed it was rejected; I think that >> the argument was that locating the HA should be a DNS issue anyway. >> From the discussion we had recently with Romain, I still think that >> DHAAD and DNS can be complementary. >> >> You have some good points on DNS. But at this time we address >> prefixes not hosts. How the hosts on the MNP get names and publish >> those is an interesting issue but out of scope at this time. > >How does CN reverse resolve the LFN's IPv6 address (for e.g. when it >receives mail from it, to avoid spam)? I think MR or other DNS server >_in_ the moving network should ultimately be in charge for that >resolution (and not HA or some entities in the home net). > >And that can only be achieved if the mechanism of prefix allocation is >tightly coupled with DNS. > >Otherwise, if you make MIP6 to delegate the prefix to MR then you should >extend MIP6 to update the DNS server as well. I'm not saying this >should be done, but that's the consequence, as I see it. > >I understand people may want to do everything with MIP6 (PMIP6, DS-MIP6, >Monami6, NEMO, etc) but at some point there are some existing things >that could be reused too. > >> The fact that the HA uses NEMO extensions to pass the prefix to the >> MR does not preclude the use of a DHCP-PD server in the back end. >> It's just abstracting and simplifying that interaction. > >I'm wondering of the necessity of this (a NEMO-MIP6 extension to support >DHCPv6-PD). I doubt that's needed, DHCPv6-PD would work all by itself, >I think. > >> One problem with the DHCP-PD draft is lifetime of the lease: should >> it die with the MR-HA tunnel? The Nemo based draft is conscious of >> the volatility of the tunnel and the HA proxies the PD process for >> the MR based on the MR demands. > >Right problem leasetime I think. > >I think if either MIP6-NEMO-PD extensions or DHCPv6-PD is used then in >any case the DHCPv6 binding lease at the DHCPv6 Server should not >expire, I don't want another moving network to be allocated the same >prefix, because I may connect my moving network to that other moving >network and addresses may collide. > >I think overall it is important to stick to one mechanism for >dynamically allocating prefixes. > >Alex > > >______________________________________________________________________ >This email has been scanned by the MessageLabs Email Security System. >For more information please visit http://www.messagelabs.com/email >______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 22 12:50: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 1IvGBd-0002MT-VL; Thu, 22 Nov 2007 12:50:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvGBc-0002M5-HE for mext@ietf.org; Thu, 22 Nov 2007 12:50:00 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvGBb-0007Jt-Rh for mext@ietf.org; Thu, 22 Nov 2007 12:50:00 -0500 X-IronPort-AV: E=Sophos;i="4.21,452,1188770400"; d="scan'208";a="158552952" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 22 Nov 2007 18:49:50 +0100 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 lAMHno2s013382; Thu, 22 Nov 2007 18:49:50 +0100 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 lAMHe2Zn001489; Thu, 22 Nov 2007 17:49:50 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, 22 Nov 2007 18:44:07 +0100 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: [MEXT] Prefix Delegation documents Date: Thu, 22 Nov 2007 18:43:54 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04D3D39A@xmb-ams-337.emea.cisco.com> In-Reply-To: <47447F8F.3050103@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Prefix Delegation documents Thread-Index: AcgscGowMmRnVa9VT0+mF5f8ZQ140wAvmf/A References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> <47447F8F.3050103@azairenet.com> From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" X-OriginalArrivalTime: 22 Nov 2007 17:44:07.0653 (UTC) FILETIME=[481B7150:01C82D2F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3868; t=1195753790; x=1196617790; 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[MEXT]=20=20Prefix=20Delegation=20documents |Sender:=20; bh=6Zbpd8tjppj5Dk5NmQgMld+8HPouMyNqGUnFis1VtPY=; b=Fx512dKPwsOtmo+hFNVcNF9gwcsmGXV72DdNN/X8iiFtrhI8yDgbprZsK7O5JZyz169+di1R K9zpgH3kLG8tVFR2bPkyCuTV9PfGnDXGzTkzf8MzXBtpy8UmpV4+r6rw; 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: 34d35111647d654d033d58d318c0d21a 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 Vijay The reason for the new MNPC option is that the original option did not convey additional stuff that's required here. In particular, the corID avoids delegating multiple prefixes if a BAck is lost. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |P|I|D|Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CorID | Reserved2 | Prefix type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Mobile Network Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ But it's just one more value for the Type anyway and we still have plenty. What do you think? Pascal >-----Original Message----- >From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] >Sent: Wednesday, November 21, 2007 7:57 PM >To: Pascal Thubert (pthubert) >Cc: Teco Boot; mext@ietf.org >Subject: Re: [MEXT] Prefix Delegation documents > >Pascal Thubert (pthubert) wrote: >> Hi Vijay >> >> My proposal to break the tie is this: >> >> - move draft-ietf-nemo-dhcpv6-pd-02.txt to informational track as it >> documents a way to use DHCP-PD but does not need new exchanges. Last I >> checked, some components were still missing but Ralph knows better. >> >> - focus on draft-ietf-nemo-prefix-delegation-02.txt for standard track. >> The draft is agnostic to the delegation mechanism in the backend and >> does not have dependencies. It proposes an integrated mechanism that >> fits the general MIP6 / NEMO approach and formats. >> >> What do you think? > >I am fine with this approach. > >For draft-ietf-nemo-prefix-delegation-02.txt, I would like to >simplify the mechanism a bit, by removing the Mobile Network >Prefix Confirm option. Just use the Mobile Network Prefix >option for the home agent to send the prefix to the mobile >router. I actually don't understand the need for the Mobile >Network Prefix Confirm option. > >Vijay > >> >> Pascal >> >>> -----Original Message----- >>> From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] >>> Sent: Tuesday, November 20, 2007 7:45 PM >>> To: Teco Boot >>> Cc: Pascal Thubert (pthubert); mext@ietf.org >>> Subject: Re: [MEXT] Re: [nemo] Prefix Delegation documents >>> >>> Teco Boot wrote: >>>> Hi Pascal, >>>> Question on WG documents for prefix delegation. There are two of >> them: >>>> 1: draft-ietf-nemo-prefix-delegation-02.txt (August 21, 2007) >>>> 2: draft-ietf-nemo-dhcpv6-pd-02.txt (September 28, 2006) >>>> Are we still working on both solutions? >>> We have a sort of stalemate on this. I believe Jari (AD) would prefer >>> one solution in this space. I think the earlier decision by the NEMO >>> WG was to standardize both solutions. Not sure what the consensus is >>> right now. >>> >>> IMO, we should standardize one ASAP. Without a prefix delegation >>> mechanism the only possible solution now is to pre-configure the >>> mobile network prefix on the mobile router. This is not sufficient. >>> >>> Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 22 14:18: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 1IvHYq-000770-Cx; Thu, 22 Nov 2007 14:18:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvHYn-00076b-0U for mext@ietf.org; Thu, 22 Nov 2007 14:18:01 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvHYm-0001xd-G8 for mext@ietf.org; Thu, 22 Nov 2007 14:18:00 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-153.messagelabs.com!1195759079!10564602!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 10337 invoked from network); 22 Nov 2007 19:17:59 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-14.tower-153.messagelabs.com with SMTP; 22 Nov 2007 19:17:59 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lAMJHlq8014403; Thu, 22 Nov 2007 12:17:47 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lAMJHkR1029567; Thu, 22 Nov 2007 13:17:47 -0600 (CST) Received: from [127.0.0.1] (mvp-10-169-4-67.corp.mot.com [10.169.4.67]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id lAMJHg4l029554; Thu, 22 Nov 2007 13:17:44 -0600 (CST) Message-ID: <4745D5D5.10905@gmail.com> Date: Thu, 22 Nov 2007 20:17:41 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [MEXT] Prefix Delegation documents References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> <47446BCB.5000000@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D35D@xmb-ams-337.emea.cisco.com> <4745B84B.6070002@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D392@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04D3D392@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071122-0, 22/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Vijay Devarapalli , 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 Salut Pascal, Pascal Thubert (pthubert) wrote: > Hi Alex: > > There are actually examples where a short time lease is just what's > needed. It's good for privacy and a number of other reasons like > getting a prefix that is topologically correct not-too-far. I can agree that that there are scenarios where short time leases of a prefix allocated by DHCP to a Mobile Router make sense. A user PAN is an example. (a larger entity as a ship doing on2ly 2-3 handovers during a transatlantic cruise probably needs more lease time). I wanted to say that there are also scenarios where prefixes allocated to a moving network are longer term, and the MR-HA tunnel being down shouldn't mean that that prefix is no longer used in that ship. > One of those examples is that of a MR visiting a MANET and getting a > local prefix for activity within that MANET that is topologically > correct in the area (AUTOCONF) and from which the MR can form a CoA > that it can keep as it moves around. Somehow yes, I agree with you Mobile Router visiting a MANET and getting a 'local' prefix (but still 'global' topologically correct) from it it will probably be short-lived. > Using NEMO to get the prefix enables the mobility of the delegated > prefix in and out the MANET - using or not the MANET protocol while > in the MANET space - till the MR finds that the prefix is useless and > forgets about it all. In order for the MANET network to deliver prefixes to visitors, do you think a MANET network is more likely to run a HA inside or a DHCPv6 Server? (my Windows Mobile PDA runs DHCPv4 Server, to not name a manufacturer). Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 22 14:29: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 1IvHja-0000XP-1B; Thu, 22 Nov 2007 14:29:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvHjX-0000KM-FP for mext@ietf.org; Thu, 22 Nov 2007 14:29:07 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvHjU-0003oQ-8T for mext@ietf.org; Thu, 22 Nov 2007 14:29:07 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 22 Nov 2007 11:29:03 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAMJT3TW026980; Thu, 22 Nov 2007 11:29:03 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAMJT3b5007585; Thu, 22 Nov 2007 19:29:03 GMT Date: Thu, 22 Nov 2007 11:29:03 -0800 (PST) From: Sri Gundavelli To: George Tsirtsis Subject: Re: [MEXT] Re: was Re: [Monami6] returning home issue in MCoA In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1608; t=1195759743; x=1196623743; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20Re=3A=20was=20Re=3A=20[Monami6]=20returning= 20home=20issue=20in=20MCoA |Sender:=20; bh=kswD+hMZiyz8pagV/QjwYCI7mdphpraACG4NR6FO0rw=; b=ouc3uYhoaoYw51b2ESSZhPYmSJeVNJij79BsKQa4no5DKNwojIdaNRDxwP89y4bENgomauJm uUX2+ho4uq/n6UGpp9G7TWW5eUz4+vt3oWIxYahQHBjJKfjKtMAjZ0G6; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 George, On Thu, 22 Nov 2007, George Tsirtsis wrote: > Yes I agree that allowing the HA to continue intercepting the packets > is necessary if the HA is supposed to direct at least some of them > away from the home link. > > The question then is how packets are sent by the HA to the mobile over > the home link. If the home link is a p2p link there should be no > issue, but on shared links how is the l2 address of the mobile > discovered by the HA? One way would be the mobile to add it in the BU > it sends to the HA to indicate such a partial deregistration but it > sounds like too much of a layer violation. Another could be for the HA > to do a reverse lookup one the address on the link to discover the mac > address of the mobile. > Its not just about the home agent learning the L2 address of the mobile node. Assuming HA intercepts the packets and it has the ability to route some of those intercepted packets to the home interface of the mobile node and some over the tunnel and to a different interface of the mobile node. But, for the other direction, how can the mobile node use the home interface to send any packets. What is neigbor view of that home address with respect to HoA ownership and the L2 association ? IMO, the solution is not simple and requires some fundamental changes that are beyond the monami scope and can always be addressed outside this doc. Also, if the home link is a p2p link, this is not an issue. HA is always in the path and L2 address has little purpose there. But, p2p home link assumption is a big assumption. Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 22 15:03:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvIGR-0000sn-Mm; Thu, 22 Nov 2007 15:03:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvIGQ-0000sd-0W for mext@ietf.org; Thu, 22 Nov 2007 15:03:06 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvIGL-00051a-66 for mext@ietf.org; Thu, 22 Nov 2007 15:03:05 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 22 Nov 2007 12:03:00 -0800 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 lAMK30Oh005637; Thu, 22 Nov 2007 12:03:00 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAMK2pb4023294; Thu, 22 Nov 2007 20:02:51 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, 22 Nov 2007 12:02:50 -0800 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 12:02:49 -0800 From: "Sri Gundavelli" To: "'Jari Arkko'" , References: <47420EC7.80606@piuha.net> Subject: RE: [MEXT] MEXT charter Date: Thu, 22 Nov 2007 12:02:49 -0800 Message-ID: <022701c82d42$a85d5700$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47420EC7.80606@piuha.net> Thread-Index: Acgq/Ajun+u5wxM3T4Shh0xHevXcqQCRf+CA X-OriginalArrivalTime: 22 Nov 2007 20:02:49.0415 (UTC) FILETIME=[A8438D70:01C82D42] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=15877; t=1195761780; x=1196625780; 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[MEXT]=20MEXT=20charter |Sender:=20; bh=mlTRQRlGJrzS/XR6tVDcjPAgMsZrp6ULBvy9L0+uVsA=; b=bQvkFDoDS9T/TxttcfqcAbNeXG0f/J6DH+7eJ/RmSnLk6/qiiuk/fPDbiDsI58imqDuVuIKy UnNaPAeKFIqiOmTWFk2O8jb20OX0BXh5HcG5CXRg9TLnj4FPRLuZXWIe; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Cc: 'Julien Laganier' 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 This is a WG document and I thought this was in the charter and does not require a charter update. https://www.ietf.org/internet-drafts/draft-ietf-mip6-generic-notification-me ssage-00.txt Sri > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Monday, November 19, 2007 2:32 PM > To: mext@ietf.org > Subject: [MEXT] MEXT charter > > > The charter that I sent to the secretary is shown below. I've > updated the milestones plus taken some of the editorial > comments from Thierry and Nicolas into account. However, > I did not want to make any bigger changes due to the discussion > we had with them in Chicago, because that would require a > new IESG approval. But I note that given the interest for > binding revocation, a charter update will probably be > needed soon anyway. We can take care of remaining issues > there. > > ---- > > Mobility EXTensions for IPv6 (MEXT) > > > 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, network mobility (NEMO) 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 (Mobile IPv6) > o RFC 3963 (NEMO) > o RFC 4877 (Mobile IPv6 Operation with IKEv2) > > The MEXT Working Group continues the work of the former 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 Mobile IPv6 and NEMO 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 Mobile IPv6 or NEMO capable dual-stack hosts. > > (A.2) A protocol based solution for enhancing the reliability of home > agents and a method to force a host/router 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: > > Done Submit I-D 'Mobile IPv6 Vendor Specific Option' > to IESG for > publication as a Proposed Standard > Done Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG > for publication as a Proposed Standard. > Done Submit I-D 'Mobility Header Home Agent Switch Message' to > IESG for publication as a Proposed Standard. > > Dec 2007 Submit Multiple CoA Registration to IESG > Dec 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for > publication as Informational. > Dec 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for > publication as a Proposed Standard. > > Feb 2008 Submit -00 draft on Route Optimization Needs for Aircraft > and Spacecraft Deployments > Feb 2008 Submit -00 draft on Route Optimization Needs for > Automobile > and Highway Deployments > Feb 2008 Submit -00 draft on Route Optimization needs for Personal > Mobile Router > Feb 2008 Submit I-D 'Goals for AAA HA Interface' to IESG for > publication as Informational. > > Mar 2008 Submit the final doc on Prefix Delegation for NEMO to the > IESG, for Proposed Standard > > May 2008 Submit -00 draft for solution to > aircraft/spacecraft problem > May 2008 Submit final doc on Route Optimization Needs for Aircraft > and Spacecraft Deployments, for Informational > May 2008 Submit final doc on Route Optimization Needs for > Automobile > and Highway Deployments, for Informational > May 2008 Submit final doc on Route Optimization needs for Personal > Mobile Router, for Informational > > Jun 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for > publication as a proposed standard. > Jun 2008 Determine how to proceed with 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 the final doc on MIB for NEMO Basic Support to the > IESG, for Proposed Standard > Aug 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG > for publication as Informational. > > Oct 2008 Submit Flow/binding policy format to IESG, for > Proposed Standard > Oct 2008 Submit Flow/binding policy transport to IESG, for Proposed > Standard > > Nov 2008 Submit final doc for solution to > aircraft/spacecraft problem > to the IESG, for Proposed Standard > Nov 2008 Recharter to work on the remaining automotive/Personal > Mobile Router solutions > > Dec 2008 Submit I-D(s) related to specific updates and > corrections of > RFC 3775 to IESG for publication as Proposed Standard. > Dec 2008 Submit I-D 'Home agent reliability' to IESG for > publication > as a Proposed Standard. > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 22 16:56: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 1IvK1v-0003aD-6w; Thu, 22 Nov 2007 16:56:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvK1u-0003a7-8J for mext@ietf.org; Thu, 22 Nov 2007 16:56:14 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvK1t-0008Bo-HV for mext@ietf.org; Thu, 22 Nov 2007 16:56:14 -0500 Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Nov 2007 13:56:12 -0800 Message-ID: <4745FAF9.8050109@azairenet.com> Date: Thu, 22 Nov 2007 13:56:09 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [MEXT] Prefix Delegation documents References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> <47446BCB.5000000@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D35D@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04D3D35D@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Nov 2007 21:56:12.0500 (UTC) FILETIME=[7F37F140:01C82D52] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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 I don't believe it is necessary to extend DHAAD for NEMO prefix delegation. The mobile router could assume that the home agent it is bootstrapping does support a mechanism for assigning prefixes for the mobile network. I don't think we have any home agents deployed today that support mobile routers to worry about. :) So it would be safe to assume that a home agent that supports mobile routers also supports a mechanism to assign a mobile network prefix. Vijay Pascal Thubert (pthubert) wrote: > Hi Alex > > My take is that similar DHAAD flags should be present in both drafts for > similar reasons; last I proposed it was rejected; I think that the > argument was that locating the HA should be a DNS issue anyway. From the > discussion we had recently with Romain, I still think that DHAAD and DNS > can be complementary. > > You have some good points on DNS. But at this time we address prefixes > not hosts. How the hosts on the MNP get names and publish those is an > interesting issue but out of scope at this time. > > The fact that the HA uses NEMO extensions to pass the prefix to the MR > does not preclude the use of a DHCP-PD server in the back end. It's just > abstracting and simplifying that interaction. One problem with the > DHCP-PD draft is lifetime of the lease: should it die with the MR-HA > tunnel? The Nemo based draft is conscious of the volatility of the > tunnel and the HA proxies the PD process for the MR based on the MR > demands. > > > Pascal > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Wednesday, November 21, 2007 6:33 PM >> To: Pascal Thubert (pthubert) >> Cc: Vijay Devarapalli; Teco Boot; mext@ietf.org >> Subject: Re: [MEXT] Prefix Delegation documents >> >> Pascal Thubert (pthubert) wrote: >>> Hi Vijay >>> >>> My proposal to break the tie is this: >>> >>> - move draft-ietf-nemo-dhcpv6-pd-02.txt to informational track as it >>> documents a way to use DHCP-PD but does not need new exchanges. >> But as Romain pointed out, DHCP-PD as specified in this draft extends >> DHAAD by adding a new D flag. If we want to avoid the use of the new D >> flag then we should (probably) say in the DHCP-NEMO-PD draft how that >> DHCPv6 Solicit is sent through the MR-HA tunnel (or not through tunnel) >> and then relayed by the HA on the home link (or the HA is the DHCPv6 >> Server). >> >> I think even if we move it to the Informational track then we still > need >> to improve some stuff in it according to implementation. Or just let > it >> float... I don't know. >> >>> Last I checked, some components were still missing but Ralph knows >>> better. >>> >>> - focus on draft-ietf-nemo-prefix-delegation-02.txt for standard >>> track. The draft is agnostic to the delegation mechanism in the >>> backend and does not have dependencies. >> But it extends MIP6, right? (adds flags in messages). >> >>> It proposes an integrated mechanism that fits the general MIP6 / NEMO >>> approach and formats. >>> >>> What do you think? >> I think we should not extend MIP6 to do prefix allocation. BEcause: >> >> -I think addressing autoconfiguration mechanisms DHCP and others are >> already there for us to reuse and enhance eventually, no need to > extend >> MIP6. >> -what happens when MIPv6 allocates a prefix and PMIPv6 allocates one >> as well, but in a different way? (currently PMIPv6 doesn't seem to > use >> NEMO-MIP6-PD flags neither does NEMO-MIP6-PD use PMIPv6 way of > putting >> 0 to mean request prefix). Are the MIP6 and PMIP6 means to allocate >> prefixes equivalent? >> -what happens when we want the prefix delegated to the MR to be >> accompanied by a delegation of responsibility of the DNS reverse >> resolution as well? Can we reuse DHCP-DNS interactions (e.g. DNS >> update RFC2136)? Or should we design a new MIP6-DNS interaction? >> >> That's simply opinion. I'm not sure about other criteria that came to >> give the suggestion you made. >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 22 17:00: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 1IvK5v-0007Qf-2Q; Thu, 22 Nov 2007 17:00:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvK5s-0007HJ-DP for mext@ietf.org; Thu, 22 Nov 2007 17:00:20 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvK5p-0000mc-KA for mext@ietf.org; Thu, 22 Nov 2007 17:00:20 -0500 Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Nov 2007 14:00:16 -0800 Message-ID: <4745FBEF.6080603@azairenet.com> Date: Thu, 22 Nov 2007 14:00:15 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [MEXT] Prefix Delegation documents References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> <47447F8F.3050103@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D39A@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04D3D39A@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Nov 2007 22:00:17.0014 (UTC) FILETIME=[10F5D160:01C82D53] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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 Pascal Thubert (pthubert) wrote: > Hi Vijay > > The reason for the new MNPC option is that the original option did not > convey additional stuff that's required here. In particular, the corID > avoids delegating multiple prefixes if a BAck is lost. ?? Why would the HA allocate a new prefix every time the BU is sent? When the mobile router requests for one or prefixes, the home agent responds with one or more prefixes. From there on, subsequent binding updates sent to refresh an existing binding will not contain any more requests for prefixes. If the Binding Ack is lost, the MN retransmits the BU. At that time, the HA assumes the mobile router lost state for some reason and is requesting for its prefixes again. Then the HA would send the same set of prefixes that were allocated earlier to the mobile router. No new prefixes. I must be missing something. Vijay > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Prefix Length |P|I|D|Reserved1| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | CorID | Reserved2 | Prefix type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Valid Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Mobile Network Prefix + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > But it's just one more value for the Type anyway and we still have > plenty. > > What do you think? > > Pascal > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] >> Sent: Wednesday, November 21, 2007 7:57 PM >> To: Pascal Thubert (pthubert) >> Cc: Teco Boot; mext@ietf.org >> Subject: Re: [MEXT] Prefix Delegation documents >> >> Pascal Thubert (pthubert) wrote: >>> Hi Vijay >>> >>> My proposal to break the tie is this: >>> >>> - move draft-ietf-nemo-dhcpv6-pd-02.txt to informational track as it >>> documents a way to use DHCP-PD but does not need new exchanges. Last > I >>> checked, some components were still missing but Ralph knows better. >>> >>> - focus on draft-ietf-nemo-prefix-delegation-02.txt for standard > track. >>> The draft is agnostic to the delegation mechanism in the backend and >>> does not have dependencies. It proposes an integrated mechanism that >>> fits the general MIP6 / NEMO approach and formats. >>> >>> What do you think? >> I am fine with this approach. >> >> For draft-ietf-nemo-prefix-delegation-02.txt, I would like to >> simplify the mechanism a bit, by removing the Mobile Network >> Prefix Confirm option. Just use the Mobile Network Prefix >> option for the home agent to send the prefix to the mobile >> router. I actually don't understand the need for the Mobile >> Network Prefix Confirm option. >> >> Vijay >> >>> Pascal >>> >>>> -----Original Message----- >>>> From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] >>>> Sent: Tuesday, November 20, 2007 7:45 PM >>>> To: Teco Boot >>>> Cc: Pascal Thubert (pthubert); mext@ietf.org >>>> Subject: Re: [MEXT] Re: [nemo] Prefix Delegation documents >>>> >>>> Teco Boot wrote: >>>>> Hi Pascal, >>>>> Question on WG documents for prefix delegation. There are two of >>> them: >>>>> 1: draft-ietf-nemo-prefix-delegation-02.txt (August 21, 2007) >>>>> 2: draft-ietf-nemo-dhcpv6-pd-02.txt (September 28, 2006) >>>>> Are we still working on both solutions? >>>> We have a sort of stalemate on this. I believe Jari (AD) would > prefer >>>> one solution in this space. I think the earlier decision by the NEMO >>>> WG was to standardize both solutions. Not sure what the consensus is >>>> right now. >>>> >>>> IMO, we should standardize one ASAP. Without a prefix delegation >>>> mechanism the only possible solution now is to pre-configure the >>>> mobile network prefix on the mobile router. This is not sufficient. >>>> >>>> Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 22 18:29: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 1IvLTS-0003kM-1Z; Thu, 22 Nov 2007 18:28:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvLTQ-0003kF-Vh for mext@ietf.org; Thu, 22 Nov 2007 18:28:45 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvLTM-0002q5-CS for mext@ietf.org; Thu, 22 Nov 2007 18:28:41 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id lAMNSMEV003860; Fri, 23 Nov 2007 08:28:22 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id lAMNSNN08227; Fri, 23 Nov 2007 08:28:23 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id lAMNSMV19611; Fri, 23 Nov 2007 08:28:22 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/soml24) id lAMNSMMf005401; Fri, 23 Nov 2007 08:28:22 +0900 (JST) Received: from [10.238.172.34] by soml24.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id lAMNSLM6005385; Fri, 23 Nov 2007 08:28:21 +0900 (JST) Date: Fri, 23 Nov 2007 08:28:23 +0900 From: Keigo Aso To: "George Tsirtsis" Subject: Re: [MEXT] Re: was Re: [Monami6] returning home issue in MCoA In-Reply-To: References: Message-Id: <20071123065838.B694.ASOU.KEIGO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 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 Hello George, "George Tsirtsis" wrote: > Yes I agree that allowing the HA to continue intercepting the packets > is necessary if the HA is supposed to direct at least some of them > away from the home link. > > The question then is how packets are sent by the HA to the mobile over > the home link. If the home link is a p2p link there should be no > issue, but on shared links how is the l2 address of the mobile > discovered by the HA? One way would be the mobile to add it in the BU > it sends to the HA to indicate such a partial deregistration but it > sounds like too much of a layer violation. Another could be for the HA > to do a reverse lookup one the address on the link to discover the mac > address of the mobile. I agree with what you said above. P2P case has no issue. Actually p2p home link is considerable as the actual deployment and in that case, the connection between HA and MN would be wireless. So, the returning home scenario is necessity for HA and MN for switching path, which should be solved by MCoA, I also think so. 'H' flag in current MCoA is simple way for this p2p link scenario. MN sends BU with 'H' flag and then HA stops ProxyND for the ingress interface connecting to the home link. After that, MN can start NDP for own HoA. If HA needs to do ProxyND for intercepting packets for MN's HoA, it can do it for the egress interface. Of course if HA can intercept packets by IP routing, no need to do it. While, for the shared link case, actually we can use a option such as Link-Layer Address (LLA) Option by RFC4068(FMIP) for the way of BU to include l2 address which you proposed. I think this is possible way. Regards, Keigo > > George > > On 21/11/2007, George Tsirtsis wrote: > > To respond to Nikolas initial question on this issue I think that > > simultaneous home-foreign connectivity issues should be discussed and > > resolved as part of the MCoA draft. In any case Ryuji already listed a > > number of options, not all of which are too complex. It seems to me that ND > > proxying or not, by who, and when is the only remaining question :-) > > > > I have to say that the H flag and the description of this in MCoA-v4 is not > > yet clear enough so there is certainly more work to be done here. > > > > I am also going to send additional comments on the MCoA draft separately. > > > > Thanks > > George > > P.S.: I moved this to MEXT list now, and below is the last e-mail I received > > on this issue on monami6 list....not sure if I missed anything in between. > > > > > > > > -----Original Message----- > > From: Keigo Aso [mailto:asou.keigo@jp.panasonic.com] > > Sent: Monday, November 19, 2007 1:52 AM > > To: Monami6 WG > > Subject: Re: [Monami6] returning home issue in MCoA > > > > > > > > Hi Ryuji, > > > > > > > > On Sun, 18 Nov 2007 11:36:49 +0900 > > > > RYUJI WAKIKAWA wrote: > > > > > > > > > Hi Vijay, > > > > > > > > > > On 2007/11/18, at 7:05, Vijay Devarapalli wrote: > > > > > > > > > > > RYUJI WAKIKAWA wrote: > > > > > > > > > > > >>> But now I puzzled why the HA would be turning of proxy ND? I think > > > > > >>> the HA should still continue proxying the home address of the mobile > > > > > >>> node and intercept the packets. > > > > > >> Then, HA and MN will meet the address duplication. > > > > > >> MN tries to defend its HoA on the home link and HA also tries to do > > > > > >> the same by Proxy ND. > > > > > > > > > > > > No. The MN does not attempt to defend its address when it knows > > > > > > that it has another binding from a visited link. It knows that > > > > > > the HA will be proxying its home address. Basically the HA would > > > > > > defined whether to send the traffic directly to the home address > > > > > > on the link or tunnel to the CoA that the MN has registered at > > > > > > the HA. The HA would make the decision based on the type of > > > > > > packet/flow.. > > > > > > > > > > > >>> The HA then decides how to forward the packet. If the packet is > > > > > >>> meant the MN interface which is not attached to the home link, the > > > > > >>> packet should be tunneled to the mobile node on the visited link. If > > > > > >>> the packet is meant for the MN interface which is attached to the > > > > > >>> home link, the HA delivers it directly. The tricky part would be to > > > > > >>> create a neighbor cache entry for the mobile node so that the HA > > > > > >>> can deliver the packet on-link. The HA would need to know the L2 > > > > > >>> address of the interface with which the mobile node is attached to > > > > > >>> the home link. > > > > > >> Do you suggest to modify ND parts for this? > > > > > > > > > > > > Is there a need to modify neighbor discovery? As long as the > > > > > > HA has the layer 2 address that corresponds to the interface > > > > > > with which the mobile node is attached to the home link, it can > > > > > > construct a neighbor cache entry or for example construct the > > > > > > ether header. > > > > > > > > > > It sounds similar to the MN's operation of sending dereg-BU from home > > > > > link. > > > > > > > > > > - How can HA learn the MN's L2 address. > > > > > - when MN communicates with CN on the home link, the packets are > > > > > always routed through the HA > > > > > - Regardless of binding status, HA MUST defend the HoA at the home link. > > > > > While MN is back to home with multiple bindings, HA will intercept > > > > > all the packets and decides how to deliver the packets to MN. However, > > > > > if MN stop using the interfaces attached to foreign link, HA will no > > > > > longer defend the HoA. It means MN MUST start defending own HoA at the > > > > > home link. I think this is a bit tricky. HA should do proxy NDP for > > > > > HoA regardless of binding status of MN. > > > > > - From the implementation experience of returning home, it is very > > > > > hard to implement this;-p > > > > > > > > I think it is better to assume HA is a router on the home link as described > > in > > > > your draft no-ndp-00 in order to avoid to introduce needless complexity > > here. > > > > When MN connects to both home and foreign link, if HA can see all packets > > for > > > > the HoA of the MN by IP routing, it would not need to do proxy ND for > > > > intercepting packets. MN can do ND for own HoA here. > > > > While, when MN's both interfaces connects to foreign link, HA should do > > proxy ND > > > > for defending the HoA of the MN, according to RFC3775. > > > > > > > > And, I agree with Vijay's comments. > > > > Even when MN connects to both home and foreign link, HA can do proxy ND for > > the > > > > network which its egress interface connects to for intercepting packets for > > the > > > > HoA of the MN. > > > > In this case, I think it is better for HA to stop proxy ND for the home > > link. > > > > If so, MN can start ND for defeinding own HoA and HA can know MN's L2 > > address. > > > > There is no change on ProxyND in home link defined by RFC3775. > > > > > > > > Regards, > > > > Keigo > > > > > > > > > > > > > > ryuji > > > > > > > > > > > > > > > > > > > > > Vijay > > > > > > > > > > > >> ryuji > > > > > >>> > > > > > >>> > > > > > >>> Vijay > > > > > >>> > > > > > >>>> If you answer YES to the question above, > > > > > >>>> Should MCoA document support this feature? > > > > > >>>> [ ] YES > > > > > >>>> [ ] NO (not in MCoA, but in a separate document) > > > > > >>>> The deadline for this consensus call is October the 8th 2007. > > > > > >>>> Thank you, > > > > > >>>> Monami6 chairs > > > > > >>>> _______________________________________________ > > > > > >>>> Monami6 mailing list > > > > > >>>> Monami6@ietf.org > > > > > >>>> https://www1.ietf.org/mailman/listinfo/monami6 > > > > > >>> > > > > > >>> > > > > > >>> _______________________________________________ > > > > > >>> Monami6 mailing list > > > > > >>> Monami6@ietf.org > > > > > >>> https://www1.ietf.org/mailman/listinfo/monami6 > > > > > >> _______________________________________________ > > > > > >> Monami6 mailing list > > > > > >> Monami6@ietf.org > > > > > >> https://www1.ietf.org/mailman/listinfo/monami6 > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Monami6 mailing list > > > > > > Monami6@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/monami6 > > > > > > > > > > > > > > > _______________________________________________ > > > > > Monami6 mailing list > > > > > Monami6@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/monami6 > > > > > > > > > > > > > > > > _______________________________________________ > > > > Monami6 mailing list > > > > Monami6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/monami6 > > > > _______________________________________________ > 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 FranciscaaffirmAkins@britneyimages.com Thu Nov 22 22:04:40 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvOqO-0007LF-MQ; Thu, 22 Nov 2007 22:04:40 -0500 Received: from c-24-128-46-69.hsd1.nh.comcast.net ([24.128.46.69] helo=shelly.hsd1.nh.comcast.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvOqO-0000At-CE; Thu, 22 Nov 2007 22:04:40 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host65354975.britneyimages.com (8.13.1/8.13.1) with SMTP id Ag8bOzff81.537855.80Z.TPf.2757148920543 for ; Thu, 22 Nov 2007 21:59:08 +0500 Message-ID: <11f3e01c82d7c$dffd6760$6401a8c0@SHELLY> From: "Estella Abraham" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_11F3A_01C82D7C.DFFD6760-- From mext-bounces@ietf.org Thu Nov 22 23:17:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvPyA-0005O6-OL; Thu, 22 Nov 2007 23:16:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvPy9-0005Nq-CZ for mext@ietf.org; Thu, 22 Nov 2007 23:16:45 -0500 Received: from web84107.mail.mud.yahoo.com ([68.142.206.194]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvPy8-0001t6-4S for mext@ietf.org; Thu, 22 Nov 2007 23:16:45 -0500 Received: (qmail 46212 invoked by uid 60001); 23 Nov 2007 04:16:43 -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=II5yNgUFibBlVoGfoe6sCmiLy2ulF633a34yv5m7rv/AvA2rogGASqnC49GurG6gfoBZbRIl2M2mMqHTofZ1YUJkOs4WIbfA6ll9zSwxjKH4ZlOkQgcKmmvpOfWmGamWllyqqkdVDKu0Z12qXlOLg6YTS5OEO+QmKv6supYdukg=; X-YMail-OSG: jV49Yd0VM1ksutSwFeHcobYjZQRq4OHqmWKbR0RlLAg2_.rjtoYbwb6WIM1Xkn5KlH8RmsULCx3rZkPuN_25wf8AZRP2Ueah_cZdjM8Koc.TpSZ.diZTLQITTA-- Received: from [71.123.247.57] by web84107.mail.mud.yahoo.com via HTTP; Thu, 22 Nov 2007 20:16:43 PST X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.152 Date: Thu, 22 Nov 2007 20:16:43 -0800 (PST) From: Behcet Sarikaya Subject: Re: [MEXT] Prefix Delegation documents To: Vijay Devarapalli MIME-Version: 1.0 Message-ID: <550106.45780.qm@web84107.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1471929613==" Errors-To: mext-bounces@ietf.org --===============1471929613== Content-Type: multipart/alternative; boundary="0-1502981316-1195791403=:45780" --0-1502981316-1195791403=:45780 Content-Type: text/plain; charset=us-ascii Hi Vijay, I agree with you. Regarding the status of the draft, it is possible to have the document to be standards track even if it does not define any new messages/parameters. An example is draft-ietf-16ng-ipv6-over-ipv6cs-11 Regards, Behcet ----- Original Message ---- From: Vijay Devarapalli To: Pascal Thubert (pthubert) Cc: mext@ietf.org Sent: Thursday, November 22, 2007 3:56:09 PM Subject: Re: [MEXT] Prefix Delegation documents I don't believe it is necessary to extend DHAAD for NEMO prefix delegation. The mobile router could assume that the home agent it is bootstrapping does support a mechanism for assigning prefixes for the mobile network. I don't think we have any home agents deployed today that support mobile routers to worry about. :) So it would be safe to assume that a home agent that supports mobile routers also supports a mechanism to assign a mobile network prefix. Vijay Pascal Thubert (pthubert) wrote: > Hi Alex > > My take is that similar DHAAD flags should be present in both drafts for > similar reasons; last I proposed it was rejected; I think that the > argument was that locating the HA should be a DNS issue anyway. From the > discussion we had recently with Romain, I still think that DHAAD and DNS > can be complementary. > > You have some good points on DNS. But at this time we address prefixes > not hosts. How the hosts on the MNP get names and publish those is an > interesting issue but out of scope at this time. > > The fact that the HA uses NEMO extensions to pass the prefix to the MR > does not preclude the use of a DHCP-PD server in the back end. It's just > abstracting and simplifying that interaction. One problem with the > DHCP-PD draft is lifetime of the lease: should it die with the MR-HA > tunnel? The Nemo based draft is conscious of the volatility of the > tunnel and the HA proxies the PD process for the MR based on the MR > demands. > > > Pascal > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Wednesday, November 21, 2007 6:33 PM >> To: Pascal Thubert (pthubert) >> Cc: Vijay Devarapalli; Teco Boot; mext@ietf.org >> Subject: Re: [MEXT] Prefix Delegation documents >> >> Pascal Thubert (pthubert) wrote: >>> Hi Vijay >>> >>> My proposal to break the tie is this: >>> >>> - move draft-ietf-nemo-dhcpv6-pd-02.txt to informational track as it >>> documents a way to use DHCP-PD but does not need new exchanges. >> But as Romain pointed out, DHCP-PD as specified in this draft extends >> DHAAD by adding a new D flag. If we want to avoid the use of the new D >> flag then we should (probably) say in the DHCP-NEMO-PD draft how that >> DHCPv6 Solicit is sent through the MR-HA tunnel (or not through tunnel) >> and then relayed by the HA on the home link (or the HA is the DHCPv6 >> Server). >> >> I think even if we move it to the Informational track then we still > need >> to improve some stuff in it according to implementation. Or just let > it >> float... I don't know. >> >>> Last I checked, some components were still missing but Ralph knows >>> better. >>> >>> - focus on draft-ietf-nemo-prefix-delegation-02.txt for standard >>> track. The draft is agnostic to the delegation mechanism in the >>> backend and does not have dependencies. >> But it extends MIP6, right? (adds flags in messages). >> >>> It proposes an integrated mechanism that fits the general MIP6 / NEMO >>> approach and formats. >>> >>> What do you think? >> I think we should not extend MIP6 to do prefix allocation. BEcause: >> >> -I think addressing autoconfiguration mechanisms DHCP and others are >> already there for us to reuse and enhance eventually, no need to > extend >> MIP6. >> -what happens when MIPv6 allocates a prefix and PMIPv6 allocates one >> as well, but in a different way? (currently PMIPv6 doesn't seem to > use >> NEMO-MIP6-PD flags neither does NEMO-MIP6-PD use PMIPv6 way of > putting >> 0 to mean request prefix). Are the MIP6 and PMIP6 means to allocate >> prefixes equivalent? >> -what happens when we want the prefix delegated to the MR to be >> accompanied by a delegation of responsibility of the DNS reverse >> resolution as well? Can we reuse DHCP-DNS interactions (e.g. DNS >> update RFC2136)? Or should we design a new MIP6-DNS interaction? >> >> That's simply opinion. I'm not sure about other criteria that came to >> give the suggestion you made. >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --0-1502981316-1195791403=:45780 Content-Type: text/html; charset=us-ascii
Hi Vijay,
  I agree with you.
Regarding the status of the draft, it is possible to have the document to be standards track even if it does not define any new messages/parameters. An example is draft-ietf-16ng-ipv6-over-ipv6cs-11
Regards,

Behcet

----- Original Message ----
From: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
To: Pascal Thubert (pthubert) <pthubert@cisco.com>
Cc: mext@ietf.org
Sent: Thursday, November 22, 2007 3:56:09 PM
Subject: Re: [MEXT] Prefix Delegation documents

I don't believe it is necessary to extend DHAAD for NEMO prefix
delegation. The mobile router could assume that the home agent it
is bootstrapping does support a mechanism for assigning prefixes
for the mobile network. I don't think we have any home agents
deployed today that support mobile routers to worry about. :) So
it would be safe to assume that a home agent that supports mobile
routers also supports a mechanism to assign a mobile network
prefix.

Vijay

Pascal Thubert (pthubert) wrote:
> Hi Alex
>
> My take is that similar DHAAD flags should be present in both drafts for
> similar reasons; last I proposed it was rejected; I think that the
> argument was that locating the HA should be a DNS issue anyway. From the
> discussion we had recently with Romain, I still think that DHAAD and DNS
> can be complementary.
>
> You have some good points on DNS. But at this time we address prefixes
> not hosts. How the hosts on the MNP get names and publish those is an
> interesting issue but out of scope at this time.
>
> The fact that the HA uses NEMO extensions to pass the prefix to the MR
> does not preclude the use of a DHCP-PD server in the back end. It's just
> abstracting and simplifying that interaction. One problem with the
> DHCP-PD draft is lifetime of the lease: should it die with the MR-HA
> tunnel? The Nemo based draft is conscious of the volatility of the
> tunnel and the HA proxies the PD process for the MR based on the MR
> demands.
> 
>
> Pascal
>
>> -----Original Message-----
>> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]
>> Sent: Wednesday, November 21, 2007 6:33 PM
>> To: Pascal Thubert (pthubert)
>> Cc: Vijay Devarapalli; Teco Boot; mext@ietf.org
>> Subject: Re: [MEXT] Prefix Delegation documents
>>
>> Pascal Thubert (pthubert) wrote:
>>> Hi Vijay
>>>
>>> My proposal to break the tie is this:
>>>
>>> - move draft-ietf-nemo-dhcpv6-pd-02.txt to informational track as it
>>>  documents a way to use DHCP-PD but does not need new exchanges.
>> But as Romain pointed out, DHCP-PD as specified in this draft extends
>> DHAAD by adding a new D flag.  If we want to avoid the use of the new D
>> flag then we should (probably) say in the DHCP-NEMO-PD draft how that
>> DHCPv6 Solicit is sent through the MR-HA tunnel (or not through tunnel)
>> and then relayed by the HA on the home link (or the HA is the DHCPv6
>> Server).
>>
>> I think even if we move it to the Informational track then we still
> need
>> to improve some stuff in it according to implementation.  Or just let
> it
>> float... I don't know.
>>
>>> Last I checked, some components were still missing but Ralph knows
>>> better.
>>>
>>> - focus on draft-ietf-nemo-prefix-delegation-02.txt for standard
>>> track. The draft is agnostic to the delegation mechanism in the
>>> backend and does not have dependencies.
>> But it extends MIP6, right?  (adds flags in messages).
>>
>>> It proposes an integrated mechanism that fits the general MIP6 / NEMO
>>> approach and formats.
>>>
>>> What do you think?
>> I think we should not extend MIP6 to do prefix allocation.  BEcause:
>>
>> -I think addressing autoconfiguration mechanisms DHCP and others are
>>  already there for us to reuse and enhance eventually, no need to
> extend
>>  MIP6.
>> -what happens when MIPv6 allocates a prefix and PMIPv6 allocates one
>>  as well, but in a different way? (currently PMIPv6 doesn't seem to
> use
>>  NEMO-MIP6-PD flags neither does NEMO-MIP6-PD use PMIPv6 way of
> putting
>>  0 to mean request prefix).  Are the MIP6 and PMIP6 means to allocate
>>  prefixes equivalent?
>> -what happens when we want the prefix delegated to the MR to be
>>  accompanied by a delegation of responsibility of the DNS reverse
>>  resolution as well?  Can we reuse DHCP-DNS interactions (e.g. DNS
>>  update RFC2136)?  Or should we design a new MIP6-DNS interaction?
>>
>> That's simply opinion.  I'm not sure about other criteria that came to
>> give the suggestion you made.
>>
>> Alex
>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________


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

--0-1502981316-1195791403=:45780-- --===============1471929613== 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 --===============1471929613==-- From mext-bounces@ietf.org Fri Nov 23 03:11: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 1IvTcn-0001fA-Cu; Fri, 23 Nov 2007 03:10:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvTcm-0001f5-6r for mext@ietf.org; Fri, 23 Nov 2007 03:10:56 -0500 Received: from hpsmtp-eml17.kpnxchange.com ([213.75.38.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvTcj-0007JM-C9 for mext@ietf.org; Fri, 23 Nov 2007 03:10:56 -0500 Received: from hpsmtp-eml07.kpnxchange.com ([213.75.38.107]) by hpsmtp-eml17.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Nov 2007 09:10:52 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml07.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Nov 2007 09:10:51 +0100 From: "Teco Boot" To: "'Pascal Thubert \(pthubert\)'" References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> <47446BCB.5000000@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D35D@xmb-ams-337.emea.cisco.com> <4745B84B.6070002@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D392@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04D3D392@xmb-ams-337.emea.cisco.com> Subject: RE: [MEXT] Prefix Delegation documents Date: Fri, 23 Nov 2007 09:10:43 +0100 Message-ID: <000e01c82da8$583f7ad0$08be7070$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgtKtIwzMwzYHWXRl6jRqoh2lg6zQAAiISgAB6GHlA= Content-Language: nl X-OriginalArrivalTime: 23 Nov 2007 08:10:51.0829 (UTC) FILETIME=[5D02F650:01C82DA8] X-Spam-Score: -1.0 (-) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: 'Vijay Devarapalli' , 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 > -----Oorspronkelijk bericht----- > Van: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Verzonden: donderdag 22 november 2007 18:36 > Aan: Alexandru Petrescu > CC: Vijay Devarapalli; Teco Boot; mext@ietf.org > Onderwerp: RE: [MEXT] Prefix Delegation documents > > Hi Alex: > > There are actually examples where a short time lease is just what's > needed. It's good for privacy and a number of other reasons like > getting > a prefix that is topologically correct not-too-far. > > One of those examples is that of a MR visiting a MANET and getting a > local prefix for activity within that MANET that is topologically > correct in the area (AUTOCONF) and from which the MR can form a CoA > that > it can keep as it moves around. How can a HA know which prefixes are topologically correct in a MANET? MR is on visiting link, do you assume there is a relation between HA and this visiting link? > > Using NEMO to get the prefix enables the mobility of the delegated > prefix in and out the MANET - using or not the MANET protocol while in > the MANET space - till the MR finds that the prefix is useless and > forgets about it all. I think the MR can notify the HA that the delegated prefix is no longer being used and ownership is given back to HA. We can use the same mechanism for short time leases (e.g. transient) and long time leases (e.g. persistent). Teco. > > Pascal > > >-----Original Message----- > >From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > >Sent: Thursday, November 22, 2007 6:12 PM > >To: Pascal Thubert (pthubert) > >Cc: Vijay Devarapalli; Teco Boot; mext@ietf.org > >Subject: Re: [MEXT] Prefix Delegation documents > > > >Pascal Thubert (pthubert) wrote: > >> Hi Alex > >> > >> My take is that similar DHAAD flags should be present in both drafts > >> for similar reasons; last I proposed it was rejected; I think that > >> the argument was that locating the HA should be a DNS issue anyway. > >> From the discussion we had recently with Romain, I still think that > >> DHAAD and DNS can be complementary. > >> > >> You have some good points on DNS. But at this time we address > >> prefixes not hosts. How the hosts on the MNP get names and publish > >> those is an interesting issue but out of scope at this time. > > > >How does CN reverse resolve the LFN's IPv6 address (for e.g. when it > >receives mail from it, to avoid spam)? I think MR or other DNS server > >_in_ the moving network should ultimately be in charge for that > >resolution (and not HA or some entities in the home net). > > > >And that can only be achieved if the mechanism of prefix allocation is > >tightly coupled with DNS. > > > >Otherwise, if you make MIP6 to delegate the prefix to MR then you > should > >extend MIP6 to update the DNS server as well. I'm not saying this > >should be done, but that's the consequence, as I see it. > > > >I understand people may want to do everything with MIP6 (PMIP6, > DS-MIP6, > >Monami6, NEMO, etc) but at some point there are some existing things > >that could be reused too. > > > >> The fact that the HA uses NEMO extensions to pass the prefix to the > >> MR does not preclude the use of a DHCP-PD server in the back end. > >> It's just abstracting and simplifying that interaction. > > > >I'm wondering of the necessity of this (a NEMO-MIP6 extension to > support > >DHCPv6-PD). I doubt that's needed, DHCPv6-PD would work all by > itself, > >I think. > > > >> One problem with the DHCP-PD draft is lifetime of the lease: should > >> it die with the MR-HA tunnel? The Nemo based draft is conscious of > >> the volatility of the tunnel and the HA proxies the PD process for > >> the MR based on the MR demands. > > > >Right problem leasetime I think. > > > >I think if either MIP6-NEMO-PD extensions or DHCPv6-PD is used then in > >any case the DHCPv6 binding lease at the DHCPv6 Server should not > >expire, I don't want another moving network to be allocated the same > >prefix, because I may connect my moving network to that other moving > >network and addresses may collide. > > > >I think overall it is important to stick to one mechanism for > >dynamically allocating prefixes. > > > >Alex > > > > > >______________________________________________________________________ > >This email has been scanned by the MessageLabs Email Security System. > >For more information please visit http://www.messagelabs.com/email > >______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 23 05:17: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 1IvVZz-0000l3-IV; Fri, 23 Nov 2007 05:16:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvVZy-0000ky-CI for mext@ietf.org; Fri, 23 Nov 2007 05:16:10 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvVZv-0002wy-K8 for mext@ietf.org; Fri, 23 Nov 2007 05:16:10 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-153.messagelabs.com!1195812965!5680442!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 23510 invoked from network); 23 Nov 2007 10:16:05 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-10.tower-153.messagelabs.com with SMTP; 23 Nov 2007 10:16:05 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lANAFwHl007738; Fri, 23 Nov 2007 03:16:02 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id lANAFvb3006411; Fri, 23 Nov 2007 04:15:57 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id lANAFsHM006394; Fri, 23 Nov 2007 04:15:55 -0600 (CST) Message-ID: <4746A859.3080007@gmail.com> Date: Fri, 23 Nov 2007 11:15:53 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: [MEXT] Prefix Delegation documents References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> <47446BCB.5000000@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D35D@xmb-ams-337.emea.cisco.com> <4745B84B.6070002@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D392@xmb-ams-337.emea.cisco.com> <000e01c82da8$583f7ad0$08be7070$@nl> In-Reply-To: <000e01c82da8$583f7ad0$08be7070$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071122-0, 22/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: 'Vijay Devarapalli' , 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 Teco Boot wrote: > >> -----Oorspronkelijk bericht----- >> Van: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] >> Verzonden: donderdag 22 november 2007 18:36 >> Aan: Alexandru Petrescu >> CC: Vijay Devarapalli; Teco Boot; mext@ietf.org >> Onderwerp: RE: [MEXT] Prefix Delegation documents >> >> Hi Alex: >> >> There are actually examples where a short time lease is just what's >> needed. It's good for privacy and a number of other reasons like >> getting >> a prefix that is topologically correct not-too-far. >> >> One of those examples is that of a MR visiting a MANET and getting a >> local prefix for activity within that MANET that is topologically >> correct in the area (AUTOCONF) and from which the MR can form a CoA >> that >> it can keep as it moves around. > > How can a HA know which prefixes are topologically correct in a MANET? A HA in the MANET network would know the prefixes topologically correct in MANET because it would be administratively configured with these prefix(es). Or it could itself run DHCPv6-PD as a Requesting Router. > MR is on visiting link, do you assume there is a relation between HA and > this visiting link? I may mean a HA _within_ the MANET network, which would delegate a prefix to a visiting Mobile Router such that Mobile Router re-configures all its "NEMO" network. It becomes complicated to explain on both sides I believe :-) >> Using NEMO to get the prefix enables the mobility of the delegated >> prefix in and out the MANET - using or not the MANET protocol while in >> the MANET space - till the MR finds that the prefix is useless and >> forgets about it all. > > I think the MR can notify the HA that the delegated prefix is no longer > being used and ownership is given back to HA. > We can use the same mechanism for short time leases (e.g. transient) and > long time leases (e.g. persistent). I think yes, I think DHCP has a means for a Client to negotiate with the Server about how long it's going to use that address. MIP6 would need to develop that. Alex > > Teco. > >> Pascal >> >>> -----Original Message----- >>> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >>> Sent: Thursday, November 22, 2007 6:12 PM >>> To: Pascal Thubert (pthubert) >>> Cc: Vijay Devarapalli; Teco Boot; mext@ietf.org >>> Subject: Re: [MEXT] Prefix Delegation documents >>> >>> Pascal Thubert (pthubert) wrote: >>>> Hi Alex >>>> >>>> My take is that similar DHAAD flags should be present in both drafts >>>> for similar reasons; last I proposed it was rejected; I think that >>>> the argument was that locating the HA should be a DNS issue anyway. >>>> From the discussion we had recently with Romain, I still think that >>>> DHAAD and DNS can be complementary. >>>> >>>> You have some good points on DNS. But at this time we address >>>> prefixes not hosts. How the hosts on the MNP get names and publish >>>> those is an interesting issue but out of scope at this time. >>> How does CN reverse resolve the LFN's IPv6 address (for e.g. when it >>> receives mail from it, to avoid spam)? I think MR or other DNS server >>> _in_ the moving network should ultimately be in charge for that >>> resolution (and not HA or some entities in the home net). >>> >>> And that can only be achieved if the mechanism of prefix allocation is >>> tightly coupled with DNS. >>> >>> Otherwise, if you make MIP6 to delegate the prefix to MR then you >> should >>> extend MIP6 to update the DNS server as well. I'm not saying this >>> should be done, but that's the consequence, as I see it. >>> >>> I understand people may want to do everything with MIP6 (PMIP6, >> DS-MIP6, >>> Monami6, NEMO, etc) but at some point there are some existing things >>> that could be reused too. >>> >>>> The fact that the HA uses NEMO extensions to pass the prefix to the >>>> MR does not preclude the use of a DHCP-PD server in the back end. >>>> It's just abstracting and simplifying that interaction. >>> I'm wondering of the necessity of this (a NEMO-MIP6 extension to >> support >>> DHCPv6-PD). I doubt that's needed, DHCPv6-PD would work all by >> itself, >>> I think. >>> >>>> One problem with the DHCP-PD draft is lifetime of the lease: should >>>> it die with the MR-HA tunnel? The Nemo based draft is conscious of >>>> the volatility of the tunnel and the HA proxies the PD process for >>>> the MR based on the MR demands. >>> Right problem leasetime I think. >>> >>> I think if either MIP6-NEMO-PD extensions or DHCPv6-PD is used then in >>> any case the DHCPv6 binding lease at the DHCPv6 Server should not >>> expire, I don't want another moving network to be allocated the same >>> prefix, because I may connect my moving network to that other moving >>> network and addresses may collide. >>> >>> I think overall it is important to stick to one mechanism for >>> dynamically allocating prefixes. >>> >>> Alex >>> >>> >>> ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security System. >>> For more information please visit http://www.messagelabs.com/email >>> ______________________________________________________________________ > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 23 09:11:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvZEc-0008QS-Je; Fri, 23 Nov 2007 09:10:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvZEb-0008PV-27 for mext@ietf.org; Fri, 23 Nov 2007 09:10:21 -0500 Received: from smtp01.uc3m.es ([163.117.176.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvZEY-0001EO-L0 for mext@ietf.org; Fri, 23 Nov 2007 09:10:21 -0500 Received: from [163.117.139.227] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.227])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp01.uc3m.es (Postfix) with ESMTP id 25B8824B0B3for ; Fri, 23 Nov 2007 15:10:07 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: mext@ietf.org From: marcelo bagnulo braun Date: Fri, 23 Nov 2007 15:10:05 +0100 X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-4.6993 TC:1F TRN:28 TV:5.0.1023(15564.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -4.0 (----) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps 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, We have been discussing with our AD the way forward w.r.t. WG drafts inherited from the previous WGs (MIP6, NEMO and MONAMI6). We have grouped drafts into five categories and decided about the actions to be taken for drafts of each category: --------------------------------------------------------------------- Cat. I: former WG drafts submitted to IESG already Action: Address possible IESG Comments/Discusses as they surface. I-Ds: draft-ietf-mip6-bootstrapping-integrated-dhc-05 draft-ietf-mip6-cn-ipsec-06 draft-ietf-mip6-ha-switch-05 draft-ietf-mip6-hiopt-08 draft-ietf-mip6-whyauthdataoption-04 draft-ietf-mip6-experimental-messages-03 draft-ietf-mip6-vsm-03 ---------------------------------------------------------------------- Cat. II: former WG drafts corresponding to MEXT charter work items Action: - MEXT to adopt drafts as WG drafts - authors to submit new versions if/when needed as draft- ietf-mext-... I-Ds (MEXT work item): draft-ietf-nemo-mib-03 work item (B.3) draft-ietf-nemo-prefix-delegation-02 (B.3) draft-ietf-monami6-mipv6-analysis-04 (A.3) draft-ietf-monami6-multihoming-motivation-scenario-02 (A.3) draft-ietf-monami6-multiplecoa-04 (A.3) draft-ietf-mip6-hareliability-03 (A.2) draft-ietf-mip6-nemo-v4traversal-05 (A.1) draft-ietf-mip6-radius-02 (A.6) ---------------------------------------------------------------------- Cat. III: individual drafts corresponding to MEXT charter work items that were accepted as former WG drafts but never submitted as such. Action: - MEXT to adopt drafts as WG drafts as long as the authors follow the conditions requested by the respective WG at the moment of acceptancy - authors to submit new versions if/when needed as draft- ietf-mext-... I-Ds (MEXT work item): draft-eddy-nemo-aero-reqs-01 (A.5) draft-soliman-monami6-flow-binding-04 (A.3) ---------------------------------------------------------------------- Cat. IV: individual drafts corresponding to MEXT charter work items that were *conditionally* accepted as former WG drafts. Action: - authors to update drafts so that they fullfills conditions. I-Ds (MEXT work item): draft-baldessari-c2ccc-nemo-req-01 (A.5) ---------------------------------------------------------------------- Cat. V: former WG drafts without corresponding MEXT charter work item Action: - MEXT to include this drafts as part of the rechartering discussion. I-Ds: draft-ietf-mip6-rfc4285bis-01 draft-ietf-mip6-generic-notification-message-00 ------------------------------------------------------------------------ Comments? Cheers, -- Julien and Marcelo, MEXT chairs _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 23 09:24: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 1IvZRB-0001eO-S4; Fri, 23 Nov 2007 09:23:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvZRA-0001e8-4w for mext@ietf.org; Fri, 23 Nov 2007 09:23:20 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvZR6-0001dB-QV for mext@ietf.org; Fri, 23 Nov 2007 09:23:20 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1195827795!4962029!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 11128 invoked from network); 23 Nov 2007 14:23:15 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-12.tower-153.messagelabs.com with SMTP; 23 Nov 2007 14:23:15 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id lANENFJs020977; Fri, 23 Nov 2007 07:23:15 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lANENEQY007324; Fri, 23 Nov 2007 08:23:14 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lANENCZD007306; Fri, 23 Nov 2007 08:23:13 -0600 (CST) Message-ID: <4746E24F.1030008@gmail.com> Date: Fri, 23 Nov 2007 15:23:11 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> In-Reply-To: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071122-0, 22/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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 marcelo bagnulo braun wrote: > Folks, > > We have been discussing with our AD the way forward w.r.t. WG drafts > inherited from the previous WGs (MIP6, NEMO and MONAMI6). > > We have grouped drafts into five categories and decided about the > actions to be taken for drafts of each category: > > --------------------------------------------------------------------- > > Cat. I: former WG drafts submitted to IESG already > > Action: Address possible IESG Comments/Discusses as they surface. > > I-Ds: draft-ietf-mip6-bootstrapping-integrated-dhc-05 > draft-ietf-mip6-cn-ipsec-06 > draft-ietf-mip6-ha-switch-05 > draft-ietf-mip6-hiopt-08 > draft-ietf-mip6-whyauthdataoption-04 > draft-ietf-mip6-experimental-messages-03 > draft-ietf-mip6-vsm-03 > > ---------------------------------------------------------------------- > > Cat. II: former WG drafts corresponding to MEXT charter work items > > Action: - MEXT to adopt drafts as WG drafts > - authors to submit new versions if/when needed as > draft-ietf-mext-... > > I-Ds (MEXT work item): draft-ietf-nemo-mib-03 work item (B.3) > draft-ietf-nemo-prefix-delegation-02 (B.3) In addition, I'd like to request inclusion of draft-ietf-nemo-dhcpv6-pd which although expired I find it relevant (http://tools.ietf.org/id/draft-ietf-nemo-dhcpv6-pd-02.txt) . On and off it's been forgotten expired and re-activated. I'd suggest a deadline in the MEXT timeline as well. We're currently discussing publicly on the MEXT list about how to progress the two NEMO documents of prefix allocation. What do you think? Thanks, Alex > draft-ietf-monami6-mipv6-analysis-04 (A.3) > draft-ietf-monami6-multihoming-motivation-scenario-02 (A.3) > draft-ietf-monami6-multiplecoa-04 (A.3) > draft-ietf-mip6-hareliability-03 (A.2) > draft-ietf-mip6-nemo-v4traversal-05 (A.1) > draft-ietf-mip6-radius-02 (A.6) > > ---------------------------------------------------------------------- > > Cat. III: individual drafts corresponding to MEXT charter work items > that were accepted as former WG drafts but never submitted as such. > > Action: - MEXT to adopt drafts as WG drafts as long as the authors > follow the > conditions requested by the respective WG at the moment of > acceptancy > - authors to submit new versions if/when needed as > draft-ietf-mext-... > > I-Ds (MEXT work item): draft-eddy-nemo-aero-reqs-01 (A.5) > draft-soliman-monami6-flow-binding-04 (A.3) > > ---------------------------------------------------------------------- > > Cat. IV: individual drafts corresponding to MEXT charter work items > that were *conditionally* accepted as former WG drafts. > > Action: - authors to update drafts so that they fullfills conditions. > > I-Ds (MEXT work item): draft-baldessari-c2ccc-nemo-req-01 (A.5) > > ---------------------------------------------------------------------- > > Cat. V: former WG drafts without corresponding MEXT charter work item > > Action: - MEXT to include this drafts as part of the rechartering > discussion. > > I-Ds: draft-ietf-mip6-rfc4285bis-01 > draft-ietf-mip6-generic-notification-message-00 > > ------------------------------------------------------------------------ > > Comments? > > Cheers, > > -- > Julien and Marcelo, MEXT chairs > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From LinwoodstashChen@seagate.com Fri Nov 23 20:31:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivjs1-0006ZZ-JR; Fri, 23 Nov 2007 20:31:45 -0500 Received: from c-76-21-17-216.hsd1.ca.comcast.net ([76.21.17.216] helo=nhutcpu.hsd1.ca.comcast.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ivjs1-0000UI-5n; Fri, 23 Nov 2007 20:31:45 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host56673654.seagate.com (8.13.1/8.13.1) with SMTP id ZEGe93NL64.508561.MG9.n44.2882596758003 for ; Fri, 23 Nov 2007 17:31:03 +0800 Message-ID: <27d9901c82e39$bdb8fd50$6400a8c0@nhutcpu> From: "Brock Camacho" To: Subject: Your health Date: Fri, 23 Nov 2007 17:31:03 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_27D95_01C82E39.BDB8FD50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_27D95_01C82E39.BDB8FD50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_27D95_01C82E39.BDB8FD50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_27D95_01C82E39.BDB8FD50-- From Keantsv@BRASILIASEG.COM.BR Sat Nov 24 02:06:23 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivp5r-0003DX-Qj for nemo-archive@lists.ietf.org; Sat, 24 Nov 2007 02:06:23 -0500 Received: from host25-166-static.23-87-b.business.telecomitalia.it ([87.23.166.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ivp5r-000134-7d for nemo-archive@lists.ietf.org; Sat, 24 Nov 2007 02:06:23 -0500 Received: by 10.33.174.122 with SMTP id zgtiTHFnNJFoi; Sat, 24 Nov 2007 08:06:27 +0100 (GMT) Received: by 192.168.218.7 with SMTP id LowHSDnCJOsNrT.7572068186943; Sat, 24 Nov 2007 08:06:25 +0100 (GMT) Message-ID: <000201c82e68$85084f90$19a61757@angelo> From: "ggggggg Kean" To: Subject: phew Date: Sat, 24 Nov 2007 08:06:22 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C82E70.E6CCB790" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.0 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a ------=_NextPart_000_0006_01C82E70.E6CCB790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable wrap your wrist in a piece of luxury, stunning watches for a limited = time only http://hpahora.com/ ------=_NextPart_000_0006_01C82E70.E6CCB790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
wrap your wrist in a piece of = luxury,=20 stunning watches for a limited time only http://hpahora.com/
<= /HTML> ------=_NextPart_000_0006_01C82E70.E6CCB790-- From KaitlinrabbiCall@osnews.com Sat Nov 24 07:05:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtlQ-00068H-Oq; Sat, 24 Nov 2007 07:05:36 -0500 Received: from [72.93.235.57] (helo=ogrady.home) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvtlO-0002JF-GB; Sat, 24 Nov 2007 07:05:34 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host42865606.osnews.com (8.13.1/8.13.1) with SMTP id ZyZsWZ9618.426923.fAS.AIn.8181467117239 for ; Sat, 24 Nov 2007 07:04:58 +0500 Message-ID: <30994b01c82e92$4eac5980$0201a8c0@ogrady> From: "Francesca Corcoran" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_309947_01C82E92.4EAC5980-- From mext-bounces@ietf.org Sat Nov 24 11:11:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvxaD-0007h9-LP; Sat, 24 Nov 2007 11:10:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvxaC-0007gx-A0 for mext@ietf.org; Sat, 24 Nov 2007 11:10:16 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ivxa9-00022e-CO for mext@ietf.org; Sat, 24 Nov 2007 11:10:14 -0500 Received: from [163.117.203.113] (unknown [163.117.203.113])by smtp02.uc3m.es (Postfix) with ESMTP id CFD50263477;Sat, 24 Nov 2007 17:00:24 +0100 (CET) In-Reply-To: <4745B84B.6070002@gmail.com> References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@g mail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC 6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-stra sbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337 .emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@aza irenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> <47446BCB.5000000@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D35D@xmb-ams-337.emea.cisco.com> <4745B84B.6070002@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MEXT] Prefix Delegation documents Date: Sat, 24 Nov 2007 17:00:23 +0100 To: Alexandru Petrescu X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-27.2099 TC:1F TRN:78 TV:5.0.1023(15566.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.1 (++) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: Vijay Devarapalli , 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 Alex, El 22/11/2007, a las 18:11, Alexandru Petrescu escribi=F3: > Pascal Thubert (pthubert) wrote: >> Hi Alex >> My take is that similar DHAAD flags should be present in both =20 >> drafts for similar reasons; last I proposed it was rejected; I =20 >> think that the argument was that locating the HA should be a DNS =20 >> issue anyway. =46rom the discussion we had recently with Romain, I =20= >> still think that DHAAD and DNS can be complementary. >> You have some good points on DNS. But at this time we address =20 >> prefixes not hosts. How the hosts on the MNP get names and publish =20= >> those is an interesting issue but out of scope at this time. > > How does CN reverse resolve the LFN's IPv6 address (for e.g. when it > receives mail from it, to avoid spam)? I think MR or other DNS server > _in_ the moving network should ultimately be in charge for that > resolution (and not HA or some entities in the home net). > why do you say that? i mean, consider the case of the personal mobile router, do you think =20= that my PDA should be my DNS server in charge of the reverse DNS for =20 my mobil phone? I mean, i may agree that in some cases, this can be a reasonable =20 approach, but in general i would assume that the DNS servr is located =20= in th home network (or even in the ISP of the home network) > And that can only be achieved if the mechanism of prefix allocation is > tightly coupled with DNS. > right, but it also needs to be a tight mechanims between the address =20 autoconfiguration mechanism and the DNS update, since at the end of =20 the day, you don't need to update the prefix in the DNS but the =20 actual addresses that have been configured, right? > Otherwise, if you make MIP6 to delegate the prefix to MR then you =20 > should > extend MIP6 to update the DNS server as well. I'm not saying this > should be done, but that's the consequence, as I see it. > I don't see why this is the case. You can have MIP to delegate the =20 prefix, and then the MR announces the prefix in RA and then the MNN =20 autoconfigures the prefix and then it should then updat the DNS, as =20 any other node that has auto-configured an address > I understand people may want to do everything with MIP6 (PMIP6, DS-=20 > MIP6, > Monami6, NEMO, etc) but at some point there are some existing things > that could be reused too. > with that, i fully agree >> The fact that the HA uses NEMO extensions to pass the prefix to =20 >> the MR does not preclude the use of a DHCP-PD server in the back =20 >> end. It's just abstracting and simplifying that interaction. > > I'm wondering of the necessity of this (a NEMO-MIP6 extension to =20 > support > DHCPv6-PD). I doubt that's needed, DHCPv6-PD would work all by =20 > itself, > I think. > >> One problem with the DHCP-PD draft is lifetime of the lease: =20 >> should it die with the MR-HA tunnel? The Nemo based draft is =20 >> conscious of the volatility of the tunnel and the HA proxies the =20 >> PD process for the MR based on the MR demands. > > Right problem leasetime I think. > > I think if either MIP6-NEMO-PD extensions or DHCPv6-PD is used then in > any case the DHCPv6 binding lease at the DHCPv6 Server should not > expire, I don't want another moving network to be allocated the same > prefix, because I may connect my moving network to that other moving > network and addresses may collide. > > I think overall it is important to stick to one mechanism for > dynamically allocating prefixes. > again, i fully agree with you Regards, marcelo > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email =20 > ______________________________________________________________________ > > _______________________________________________ > 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 Sat Nov 24 11:56:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvyII-00082o-85; Sat, 24 Nov 2007 11:55:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvyIE-0007qX-K9 for mext@ietf.org; Sat, 24 Nov 2007 11:55:47 -0500 Received: from smtp03.uc3m.es ([163.117.176.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvyIE-0003fH-4m for mext@ietf.org; Sat, 24 Nov 2007 11:55:46 -0500 Received: from [163.117.203.113] (unknown [163.117.203.113])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp03.uc3m.es (Postfix) with ESMTP id 8AED224E7D4for ; Sat, 24 Nov 2007 17:55:44 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <1854AD9E-C316-4321-BE85-426DA3D17022@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: mext@ietf.org From: marcelo bagnulo braun Date: Sat, 24 Nov 2007 17:55:43 +0100 X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-4.8057 TC:1F TRN:17 TV:5.0.1023(15566.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 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: de4f315c9369b71d7dd5909b42224370 Subject: [MEXT] MEXT Rechartering 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 folks, Even though the WG just been created, we already have some new items that people seem to be interested in including in the MEXT charter, so we would like to open that discussion right away. Moreover, we are planning to devote part of the next meeting in Vancouver to discuss possible additional items to be included in the MEXT charter in the rechartering process. So in order to do this process, we would like that if you have items that you think should be included in the charter, please send a proposal to the MEXT ml so it can be discussed and also if you want to include it as part of the MEXT meeting rechartering discussion, ask for a slot. Thanks, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Nov 24 12:09:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvyV3-00066a-CB; Sat, 24 Nov 2007 12:09:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvyV1-0005xe-Vd for mext@ietf.org; Sat, 24 Nov 2007 12:09:00 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvyV1-00048a-En for mext@ietf.org; Sat, 24 Nov 2007 12:08:59 -0500 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: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps Date: Sat, 24 Nov 2007 09:08:57 -0800 Message-ID: In-Reply-To: <4746E24F.1030008@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps Thread-Index: Acgt3JNcLbnt3xenTxGQXM4+8mqShwA3/00w References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <4746E24F.1030008@gmail.com> From: "Vijay Devarapalli" To: "Alexandru Petrescu" , "marcelo bagnulo braun" X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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 > > I-Ds (MEXT work item): draft-ietf-nemo-mib-03 work item (B.3) > > draft-ietf-nemo-prefix-delegation-02 (B.3) >=20 > In addition, I'd like to request inclusion of=20 > draft-ietf-nemo-dhcpv6-pd which although expired I find it relevant > (http://tools.ietf.org/id/draft-ietf-nemo-dhcpv6-pd-02.txt) .=20 > On and off it's been forgotten expired and re-activated. =20 > I'd suggest a deadline in the MEXT timeline as well. Right. This is a NEMO WG document currently expired. A WG last call on this due about 2 years ago, but got delayed because there are two solution documents for prefix delegation. Vijay >=20 > We're currently discussing publicly on the MEXT list about=20 > how to progress the two NEMO documents of prefix allocation. >=20 > What do you think? >=20 > Thanks, >=20 > Alex >=20 > > draft-ietf-monami6-mipv6-analysis-04 (A.3) > > =20 > draft-ietf-monami6-multihoming-motivation-scenario-02 (A.3) > > draft-ietf-monami6-multiplecoa-04 (A.3) > > draft-ietf-mip6-hareliability-03 (A.2) > > draft-ietf-mip6-nemo-v4traversal-05 (A.1) > > draft-ietf-mip6-radius-02 (A.6) > >=20 > >=20 > ---------------------------------------------------------------------- > >=20 > > Cat. III: individual drafts corresponding to MEXT charter work items > > that were accepted as former WG drafts but never=20 > submitted as such. > >=20 > > Action: - MEXT to adopt drafts as WG drafts as long as the authors=20 > > follow the > > conditions requested by the respective WG at the=20 > moment of=20 > > acceptancy > > - authors to submit new versions if/when needed as=20 > > draft-ietf-mext-... > >=20 > > I-Ds (MEXT work item): draft-eddy-nemo-aero-reqs-01 (A.5) > > draft-soliman-monami6-flow-binding-04 (A.3) > >=20 > >=20 > ---------------------------------------------------------------------- > >=20 > > Cat. IV: individual drafts corresponding to MEXT charter work items > > that were *conditionally* accepted as former WG drafts. > >=20 > > Action: - authors to update drafts so that they fullfills=20 > conditions. > >=20 > > I-Ds (MEXT work item): draft-baldessari-c2ccc-nemo-req-01 (A.5) > >=20 > >=20 > ---------------------------------------------------------------------- > >=20 > > Cat. V: former WG drafts without corresponding MEXT charter=20 > work item > >=20 > > Action: - MEXT to include this drafts as part of the rechartering > > discussion. > >=20 > > I-Ds: draft-ietf-mip6-rfc4285bis-01 > > draft-ietf-mip6-generic-notification-message-00 > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > Comments? > >=20 > > Cheers, > >=20 > > -- > > Julien and Marcelo, MEXT chairs > >=20 > >=20 > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > >=20 >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Nov 24 12:12: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 1IvyY7-0000wW-41; Sat, 24 Nov 2007 12:12:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvyY5-0000w3-Hr for mext@ietf.org; Sat, 24 Nov 2007 12:12:09 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvyY4-0004El-LN for mext@ietf.org; Sat, 24 Nov 2007 12:12:09 -0500 X-IronPort-AV: E=Sophos;i="4.21,461,1188770400"; d="scan'208";a="158684945" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 24 Nov 2007 18:12:08 +0100 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 lAOHC7n0002720; Sat, 24 Nov 2007 18:12:07 +0100 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 lAOHC3ZZ005415; Sat, 24 Nov 2007 17:12:07 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); Sat, 24 Nov 2007 18:12:03 +0100 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: [MEXT] Prefix Delegation documents Date: Sat, 24 Nov 2007 18:11:57 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04D3D852@xmb-ams-337.emea.cisco.com> In-Reply-To: <4745FBEF.6080603@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Prefix Delegation documents Thread-Index: AcgtUxMZWvfQyu4XSNybC6//ZOT9XQBac7Qg References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> <47447F8F.3050103@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D39A@xmb-ams-337.emea.cisco.com> <4745FBEF.6080603@azairenet.com> From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" X-OriginalArrivalTime: 24 Nov 2007 17:12:03.0388 (UTC) FILETIME=[21FB67C0:01C82EBD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4768; t=1195924327; x=1196788327; 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[MEXT]=20=20Prefix=20Delegation=20documents |Sender:=20; bh=Y/COirSJjnYxNahCtqN/KBt6cNh+VXH1JNZhMH5TCRE=; b=CaKaeIuD5Ff2Jqt3GjhLwglCsFaS4NhMpIaHMa04VurtBhEyWlF2i4MJUo+4+285j26gjNcp wQbtuo7sVYXnI3NHnN0u22ZZiOpAPQtPdczAHRhoPPyAH5SLY2HOwnAl; 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: d2b46e3b2dfbff2088e0b72a54104985 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 Vijay: Surely not allocating a prefix every time a BU is sent :) but for the duration of a session, yes, we have use cases for that.=20 Pascal >-----Original Message----- >From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] >Sent: Thursday, November 22, 2007 11:00 PM >To: Pascal Thubert (pthubert) >Cc: Teco Boot; mext@ietf.org >Subject: Re: [MEXT] Prefix Delegation documents > >Pascal Thubert (pthubert) wrote: >> Hi Vijay >> >> The reason for the new MNPC option is that the original option did not >> convey additional stuff that's required here. In particular, the corID >> avoids delegating multiple prefixes if a BAck is lost. > >?? Why would the HA allocate a new prefix every time the BU is >sent? When the mobile router requests for one or prefixes, the >home agent responds with one or more prefixes. From there on, >subsequent binding updates sent to refresh an existing binding >will not contain any more requests for prefixes. > >If the Binding Ack is lost, the MN retransmits the BU. At that >time, the HA assumes the mobile router lost state for some >reason and is requesting for its prefixes again. Then the HA >would send the same set of prefixes that were allocated earlier >to the mobile router. No new prefixes. > >I must be missing something. > >Vijay > >> >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Length | Prefix Length |P|I|D|Reserved1| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | CorID | Reserved2 | Prefix type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Valid Lifetime | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> + + >> | | >> + Mobile Network Prefix + >> | | >> + + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> But it's just one more value for the Type anyway and we still have >> plenty. >> >> What do you think? >> >> Pascal >> >>> -----Original Message----- >>> From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] >>> Sent: Wednesday, November 21, 2007 7:57 PM >>> To: Pascal Thubert (pthubert) >>> Cc: Teco Boot; mext@ietf.org >>> Subject: Re: [MEXT] Prefix Delegation documents >>> >>> Pascal Thubert (pthubert) wrote: >>>> Hi Vijay >>>> >>>> My proposal to break the tie is this: >>>> >>>> - move draft-ietf-nemo-dhcpv6-pd-02.txt to informational track as it >>>> documents a way to use DHCP-PD but does not need new exchanges. Last >> I >>>> checked, some components were still missing but Ralph knows better. >>>> >>>> - focus on draft-ietf-nemo-prefix-delegation-02.txt for standard >> track. >>>> The draft is agnostic to the delegation mechanism in the backend and >>>> does not have dependencies. It proposes an integrated mechanism that >>>> fits the general MIP6 / NEMO approach and formats. >>>> >>>> What do you think? >>> I am fine with this approach. >>> >>> For draft-ietf-nemo-prefix-delegation-02.txt, I would like to >>> simplify the mechanism a bit, by removing the Mobile Network >>> Prefix Confirm option. Just use the Mobile Network Prefix >>> option for the home agent to send the prefix to the mobile >>> router. I actually don't understand the need for the Mobile >>> Network Prefix Confirm option. >>> >>> Vijay >>> >>>> Pascal >>>> >>>>> -----Original Message----- >>>>> From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] >>>>> Sent: Tuesday, November 20, 2007 7:45 PM >>>>> To: Teco Boot >>>>> Cc: Pascal Thubert (pthubert); mext@ietf.org >>>>> Subject: Re: [MEXT] Re: [nemo] Prefix Delegation documents >>>>> >>>>> Teco Boot wrote: >>>>>> Hi Pascal, >>>>>> Question on WG documents for prefix delegation. There are two of >>>> them: >>>>>> 1: draft-ietf-nemo-prefix-delegation-02.txt (August 21, 2007) >>>>>> 2: draft-ietf-nemo-dhcpv6-pd-02.txt (September 28, 2006) >>>>>> Are we still working on both solutions? >>>>> We have a sort of stalemate on this. I believe Jari (AD) would >> prefer >>>>> one solution in this space. I think the earlier decision by the NEMO >>>>> WG was to standardize both solutions. Not sure what the consensus is >>>>> right now. >>>>> >>>>> IMO, we should standardize one ASAP. Without a prefix delegation >>>>> mechanism the only possible solution now is to pre-configure the >>>>> mobile network prefix on the mobile router. This is not sufficient. >>>>> >>>>> Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Nov 24 12:12: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 1IvyY7-0000xC-L6; Sat, 24 Nov 2007 12:12:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvyY6-0000wA-E3 for mext@ietf.org; Sat, 24 Nov 2007 12:12:10 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvyY5-0004Er-SH for mext@ietf.org; Sat, 24 Nov 2007 12:12:10 -0500 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: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps Date: Sat, 24 Nov 2007 09:12:08 -0800 Message-ID: In-Reply-To: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps Thread-Index: Acgt2vpYPayQwUtKTpKa7erUaRmQZwA4eBUw References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> From: "Vijay Devarapalli" To: "marcelo bagnulo braun" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: 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 High level question. Is there a need to rename all the drafts as draft-ietf-mext...? This always causes confusion when you are trying to go back through the revisions and try to find something that was added/deleted. Can't the drafts retain the names=20 (mip6/nemo/monami6) and progress as MEXT WG documents? Of course, new WG documents should be named draft-ietf-mext... Vijay > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Friday, November 23, 2007 6:10 AM > To: mext@ietf.org > Subject: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps=20 >=20 > Folks, >=20 > We have been discussing with our AD the way forward w.r.t. WG=20 > drafts inherited from the previous WGs (MIP6, NEMO and MONAMI6). >=20 > We have grouped drafts into five categories and decided about=20 > the actions to be taken for drafts of each category: >=20 > --------------------------------------------------------------------- >=20 > Cat. I: former WG drafts submitted to IESG already >=20 > Action: Address possible IESG Comments/Discusses as they surface. >=20 > I-Ds: draft-ietf-mip6-bootstrapping-integrated-dhc-05 > draft-ietf-mip6-cn-ipsec-06 > draft-ietf-mip6-ha-switch-05 > draft-ietf-mip6-hiopt-08 > draft-ietf-mip6-whyauthdataoption-04 > draft-ietf-mip6-experimental-messages-03 > draft-ietf-mip6-vsm-03 >=20 > ---------------------------------------------------------------------- >=20 > Cat. II: former WG drafts corresponding to MEXT charter work items >=20 > Action: - MEXT to adopt drafts as WG drafts > - authors to submit new versions if/when needed as=20 > draft- ietf-mext-... >=20 > I-Ds (MEXT work item): draft-ietf-nemo-mib-03 work item (B.3) > draft-ietf-nemo-prefix-delegation-02 (B.3) > draft-ietf-monami6-mipv6-analysis-04 (A.3) > =09 > draft-ietf-monami6-multihoming-motivation-scenario-02 (A.3) > draft-ietf-monami6-multiplecoa-04 (A.3) > draft-ietf-mip6-hareliability-03 (A.2) > draft-ietf-mip6-nemo-v4traversal-05 (A.1) > draft-ietf-mip6-radius-02 (A.6) >=20 > ---------------------------------------------------------------------- >=20 > Cat. III: individual drafts corresponding to MEXT charter work items > that were accepted as former WG drafts but never=20 > submitted as such. >=20 > Action: - MEXT to adopt drafts as WG drafts as long as the=20 > authors follow the > conditions requested by the respective WG at the=20 > moment of acceptancy > - authors to submit new versions if/when needed as=20 > draft- ietf-mext-... >=20 > I-Ds (MEXT work item): draft-eddy-nemo-aero-reqs-01 (A.5) > draft-soliman-monami6-flow-binding-04 (A.3) >=20 > ---------------------------------------------------------------------- >=20 > Cat. IV: individual drafts corresponding to MEXT charter work items > that were *conditionally* accepted as former WG drafts. >=20 > Action: - authors to update drafts so that they fullfills conditions. >=20 > I-Ds (MEXT work item): draft-baldessari-c2ccc-nemo-req-01 (A.5) >=20 > ---------------------------------------------------------------------- >=20 > Cat. V: former WG drafts without corresponding MEXT charter work item >=20 > Action: - MEXT to include this drafts as part of the rechartering > discussion. >=20 > I-Ds: draft-ietf-mip6-rfc4285bis-01 > draft-ietf-mip6-generic-notification-message-00 >=20 > -------------------------------------------------------------- > ---------- >=20 > Comments? >=20 > Cheers, >=20 > -- > Julien and Marcelo, MEXT chairs >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Nov 24 12:24: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 1Ivyk1-0000dv-3f; Sat, 24 Nov 2007 12:24:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivyk0-0000dN-6g for mext@ietf.org; Sat, 24 Nov 2007 12:24:28 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivyjw-0001KX-EA for mext@ietf.org; Sat, 24 Nov 2007 12:24:28 -0500 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: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps Date: Sat, 24 Nov 2007 09:24:23 -0800 Message-ID: In-Reply-To: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps Thread-Index: Acgt2vpYPayQwUtKTpKa7erUaRmQZwA4nLOQ References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> From: "Vijay Devarapalli" To: "marcelo bagnulo braun" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: Julien Laganier 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 Marcelo, The following drafts are missing.=20 draft-ietf-mip6-aaa-ha-goals - I think this document completed=20 MIP6 WG last call. It is currently expired. draft-devarapalli-mip6-authprotocol-bootstrap - There is an ongoing consensus(?) call to make this a WG document. Not sure if it is actually a consensus call. Something about gauging interest. :) 4283bis - There is no draft on this yet, but a need to update 4283 was identified on the NETLMM mailing list and then=20 discussed later on the mext mailing list. The update is to mainly include other subtypes for MN identifier. For example, the MAC address would be the new subtype. Currently the=20 document only defines NAI. Finally, what happened to=20 draft-mitsuya-monami6-flow-distribution-policy-04.txt. I=20 thought this was also going to be adopted as a MONAMI6 WG=20 document. I might have missed some emails. Vijay > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Friday, November 23, 2007 6:10 AM > To: mext@ietf.org > Subject: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps=20 >=20 > Folks, >=20 > We have been discussing with our AD the way forward w.r.t. WG=20 > drafts inherited from the previous WGs (MIP6, NEMO and MONAMI6). >=20 > We have grouped drafts into five categories and decided about=20 > the actions to be taken for drafts of each category: >=20 > --------------------------------------------------------------------- >=20 > Cat. I: former WG drafts submitted to IESG already >=20 > Action: Address possible IESG Comments/Discusses as they surface. >=20 > I-Ds: draft-ietf-mip6-bootstrapping-integrated-dhc-05 > draft-ietf-mip6-cn-ipsec-06 > draft-ietf-mip6-ha-switch-05 > draft-ietf-mip6-hiopt-08 > draft-ietf-mip6-whyauthdataoption-04 > draft-ietf-mip6-experimental-messages-03 > draft-ietf-mip6-vsm-03 >=20 > ---------------------------------------------------------------------- >=20 > Cat. II: former WG drafts corresponding to MEXT charter work items >=20 > Action: - MEXT to adopt drafts as WG drafts > - authors to submit new versions if/when needed as=20 > draft- ietf-mext-... >=20 > I-Ds (MEXT work item): draft-ietf-nemo-mib-03 work item (B.3) > draft-ietf-nemo-prefix-delegation-02 (B.3) > draft-ietf-monami6-mipv6-analysis-04 (A.3) > =09 > draft-ietf-monami6-multihoming-motivation-scenario-02 (A.3) > draft-ietf-monami6-multiplecoa-04 (A.3) > draft-ietf-mip6-hareliability-03 (A.2) > draft-ietf-mip6-nemo-v4traversal-05 (A.1) > draft-ietf-mip6-radius-02 (A.6) >=20 > ---------------------------------------------------------------------- >=20 > Cat. III: individual drafts corresponding to MEXT charter work items > that were accepted as former WG drafts but never=20 > submitted as such. >=20 > Action: - MEXT to adopt drafts as WG drafts as long as the=20 > authors follow the > conditions requested by the respective WG at the=20 > moment of acceptancy > - authors to submit new versions if/when needed as=20 > draft- ietf-mext-... >=20 > I-Ds (MEXT work item): draft-eddy-nemo-aero-reqs-01 (A.5) > draft-soliman-monami6-flow-binding-04 (A.3) >=20 > ---------------------------------------------------------------------- >=20 > Cat. IV: individual drafts corresponding to MEXT charter work items > that were *conditionally* accepted as former WG drafts. >=20 > Action: - authors to update drafts so that they fullfills conditions. >=20 > I-Ds (MEXT work item): draft-baldessari-c2ccc-nemo-req-01 (A.5) >=20 > ---------------------------------------------------------------------- >=20 > Cat. V: former WG drafts without corresponding MEXT charter work item >=20 > Action: - MEXT to include this drafts as part of the rechartering > discussion. >=20 > I-Ds: draft-ietf-mip6-rfc4285bis-01 > draft-ietf-mip6-generic-notification-message-00 >=20 > -------------------------------------------------------------- > ---------- >=20 > Comments? >=20 > Cheers, >=20 > -- > Julien and Marcelo, MEXT chairs >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Nov 24 12:56: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 1IvzFG-0000ph-Fv; Sat, 24 Nov 2007 12:56:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvzDf-0007fU-Qp for mext@ietf.org; Sat, 24 Nov 2007 12:55:07 -0500 Received: from rv-out-0910.google.com ([209.85.198.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivz98-0002Ot-GR for mext@ietf.org; Sat, 24 Nov 2007 12:50:35 -0500 Received: by rv-out-0910.google.com with SMTP id l15so134940rvb for ; Sat, 24 Nov 2007 09:50:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=gQ6ZDDQFXTURv/lbmrfy7AW8jinJl0jAIuF0Aqlb6bU=; b=I8z0r/PEGkg0vB5fi7abNxoAeQ5rnDI9YWSoJAl/nYeb3ikLUSil0jd/Xvs8mXl7rjxfwd5ROJp2/9ESQM4T65eCY7iDI9uubadgTjloQGSF+d5/7e79nfahEzczT1sXb8uREv94K/9zN21btT+iJrA2Oc1sbPdmUjsX7i6cTYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=ITwAlHu912DdMSZ6B20vO/QvutCnszyB0qK+MTsy2m4sYJpl897ZevFCkx4VikYndrZ7VB8//KsovhUiIAm8W8VeltHhdDhshtZD8rlSoqWSRrtPbLLH5BpWQJj0GM/lZTTk5FnodHrZxtURD/IOuG9A9iqJ7MiOHezg6Xu6woY= Received: by 10.141.15.19 with SMTP id s19mr281675rvi.1195926621466; Sat, 24 Nov 2007 09:50:21 -0800 (PST) Received: from ?10.0.1.200? ( [219.110.64.224]) by mx.google.com with ESMTPS id f21sm3532406rvb.2007.11.24.09.50.18 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Nov 2007 09:50:19 -0800 (PST) From: RYUJI WAKIKAWA To: George Tsirtsis In-Reply-To: Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-04.txt References: Message-Id: <01D2C6E5-F109-4DF1-96E4-D5784C259A46@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Sun, 25 Nov 2007 02:50:17 +0900 X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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 George thanks for your comments. Please find my reply inline. On 2007/11/21, at 23:08, George Tsirtsis wrote: > Hi all, > > I reviewed draft-ietf-monami6-multiplecoa-04.txt so here are some > comments: > > 1) BID name: Not sure if I am missing some history behind this but I > am not sure why BID does not simply mean "Binding ID" as opposed to > "Binding Unique ID". Could we drop the work "unique" from BID and > the corresponding sub-option? I don't have much intention to the name. We can change it if nobody complain :-) > 2) BID uniqueness and scope: One needs to read almost the entire > document before he can figure out that the BID's scope of uniqueness > is exactly. The fact that a BID is unique to an HoA/CoA pair and the > fact that the MN is responsible for managing the BID number space > should be made clear up front, maybe as part of the BID definition > in Section 2. OK > > 3) Bulk Registrations and CNs: It is not clear why bulk > registrations are not allowed for CNs. Is it so much more complex to > handle bulk registrations once that is defined for the HA and once > the CNs handle MCoAs one at a time? This is just for simplicity. We had consensus for this. > 4) Deregistration/Returning_Home:These issues are described in > Section 3 (protocol overview) and then more explicitly in other > sections. I found the text in Section 3 with respect to these issues > confusing to say the least. Maybe that text can be removed or re- > written after the issues are resolved sufficiently (see separate > thread of discussion on that). We certainly have to update this part. For this revision, I didn't update the returning home parts and waiting for consensus in WG. > 5) In the definition of Care of address (C) flag (section 4.2.1) a > "must", an "or", and a "MUST" are used in the same breath...please > clean it up :-) > OK, I will fix this. thanks > 6) BID independence vs bulk registrations: It is hard to tell from > the current text to what extend BIDs are managed independently and > how that is affected by bulk registrations. In particular the > discussion regarding sequence numbers in Section 5.4 is confusing. > According to 3775, Section 11.1, the MN is keeping just one entry in > its Binding Update List for each destination. If I understand > correctly, with MCoAs, the MN needs to keep multiple entries in that > list, one per BID. It should be made clear whether a separate > sequence number space is required per BID or not. Separate space per > BID seems incompatible with the idea of sending bulk registrations, > so I would think that the same space should be used. For bulk registration, the same space should be used, but not MUST. This is because MN may switch to use bulk registration when the number of active CoAs gets larger. In such case, MN should update the sequence number values of all the bindings to the reasonable number (which is the highest number of all the bindings within the sequence window). thanks, ryuji > > 7) Interactions with DSMIPv6. I think at some point a new section > needs to be added to talk about interactions with DSMIPv6. Beyond > the obvious issue of whether MCoAs can include IPv4 CoAs etc the > MCoA draft includes some interactions with IKEv2 and imposes some > requirements to the use of alternate-CoA which may or may not > conflict with DSMIPv6 (have not checked that myself yet). > > Regards > George > _______________________________________________ > 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 Sat Nov 24 13:02: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 1IvzKm-00021q-So; Sat, 24 Nov 2007 13:02:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvzKk-00021e-N4 for mext@ietf.org; Sat, 24 Nov 2007 13:02:26 -0500 Received: from rv-out-0910.google.com ([209.85.198.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvzKh-0002uP-01 for mext@ietf.org; Sat, 24 Nov 2007 13:02:26 -0500 Received: by rv-out-0910.google.com with SMTP id l15so136433rvb for ; Sat, 24 Nov 2007 10:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=Z2vKEN//wFhrGI9TthFDbivtWZSFDnovTUwGwILHF6Q=; b=Fl23Hkf/PuKz39zMiwVDCn/kZ0/ejO5u8Dfr8kaWyianKLexeoWt7hyIdirK255NxKYDo1dVeuw77Pzb5Zl/FUUmB6Wi0OcBfvgYaeFKSDIbsvxGi+lqFH2fS3C7z9Eiuixn/GxhaqTUVaSIh8ndzYF+8Dh1nG5IMNabucpJFgU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=cbpKpxnq06gJivwJw5Nz4XBqBHM07IEFozZJajrUh1KUkNHSvBYs7uPQyfMxreEssENieNvnpRvTYEiC+9LD0M4Lei/IGWCrF0tYqDybRt6cgExz4z1A2wCqD5DTACiiYdCJI6mXJ0D4598gM8jUC+b9Kwzao2kixFFlGmQjKb8= Received: by 10.140.164.1 with SMTP id m1mr295537rve.1195927340651; Sat, 24 Nov 2007 10:02:20 -0800 (PST) Received: from ?10.0.1.200? ( [219.110.64.224]) by mx.google.com with ESMTPS id l27sm5104622rvb.2007.11.24.10.02.18 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Nov 2007 10:02:19 -0800 (PST) From: RYUJI WAKIKAWA To: Vijay Devarapalli In-Reply-To: Subject: Re: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Sun, 25 Nov 2007 03:02:16 +0900 X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: Julien Laganier , 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 Vijay On 2007/11/25, at 2:24, Vijay Devarapalli wrote: > Marcelo, > > The following drafts are missing. > > draft-ietf-mip6-aaa-ha-goals - I think this document completed > MIP6 WG last call. It is currently expired. > > draft-devarapalli-mip6-authprotocol-bootstrap - There is an > ongoing consensus(?) call to make this a WG document. Not sure > if it is actually a consensus call. Something about gauging > interest. :) > > 4283bis - There is no draft on this yet, but a need to update > 4283 was identified on the NETLMM mailing list and then > discussed later on the mext mailing list. The update is to > mainly include other subtypes for MN identifier. For example, > the MAC address would be the new subtype. Currently the > document only defines NAI. > > Finally, what happened to > draft-mitsuya-monami6-flow-distribution-policy-04.txt. I > thought this was also going to be adopted as a MONAMI6 WG > document. I might have missed some emails. There are two documents about flow distribution languages documents. - draft-mitsuya-monami6-flow-distribution-policy-04.txt - draft-larsson-monami6-filter-rules-02.txt We agreed to merge the two documents and published draft-larsson-mext-flow-distribution-rules-00.txt regards, ryuji > > > Vijay > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Friday, November 23, 2007 6:10 AM >> To: mext@ietf.org >> Subject: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps >> >> Folks, >> >> We have been discussing with our AD the way forward w.r.t. WG >> drafts inherited from the previous WGs (MIP6, NEMO and MONAMI6). >> >> We have grouped drafts into five categories and decided about >> the actions to be taken for drafts of each category: >> >> --------------------------------------------------------------------- >> >> Cat. I: former WG drafts submitted to IESG already >> >> Action: Address possible IESG Comments/Discusses as they surface. >> >> I-Ds: draft-ietf-mip6-bootstrapping-integrated-dhc-05 >> draft-ietf-mip6-cn-ipsec-06 >> draft-ietf-mip6-ha-switch-05 >> draft-ietf-mip6-hiopt-08 >> draft-ietf-mip6-whyauthdataoption-04 >> draft-ietf-mip6-experimental-messages-03 >> draft-ietf-mip6-vsm-03 >> >> ---------------------------------------------------------------------- >> >> Cat. II: former WG drafts corresponding to MEXT charter work items >> >> Action: - MEXT to adopt drafts as WG drafts >> - authors to submit new versions if/when needed as >> draft- ietf-mext-... >> >> I-Ds (MEXT work item): draft-ietf-nemo-mib-03 work item (B.3) >> draft-ietf-nemo-prefix-delegation-02 (B.3) >> draft-ietf-monami6-mipv6-analysis-04 (A.3) >> >> draft-ietf-monami6-multihoming-motivation-scenario-02 (A.3) >> draft-ietf-monami6-multiplecoa-04 (A.3) >> draft-ietf-mip6-hareliability-03 (A.2) >> draft-ietf-mip6-nemo-v4traversal-05 (A.1) >> draft-ietf-mip6-radius-02 (A.6) >> >> ---------------------------------------------------------------------- >> >> Cat. III: individual drafts corresponding to MEXT charter work items >> that were accepted as former WG drafts but never >> submitted as such. >> >> Action: - MEXT to adopt drafts as WG drafts as long as the >> authors follow the >> conditions requested by the respective WG at the >> moment of acceptancy >> - authors to submit new versions if/when needed as >> draft- ietf-mext-... >> >> I-Ds (MEXT work item): draft-eddy-nemo-aero-reqs-01 (A.5) >> draft-soliman-monami6-flow-binding-04 (A.3) >> >> ---------------------------------------------------------------------- >> >> Cat. IV: individual drafts corresponding to MEXT charter work items >> that were *conditionally* accepted as former WG drafts. >> >> Action: - authors to update drafts so that they fullfills conditions. >> >> I-Ds (MEXT work item): draft-baldessari-c2ccc-nemo-req-01 (A.5) >> >> ---------------------------------------------------------------------- >> >> Cat. V: former WG drafts without corresponding MEXT charter work item >> >> Action: - MEXT to include this drafts as part of the rechartering >> discussion. >> >> I-Ds: draft-ietf-mip6-rfc4285bis-01 >> draft-ietf-mip6-generic-notification-message-00 >> >> -------------------------------------------------------------- >> ---------- >> >> Comments? >> >> Cheers, >> >> -- >> Julien and Marcelo, MEXT chairs >> >> >> _______________________________________________ >> 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 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Nov 24 13:11: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 1IvzTT-0001P6-Pi; Sat, 24 Nov 2007 13:11:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvzDf-0007ep-76 for mext@ietf.org; Sat, 24 Nov 2007 12:55:07 -0500 Received: from mtoichi14.ns.itscom.net ([219.110.2.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvzBn-0002Uz-JP for mext@ietf.org; Sat, 24 Nov 2007 12:53:15 -0500 Received: from mtiichi14.ns.itscom.net ([unknown]) by mtoichi14.ns.itscom.net with ESMTP id lAOHr2mX016782 Sun, 25 Nov 2007 02:53:02 +0900 (JST) Received: from [10.0.1.200] (h219-110-64-224.catv02.itscom.jp [219.110.64.224]) by mtiichi14.ns.itscom.net with ESMTP id lAOHr2NY021207 ; Sun, 25 Nov 2007 02:53:02 +0900 (JST) From: Ryuji Wakikawa To: Vijay Devarapalli In-Reply-To: <4744BE6F.5040408@azairenet.com> Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-04.txt References: <4744BE6F.5040408@azairenet.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Sun, 25 Nov 2007 02:53:02 +0900 X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Sat, 24 Nov 2007 13:11:26 -0500 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 George and Vijay, Question is whether we should support DSMIP in this document. It seems reasonable to support DSMIP. We can easily extend BID sub-option to cary both IPv4/IPv6 addresses. regards, ryuji On 2007/11/22, at 8:25, Vijay Devarapalli wrote: > George Tsirtsis wrote: > >> 7) Interactions with DSMIPv6. I think at some point a new section >> needs to be added to talk about interactions with DSMIPv6. Beyond >> the obvious issue of whether MCoAs can include IPv4 CoAs etc the >> MCoA draft includes some interactions with IKEv2 > > I think the IKEv2 interactions are inline with what we decided for > DS-MIPv6 last week. Transport mode IPsec SA for the binding update, > and tunnel mode SAs updated either by MIPv6 (K flag) or running > IKEv2 again. > > and imposes some requirements to the use of >> alternate-CoA which may or may not conflict with DSMIPv6 (have not >> checked that myself yet). > > In DS-MIPv6, the IPv4 CoA option is a new mobility option, not > related to the alt CoA option in RFC 3775. > draft-ietf-monami6-multiplecoa says the alt CoA option should not > be included whenever the CoA is carried in the BID mobility option. > > The BID option as defined in the draft currently seems to allow > only for an IPv6 address. I think, we need to extend the BID option > to carry an IPv4 or an IPv6 address. > > Vijay > > _______________________________________________ > 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 Sat Nov 24 13:21: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 1Ivzd2-0003Tf-9w; Sat, 24 Nov 2007 13:21:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivzd0-0003Ta-SZ for mext@ietf.org; Sat, 24 Nov 2007 13:21:18 -0500 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivzcy-0003zy-Gc for mext@ietf.org; Sat, 24 Nov 2007 13:21:18 -0500 Received: by py-out-1112.google.com with SMTP id d32so541745pye for ; Sat, 24 Nov 2007 10:21:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=HGWPXxIjC6iTrU36z1XRIWEVwt+Pp8zbeA2aDT0spyI=; b=ikXp3oEgccHkirGcagfv0xOqHjtmcxSWL0W85/s14bV7wW8Ly6QSEG3eWuwrRhqF3wrm2CeEmJ9OvZOv/a9FtbNNmw6kN98TJ5GOM9jFZ51P9pTLkjH+FGYxU/2ZDDwnC6XT9H7XcbUCDgPbUwuyIgax3GdoRrUFK+ri2M4qYbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=JuUajaaU/gZh/2tD2XDVFG5zz/gcY1m/Ro94fjIOCX3thaHXcQUTFBzSzMMCisZL+gj8U6Yv0xKa6zple8yrE2CBYRhgWuG0ekxHMbk76ywCtOeKi54IX9a80A2GcBn+lP3FaGO86QZbb5cmyrvZ5QTWGNrSvJ2MzT1Ypew2nUA= Received: by 10.35.115.18 with SMTP id s18mr857558pym.1195928476004; Sat, 24 Nov 2007 10:21:16 -0800 (PST) Received: from ?10.0.1.200? ( [219.110.64.224]) by mx.google.com with ESMTPS id f45sm8202205pyh.2007.11.24.10.21.12 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Nov 2007 10:21:14 -0800 (PST) From: RYUJI WAKIKAWA To: Basavaraj Patil In-Reply-To: Subject: Re: [Mip6] Re: [MEXT] MEXT starts now References: Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Sun, 25 Nov 2007 03:21:10 +0900 X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: mip6@ietf.org, 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 Thanks Raj! I believe we can continue working with you:-) ryuji On 2007/11/21, at 3:23, Basavaraj Patil wrote: > > Much appreciated. It has been possible only because of an excellent > support > cast in the mobility area. It has been a pleasure working with all > of you. > > I wish the MEXT chairs good luck. > > Cheers, > -Raj > > On 11/20/07 12:17 PM, "ext Jari Arkko" wrote: > >> Indeed. Its a long time. Thanks, Raj. >> >> Jari >> >> Vijay Devarapalli kirjoitti: >>> Special thanks to Raj for chairing the MIP6 WG (and the earlier >>> Mobile IP WG) for 8 years! Mobile IP and MIP6 have always been >>> "exciting" WGs and Raj had always had his hands full. :) >>> >>> Vijay >>> >>> Jari Arkko wrote: >>>> Hi all, >>>> >>>> I'm happy to announce that MEXT is now finally created. Marcelo >>>> Braun and Julien Laganier are the new chairs. Please join me >>>> in welcoming them and thanking them for taking up this task! >>>> >>>> Their first task is to organize the agenda and meeting in >>>> Vancouver, so send mail to them for agenda slots and other >>>> requests. >>>> >>>> The IETF secretary is working on the WG web page updates and >>>> other practical details. The two slots for MIP6 in the current >>>> agenda will be renamed to MEXT slots. >>>> >>>> I would also like to thank the chairs of the three WGs that will >>>> now be merged into one: Thierry, Gopal, Basavaraj, TJ, and >>>> Nicolas -- big thanks for your hard work over the years! >>>> >>>> Jari Arkko >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mext >>> >>> >>> >> > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Nov 24 14:16: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 1Iw0Tb-0007dy-I8; Sat, 24 Nov 2007 14:15:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw0TZ-0007df-VK for mext@ietf.org; Sat, 24 Nov 2007 14:15:38 -0500 Received: from smtp03.uc3m.es ([163.117.176.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iw0TZ-0001F8-0T for mext@ietf.org; Sat, 24 Nov 2007 14:15:37 -0500 Received: from [192.168.1.129] (143.44.217.87.dynamic.jazztel.es [87.217.44.143])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp03.uc3m.es (Postfix) with ESMTP id DD06824EF06for ; Sat, 24 Nov 2007 20:15:35 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: mext@ietf.org From: marcelo bagnulo braun Date: Sat, 24 Nov 2007 20:15:35 +0100 X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-8.1019 TC:1F TRN:25 TV:5.0.1023(15566.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -4.0 (----) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [MEXT] Agenda so far 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 folks, We haven't yet finished the agenda, but we do have a prelimanry one, that will certainly change, but just to keep you up to date on the progress on the meeting planning. --------------------------------------------------------------------- Mobility EXTensions for IPv6 (MEXT) Agenda at IETF-70 ==================================== Chairs: Julien Laganier Marcelo Bagnulo Braun Sessions: TUESDAY, December 4, 2007 0900-1130 Morning Session I FRIDAY, December 7, 2007 0900-1130 Morning Session I Agenda: o MEXT Deliverables - Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) Hesham Soliman - 15 min draft-ietf-mip6-nemo-v4traversal-06.txt - Guidelines for firewall administrators regarding MIPv6 traffic Suresh Krishnan - 10 min draft-krishnan-mip6-firewall-admin-02 - Guidelines for firewall vendors regarding MIPv6 traffic Suresh Krishnan - 10 min draft-krishnan-mip6-firewall-vendor-02 - Multiple Care-of Addresses Registration Ryuji Wakikawa - 20 min draft-ietf-monami6-multiplecoa-04 - Consumer Electronics Requirements for Network Mobility Route Optimization Chan-Wah Ng - 10 min draft-ng-nemo-ce-req-01 - Analysis of commonalities in nemo RO requirements for aviation, car to car and consumer electronics cases 20 min o Rechartering Discussion - Binding Revocation for IPv6 Mobility Ahmad Muhanna - 10 min draft-muhanna-mip6-binding-revocation-02.txt - MIPv6 home link operation in various SDOs Vijay Devarapalli - 15 min no draft yet o Other Discussions (depending on the time left from previous discussions) - EAP-Based Keying for IP Mobility Protocols Gerardo Giarretta - 10 min draft-vidya-eap-usrk-ip-mobility-01 - Limitations exist in IP mobility support applications (NEMO + PMIP) John Zhao - 10 min draft-zhao-nemo-limitations-ps _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Nov 24 16:06: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 1Iw2Bv-0002Yn-51; Sat, 24 Nov 2007 16:05:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw2Bq-0002YI-I6 for mext@ietf.org; Sat, 24 Nov 2007 16:05:26 -0500 Received: from p130.piuha.net ([2001:14b8:400::130] helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iw2Bq-00023P-93 for mext@ietf.org; Sat, 24 Nov 2007 16:05:26 -0500 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 9EE921986B9; Sat, 24 Nov 2007 23:05:25 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 425DE198670; Sat, 24 Nov 2007 23:05:25 +0200 (EET) Message-ID: <47489214.7090406@piuha.net> Date: Sat, 24 Nov 2007 23:05:24 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Vijay, > High level question. Is there a need to rename all the drafts > as draft-ietf-mext...? This always causes confusion when you are > trying to go back through the revisions and try to find something > that was added/deleted. Can't the drafts retain the names > (mip6/nemo/monami6) and progress as MEXT WG documents? > I think this is no longer strictly speaking needed for drafts to show up in the right WG pages. However, having the name and WG match helps people to understand where drafts belong, recognize announcements, etc. As Marcelo wrote, there is no need for anyone to rush to submit a draft just because of the name change. However, when you have a need to change the draft for other reasons, I would actually like to see them use a new name as well. By the way, nothing passed to the AD or IESG should be renamed. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Nov 24 16:45: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 1Iw2oY-0006n0-QJ; Sat, 24 Nov 2007 16:45:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw2oW-0006mm-VZ for mext@ietf.org; Sat, 24 Nov 2007 16:45:24 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iw2oR-0003V1-Ud for mext@ietf.org; Sat, 24 Nov 2007 16:45:24 -0500 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id lAOLjIpS008518; Sat, 24 Nov 2007 15:45:18 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Nov 2007 15:45:18 -0600 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: [MEXT] MEXT Rechartering Date: Sat, 24 Nov 2007 16:45:16 -0500 Message-ID: <95D8C1105D54EB41864F8831E6C4EB75021C81B5@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] MEXT Rechartering Thread-Index: AcguuvPvgUuzHpPwTuGo0CqIs1bmvwAJ4W5v References: <1854AD9E-C316-4321-BE85-426DA3D17022@it.uc3m.es> From: "Wassim Haddad" To: "marcelo bagnulo braun" X-OriginalArrivalTime: 24 Nov 2007 21:45:18.0493 (UTC) FILETIME=[4E39E4D0:01C82EE3] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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, I would like to request a 5 min slot to present = draft-haddad-mip6-tunneling-optimization-01 and its addition to the charter discussion.=20 Regards, Wassim H. -----Original Message----- From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] Sent: Sat 11/24/2007 5:55 PM To: mext@ietf.org Subject: [MEXT] MEXT Rechartering =20 Hi folks, Even though the WG just been created, we already have some new items =20 that people seem to be interested in including in the MEXT charter, =20 so we would like to open that discussion right away. Moreover, we are =20 planning to devote part of the next meeting in Vancouver to discuss =20 possible additional items to be included in the MEXT charter in the =20 rechartering process. So in order to do this process, we would like that if you have items =20 that you think should be included in the charter, please send a =20 proposal to the MEXT ml so it can be discussed and also if you want =20 to include it as part of the MEXT meeting rechartering discussion, =20 ask for a slot. Thanks, marcelo _______________________________________________ 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 Sat Nov 24 16:47: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 1Iw2ql-0007j2-9H; Sat, 24 Nov 2007 16:47:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw2qi-0007ii-N6 for mext@ietf.org; Sat, 24 Nov 2007 16:47:42 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iw2qi-0006f2-B5 for mext@ietf.org; Sat, 24 Nov 2007 16:47:40 -0500 Received: from [192.168.1.129] (143.44.217.87.dynamic.jazztel.es [87.217.44.143])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp02.uc3m.es (Postfix) with ESMTP id 14AAB264ACD;Sat, 24 Nov 2007 22:47:39 +0100 (CET) In-Reply-To: References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <93960661-DB67-4A94-89FE-AA48EF1DC7D9@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Potential recharter items (was Re: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps Date: Sat, 24 Nov 2007 22:47:38 +0100 To: Vijay Devarapalli X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-1.5549 TC:1F TRN:18 TV:5.0.1023(15566.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.1 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Julien Laganier , 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 Vijay, El 24/11/2007, a las 18:24, Vijay Devarapalli escribi=F3: > draft-devarapalli-mip6-authprotocol-bootstrap - There is an > ongoing consensus(?) call to make this a WG document. Not sure > if it is actually a consensus call. Something about gauging > interest. :) > this should be included in the rechartering discussion, what other =20 people feel about including this item in the recharter? > 4283bis - There is no draft on this yet, but a need to update > 4283 was identified on the NETLMM mailing list and then > discussed later on the mext mailing list. The update is to > mainly include other subtypes for MN identifier. For example, > the MAC address would be the new subtype. Currently the > document only defines NAI. > same thing here, this should be included in the rechartering =20 discussion, what other people feel about including this item in the =20 recharter? Regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Nov 24 17:00: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 1Iw33L-00047G-3u; Sat, 24 Nov 2007 17:00:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw33J-00047B-Pq for mext@ietf.org; Sat, 24 Nov 2007 17:00:41 -0500 Received: from web84109.mail.mud.yahoo.com ([68.142.206.196]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iw33J-00070Y-7j for mext@ietf.org; Sat, 24 Nov 2007 17:00:41 -0500 Received: (qmail 81157 invoked by uid 60001); 24 Nov 2007 22:00:40 -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=uQTLaHJFtGcbVxISbDwi/GxHRUWIqP455NsXp5BlYbwRxG2JnY+PiHogX3ur5HGyDNnSMc9QLERN1nz+jdy20Lwt/24hMF6KqQKB61PZOUhotgheBH8/yV3j7CvgI1I1fdzi5ch2yg+3C92+UyhJK3ijhVnl1akIz99X8SQA+uw=; X-YMail-OSG: deSS2_gVM1ml4iR9REk_A5aHFvMIEnS1jwwFP1MtC7WPNU735pE977ouWDMo8jtX4dSkz1x9EBuDObR0OPB7NUOa.alr0AjOolTraVAV3gyMfzI- Received: from [71.123.247.57] by web84109.mail.mud.yahoo.com via HTTP; Sat, 24 Nov 2007 14:00:40 PST X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.152 Date: Sat, 24 Nov 2007 14:00:40 -0800 (PST) From: Behcet Sarikaya Subject: Re: [MEXT] MEXT Rechartering To: marcelo bagnulo braun MIME-Version: 1.0 Message-ID: <699953.80351.qm@web84109.mail.mud.yahoo.com> 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 Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1793360941==" Errors-To: mext-bounces@ietf.org --===============1793360941== Content-Type: multipart/alternative; boundary="0-1018685549-1195941640=:80351" --0-1018685549-1195941640=:80351 Content-Type: text/plain; charset=us-ascii Hi Marcelo, How about including part if not all of netlmm extensions into the mext charter. After all they are extensions to PMIPv6 which is itself an extension of MIPv6 which is what mext has been chartered for. Regards, Behcet ----- Original Message ---- From: marcelo bagnulo braun To: mext@ietf.org Sent: Saturday, November 24, 2007 10:55:43 AM Subject: [MEXT] MEXT Rechartering Hi folks, Even though the WG just been created, we already have some new items that people seem to be interested in including in the MEXT charter, so we would like to open that discussion right away. Moreover, we are planning to devote part of the next meeting in Vancouver to discuss possible additional items to be included in the MEXT charter in the rechartering process. So in order to do this process, we would like that if you have items that you think should be included in the charter, please send a proposal to the MEXT ml so it can be discussed and also if you want to include it as part of the MEXT meeting rechartering discussion, ask for a slot. Thanks, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --0-1018685549-1195941640=:80351 Content-Type: text/html; charset=us-ascii
Hi Marcelo,
  How about including part if not all of netlmm extensions into the mext charter. After all they are extensions to PMIPv6 which is itself an extension of MIPv6 which is what mext has been chartered for.
  Regards,

Behcet

----- Original Message ----
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
To: mext@ietf.org
Sent: Saturday, November 24, 2007 10:55:43 AM
Subject: [MEXT] MEXT Rechartering

Hi folks,

Even though the WG just been created, we already have some new items 
that people seem to be interested in including in the MEXT charter, 
so we would like to open that discussion right away. Moreover, we are 
planning to devote part of the next meeting in Vancouver to discuss 
possible additional items to be included in the MEXT charter in the 
rechartering process.

So in order to do this process, we would like that if you have items 
that you think should be included in the charter, please send a 
proposal to the MEXT ml so it can be discussed and also if you want 
to include it as part of the MEXT meeting rechartering discussion, 
ask for a slot.


Thanks, marcelo

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

--0-1018685549-1195941640=:80351-- --===============1793360941== 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 --===============1793360941==-- From mext-bounces@ietf.org Sat Nov 24 17: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 1Iw3A7-0002wb-5a; Sat, 24 Nov 2007 17:07:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw3A5-0002rX-Sq for mext@ietf.org; Sat, 24 Nov 2007 17:07:41 -0500 Received: from web84106.mail.mud.yahoo.com ([68.142.206.193]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iw3A3-0004AW-8h for mext@ietf.org; Sat, 24 Nov 2007 17:07:41 -0500 Received: (qmail 27416 invoked by uid 60001); 24 Nov 2007 22:07:38 -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=YEhcte5k7sfNelNHT7iKLiI5fX6uuShCdJ+s2pBWmuqvCXAiy6iN75jQ58N3BVe7xDQgPSAGD2bE7+yFgjT2PXwtnJS0ZVKHBDJUO+Zm/+bPU8+klod+6Kx/sXPewZ3PtmFQzGLmgeHuQ3yS3KHjfL7y4o19zvMcJ8ilMtXJ+38=; X-YMail-OSG: a9F.lOsVM1my3ltR3VcNedT60NhFWKuLPoBIfeUwyB8_tGv4IqGnroPJSzBytf_QDwHlbuad43fTGja04.BjnWql.KOijxEm1PTDQJsfUdXiDPc- Received: from [71.123.247.57] by web84106.mail.mud.yahoo.com via HTTP; Sat, 24 Nov 2007 14:07:38 PST X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.152 Date: Sat, 24 Nov 2007 14:07:38 -0800 (PST) From: Behcet Sarikaya Subject: Re: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps To: Jari Arkko MIME-Version: 1.0 Message-ID: <562721.18489.qm@web84106.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0957404110==" Errors-To: mext-bounces@ietf.org --===============0957404110== Content-Type: multipart/alternative; boundary="0-558445037-1195942058=:18489" --0-558445037-1195942058=:18489 Content-Type: text/plain; charset=us-ascii Hi Jari, See inline. Regards, Behcet ----- Original Message ---- From: Jari Arkko To: Vijay Devarapalli Cc: mext@ietf.org Sent: Saturday, November 24, 2007 3:05:24 PM Subject: Re: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps Vijay, > High level question. Is there a need to rename all the drafts > as draft-ietf-mext...? This always causes confusion when you are > trying to go back through the revisions and try to find something > that was added/deleted. Can't the drafts retain the names > (mip6/nemo/monami6) and progress as MEXT WG documents? > I think this is no longer strictly speaking needed for drafts to show up in the right WG pages. However, having the name and WG match helps people to understand where drafts belong, recognize announcements, etc. As Marcelo wrote, there is no need for anyone to rush to submit a draft just because of the name change. However, when you have a need to change the draft for other reasons, I would actually like to see them use a new name as well. [behcet] This would mean a re-versioning as well. The new online submission tool requires the previous version x to be exatcly named after version x-1. So it is not going to be possible to submit the new version of say, draft-nemo-...-02 to be draft-mext-...-03. By the way, nothing passed to the AD or IESG should be renamed. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --0-558445037-1195942058=:18489 Content-Type: text/html; charset=us-ascii
Hi Jari,
  See inline.

Regards,

Behcet
----- Original Message ----
From: Jari Arkko <jari.arkko@piuha.net>
To: Vijay Devarapalli <Vijay.Devarapalli@AzaireNet.com>
Cc: mext@ietf.org
Sent: Saturday, November 24, 2007 3:05:24 PM
Subject: Re: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps

Vijay,

> High level question. Is there a need to rename all the drafts
> as draft-ietf-mext...? This always causes confusion when you are
> trying to go back through the revisions and try to find something
> that was added/deleted. Can't the drafts retain the names
> (mip6/nemo/monami6) and progress as MEXT WG documents?
> 

I think this is no longer strictly speaking needed for drafts to
show up in the right WG pages. However, having the name
and WG match helps people to understand where drafts
belong, recognize announcements, etc. As Marcelo wrote,
there is no need for anyone to rush to submit a draft just
because of the name change. However, when you have a
need to change the draft for other reasons, I would
actually like to see them use a new name as well.

[behcet] This would mean a re-versioning as well. The new online submission tool requires the previous version x to be exatcly named after version x-1. So it is not going to be possible to submit the new version of say, draft-nemo-...-02 to be draft-mext-...-03.


By the way, nothing passed to the AD or IESG should be
renamed.

Jari


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

--0-558445037-1195942058=:18489-- --===============0957404110== 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 --===============0957404110==-- From mext-bounces@ietf.org Sat Nov 24 18:12:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw4AS-00060z-HH; Sat, 24 Nov 2007 18:12:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw4AR-0005sm-8q for mext@ietf.org; Sat, 24 Nov 2007 18:12:07 -0500 Received: from smtp03.uc3m.es ([163.117.176.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iw4AO-0005n0-1s for mext@ietf.org; Sat, 24 Nov 2007 18:12:07 -0500 Received: from [192.168.1.129] (143.44.217.87.dynamic.jazztel.es [87.217.44.143])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp03.uc3m.es (Postfix) with ESMTP id 12EA824F630;Sun, 25 Nov 2007 00:12:03 +0100 (CET) In-Reply-To: <699953.80351.qm@web84109.mail.mud.yahoo.com> References: <699953.80351.qm@web84109.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MEXT] MEXT Rechartering Date: Sun, 25 Nov 2007 00:12:02 +0100 To: Behcet Sarikaya X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-15.3202 TC:1F TRN:31 TV:5.0.1023(15566.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -1.9 (-) 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 Behcet, this is probably beyond the rechartering we have in mind right now... regards, marcelo El 24/11/2007, a las 23:00, Behcet Sarikaya escribi=F3: > Hi Marcelo, > How about including part if not all of netlmm extensions into the =20= > mext charter. After all they are extensions to PMIPv6 which is =20 > itself an extension of MIPv6 which is what mext has been chartered =20 > for. > Regards, > > Behcet > > ----- Original Message ---- > From: marcelo bagnulo braun > To: mext@ietf.org > Sent: Saturday, November 24, 2007 10:55:43 AM > Subject: [MEXT] MEXT Rechartering > > Hi folks, > > Even though the WG just been created, we already have some new items > that people seem to be interested in including in the MEXT charter, > so we would like to open that discussion right away. Moreover, we are > planning to devote part of the next meeting in Vancouver to discuss > possible additional items to be included in the MEXT charter in the > rechartering process. > > So in order to do this process, we would like that if you have items > that you think should be included in the charter, please send a > proposal to the MEXT ml so it can be discussed and also if you want > to include it as part of the MEXT meeting rechartering discussion, > ask for a slot. > > > Thanks, marcelo > > _______________________________________________ > 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 Sat Nov 24 22:12: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 1Iw7uz-0002cs-2N; Sat, 24 Nov 2007 22:12:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw7ux-0002cn-CR for mext@ietf.org; Sat, 24 Nov 2007 22:12:23 -0500 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iw7uu-0002Kf-4j for mext@ietf.org; Sat, 24 Nov 2007 22:12:23 -0500 Received: by rv-out-0910.google.com with SMTP id l15so202736rvb for ; Sat, 24 Nov 2007 19:12:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=nSRA81IrpGDEkXctSmQo4Hi2sIDoL3FSrlcQThyPZNo=; b=UZRNcxoC2sbGglqHOfZKmQmJqa29b+Z4rsaBq1SVYF1++ap0dKmNOPvt5u/O9vN12EY7Pzj/nFeDT/qvA/+xuLhPhtUvKuze0H/gtafoi4JHynv5HtKKVxXvOWXZ/SH+oDpCv83hGgcEgLbOpzsN930PY03qReSdnYZWISekeAc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=j/OpJS2Q8TyPSBtYa7mWQWJDSWI6WV02ouy849uVdQe3KYfyz1w2iD7y58PR835s1U+EzK2PeslHYCbbXPMoqo6ldDsyoB1II4/OeNJJg4yQ8twN7JrfN42KbIcUhKm0xYgeb3WDl0j46zJOeics3ux2hekYoaWwUtgX7+DYuS4= Received: by 10.140.180.11 with SMTP id c11mr456480rvf.1195960339188; Sat, 24 Nov 2007 19:12:19 -0800 (PST) Received: by 10.141.180.1 with HTTP; Sat, 24 Nov 2007 19:12:19 -0800 (PST) Message-ID: <1d38a3350711241912l2bda3ecaub165f794889194bd@mail.gmail.com> Date: Sun, 25 Nov 2007 11:12:19 +0800 From: "Hui Deng" To: "marcelo bagnulo braun" Subject: Re: [MEXT] MEXT Rechartering In-Reply-To: <1854AD9E-C316-4321-BE85-426DA3D17022@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1854AD9E-C316-4321-BE85-426DA3D17022@it.uc3m.es> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 possible, we would like to request a 5 min slot to present http://www.ietf.org/internet-drafts/draft-qi-mip6-ikev2-interfacing-01.txt and its addition to the charter discussion. thanks -Hui 2007/11/25, marcelo bagnulo braun : > Hi folks, > > Even though the WG just been created, we already have some new items > that people seem to be interested in including in the MEXT charter, > so we would like to open that discussion right away. Moreover, we are > planning to devote part of the next meeting in Vancouver to discuss > possible additional items to be included in the MEXT charter in the > rechartering process. > > So in order to do this process, we would like that if you have items > that you think should be included in the charter, please send a > proposal to the MEXT ml so it can be discussed and also if you want > to include it as part of the MEXT meeting rechartering discussion, > ask for a slot. > > > Thanks, marcelo > > _______________________________________________ > 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 Sat Nov 24 22:32: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 1Iw8Ei-0001B3-AK; Sat, 24 Nov 2007 22:32:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw8Eg-0001Ax-DT for mext@ietf.org; Sat, 24 Nov 2007 22:32:46 -0500 Received: from deimos.multihop.net ([74.0.36.190] helo=multihop.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iw8Ef-0006CO-P4 for mext@ietf.org; Sat, 24 Nov 2007 22:32:46 -0500 Received: by deimos.multihop.net (Postfix, from userid 1013) id C6FA2A0A97E; Sat, 24 Nov 2007 19:32:44 -0800 (PST) X-Spam-Score: -4.4 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on deimos.multihop.net X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Received: from [192.168.4.25] (ibmx31.tehama.multihop.net [192.168.4.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 6A927A0A77F; Sat, 24 Nov 2007 19:32:43 -0800 (PST) Message-ID: <4748ECDB.1080204@kniveton.com> Date: Sat, 24 Nov 2007 19:32:43 -0800 From: "T.J. Kniveton" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <47489214.7090406@piuha.net> In-Reply-To: <47489214.7090406@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Vijay Devarapalli , 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 Jari Arkko wrote: > Vijay, > > >> High level question. Is there a need to rename all the drafts >> as draft-ietf-mext...? This always causes confusion when you are >> trying to go back through the revisions and try to find something >> that was added/deleted. Can't the drafts retain the names >> (mip6/nemo/monami6) and progress as MEXT WG documents? >> >> > > I think this is no longer strictly speaking needed for drafts to > show up in the right WG pages. However, having the name > and WG match helps people to understand where drafts > belong, recognize announcements, etc. As Marcelo wrote, > there is no need for anyone to rush to submit a draft just > because of the name change. However, when you have a > need to change the draft for other reasons, I would > actually like to see them use a new name as well. > > By the way, nothing passed to the AD or IESG should be > renamed. > > Jari > As Behcet pointed out, renaming the draft will reset the draft counter to -00. We experienced this when renaming some of the "monet" drafts to "nemo" drafts. However, it's usually not a big deal. Drafts that are ready to go to IESG could probably keep their current names (since they will just end up as RFCs anyway), but drafts that will be around for a while should probably be renamed. TJ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 25 06:26: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 1IwFcJ-0002el-Bw; Sun, 25 Nov 2007 06:25:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwFcI-0002eg-1N for mext@ietf.org; Sun, 25 Nov 2007 06:25:38 -0500 Received: from smtp03.uc3m.es ([163.117.176.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwFcF-00086T-99 for mext@ietf.org; Sun, 25 Nov 2007 06:25:38 -0500 Received: from [192.168.1.129] (219.44.217.87.dynamic.jazztel.es [87.217.44.219])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp03.uc3m.es (Postfix) with ESMTP id 55B4D24FAE1for ; Sun, 25 Nov 2007 12:25:32 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: mext@ietf.org From: marcelo bagnulo braun Date: Sun, 25 Nov 2007 12:25:31 +0100 X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-2.5693 TC:04 TRN:13 TV:5.0.1023(15566.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [MEXT] Next steps on prefix delegation 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 all, With respect to the NEMO prefix delegation issue, it is my opinion that it would be preferred to have a single prefix delegation solution rather than two. Moreover, that we should have strong technical reasons to do more than one solution since this variety of mechanisms without strong reasons adds needless complexity. So, my first question to the working group is: do you think there are strong technical reasons to have more than one solution for prefix delegation? If no, then which would be the preferred approach for prefix delegation and why? Out goal is to try to wrap up this discussion in the next meting Thanks, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 25 06:40:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwFqc-0006JP-8g; Sun, 25 Nov 2007 06:40:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwFqa-0006JJ-UC for mext@ietf.org; Sun, 25 Nov 2007 06:40:24 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IwFqX-000070-Do for mext@ietf.org; Sun, 25 Nov 2007 06:40:24 -0500 Received: (qmail invoked by alias); 25 Nov 2007 11:40:20 -0000 Received: from p54985FA5.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.95.165] by mail.gmx.net (mp035) with SMTP; 25 Nov 2007 12:40:20 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19W3CNxU9xWZOk6brFqejAFurdmG9wzdwQUFvDAjQ TwUPnshz3OLwqR Message-ID: <47495F23.2040107@gmx.net> Date: Sun, 25 Nov 2007 12:40:19 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mext@ietf.org References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> In-Reply-To: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [MEXT] Prefix delegation & Diameter Interaction 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 all, in the DIME working group we have a document that provides the Diameter interworking for prefix delegation. Here is the document: http://tools.ietf.org/wg/dime/draft-sarikaya-dime-prefix-delegation-ps-00.txt It would help us in DIME if members of this group could give us some feedback. Ciao Hannes _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 25 07:47: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 1IwGth-0002In-Fz; Sun, 25 Nov 2007 07:47:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwGtf-0002Ia-Ey for mext@ietf.org; Sun, 25 Nov 2007 07:47:39 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IwGte-0005a6-K3 for mext@ietf.org; Sun, 25 Nov 2007 07:47:39 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-153.messagelabs.com!1195994857!7710431!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 13199 invoked from network); 25 Nov 2007 12:47:37 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-8.tower-153.messagelabs.com with SMTP; 25 Nov 2007 12:47:37 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id lAPClWHQ015113; Sun, 25 Nov 2007 05:47:32 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lAPClVAd000131; Sun, 25 Nov 2007 06:47:31 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.246]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id lAPClR5f000118; Sun, 25 Nov 2007 06:47:28 -0600 (CST) Message-ID: <47496EDE.1070208@gmail.com> Date: Sun, 25 Nov 2007 13:47:26 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [MEXT] Prefix Delegation documents References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> <47447F8F.3050103@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D39A@xmb-ams-337.emea.cisco.com> <4745FBEF.6080603@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D852@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04D3D852@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071124-0, 24/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: Vijay Devarapalli , 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 Pascal Thubert (pthubert) wrote: > Hi Vijay: > > Surely not allocating a prefix every time a BU is sent :) I agree with that: there should be no need for HA/entity to allocate a prefix at each change of CoA - otherwise it's a complete mess. Alex > but for the duration of a session, yes, we have use cases for that. > > Pascal > >> -----Original Message----- From: Vijay Devarapalli >> [mailto:vijay.devarapalli@AzaireNet.com] Sent: Thursday, November >> 22, 2007 11:00 PM To: Pascal Thubert (pthubert) Cc: Teco Boot; >> mext@ietf.org Subject: Re: [MEXT] Prefix Delegation documents >> >> Pascal Thubert (pthubert) wrote: >>> Hi Vijay >>> >>> The reason for the new MNPC option is that the original option >>> did > not >>> convey additional stuff that's required here. In particular, the > corID >>> avoids delegating multiple prefixes if a BAck is lost. >> ?? Why would the HA allocate a new prefix every time the BU is >> sent? When the mobile router requests for one or prefixes, the home >> agent responds with one or more prefixes. From there on, subsequent >> binding updates sent to refresh an existing binding will not >> contain any more requests for prefixes. >> >> If the Binding Ack is lost, the MN retransmits the BU. At that >> time, the HA assumes the mobile router lost state for some reason >> and is requesting for its prefixes again. Then the HA would send >> the same set of prefixes that were allocated earlier to the mobile >> router. No new prefixes. >> >> I must be missing something. >> >> Vijay >> >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 > 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type | Length | Prefix Length > |P|I|D|Reserved1| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | CorID | Reserved2 | Prefix type > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Valid Lifetime > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | > | >>> + > + >>> | > | >>> + Mobile Network Prefix > + >>> | > | >>> + > + >>> | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> But it's just one more value for the Type anyway and we still >>> have plenty. >>> >>> What do you think? >>> >>> Pascal >>> >>>> -----Original Message----- From: Vijay Devarapalli >>>> [mailto:vijay.devarapalli@AzaireNet.com] Sent: Wednesday, >>>> November 21, 2007 7:57 PM To: Pascal Thubert (pthubert) Cc: >>>> Teco Boot; mext@ietf.org Subject: Re: [MEXT] Prefix Delegation >>>> documents >>>> >>>> Pascal Thubert (pthubert) wrote: >>>>> Hi Vijay >>>>> >>>>> My proposal to break the tie is this: >>>>> >>>>> - move draft-ietf-nemo-dhcpv6-pd-02.txt to informational >>>>> track as > it >>>>> documents a way to use DHCP-PD but does not need new >>>>> exchanges. > Last >>> I >>>>> checked, some components were still missing but Ralph knows >>>>> better. >>>>> >>>>> - focus on draft-ietf-nemo-prefix-delegation-02.txt for >>>>> standard >>> track. >>>>> The draft is agnostic to the delegation mechanism in the >>>>> backend > and >>>>> does not have dependencies. It proposes an integrated >>>>> mechanism > that >>>>> fits the general MIP6 / NEMO approach and formats. >>>>> >>>>> What do you think? >>>> I am fine with this approach. >>>> >>>> For draft-ietf-nemo-prefix-delegation-02.txt, I would like to >>>> simplify the mechanism a bit, by removing the Mobile Network >>>> Prefix Confirm option. Just use the Mobile Network Prefix >>>> option for the home agent to send the prefix to the mobile >>>> router. I actually don't understand the need for the Mobile >>>> Network Prefix Confirm option. >>>> >>>> Vijay >>>> >>>>> Pascal >>>>> >>>>>> -----Original Message----- From: Vijay Devarapalli >>>>>> [mailto:vijay.devarapalli@AzaireNet.com] Sent: Tuesday, >>>>>> November 20, 2007 7:45 PM To: Teco Boot Cc: Pascal Thubert >>>>>> (pthubert); mext@ietf.org Subject: Re: [MEXT] Re: [nemo] >>>>>> Prefix Delegation documents >>>>>> >>>>>> Teco Boot wrote: >>>>>>> Hi Pascal, Question on WG documents for prefix >>>>>>> delegation. There are two of >>>>> them: >>>>>>> 1: draft-ietf-nemo-prefix-delegation-02.txt (August 21, >>>>>>> 2007) 2: draft-ietf-nemo-dhcpv6-pd-02.txt (September 28, >>>>>>> 2006) Are we still working on both solutions? >>>>>> We have a sort of stalemate on this. I believe Jari (AD) >>>>>> would >>> prefer >>>>>> one solution in this space. I think the earlier decision by >>>>>> the > NEMO >>>>>> WG was to standardize both solutions. Not sure what the >>>>>> consensus > is >>>>>> right now. >>>>>> >>>>>> IMO, we should standardize one ASAP. Without a prefix >>>>>> delegation mechanism the only possible solution now is to >>>>>> pre-configure the mobile network prefix on the mobile >>>>>> router. This is not > sufficient. >>>>>> Vijay > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 25 07:53:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwGyr-0006uM-Lp; Sun, 25 Nov 2007 07:53:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwGyp-0006ld-Ii for mext@ietf.org; Sun, 25 Nov 2007 07:52:59 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IwGyl-0002BH-ST for mext@ietf.org; Sun, 25 Nov 2007 07:52:59 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-128.messagelabs.com!1195995174!7766113!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 30633 invoked from network); 25 Nov 2007 12:52:54 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-128.messagelabs.com with SMTP; 25 Nov 2007 12:52:54 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAPCqnYm024901; Sun, 25 Nov 2007 05:52:49 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id lAPCqn4Q011621; Sun, 25 Nov 2007 06:52:49 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.246]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id lAPCqlVt011615; Sun, 25 Nov 2007 06:52:47 -0600 (CST) Message-ID: <4749701E.3050703@gmail.com> Date: Sun, 25 Nov 2007 13:52:46 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: MN-ID extension beyong NAI for PMIPv6 (was: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps) References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071124-0, 24/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: Julien Laganier , 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 Vijay Devarapalli wrote: [...] > 4283bis - There is no draft on this yet, but a need to update > 4283 was identified on the NETLMM mailing list and then > discussed later on the mext mailing list. The update is to > mainly include other subtypes for MN identifier. For example, > the MAC address would be the new subtype. Currently the > document only defines NAI. I mainly agree with that need. I'm not sure however on the interactions with netlmm and pmipv6. The idea about 4283 potential extension (extend MN-ID option to include something else than a NAI) that was developped in the netlmm pmipv6 discussion made a lot of sense to me there. But I'm not following anylonger where is the pmipv6 overall mechanism/vision impacting this. Maybe 4283bissing discussion should be done there? I don't know? Alex > Finally, what happened to > draft-mitsuya-monami6-flow-distribution-policy-04.txt. I > thought this was also going to be adopted as a MONAMI6 WG > document. I might have missed some emails. > > Vijay > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Friday, November 23, 2007 6:10 AM >> To: mext@ietf.org >> Subject: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps >> >> Folks, >> >> We have been discussing with our AD the way forward w.r.t. WG >> drafts inherited from the previous WGs (MIP6, NEMO and MONAMI6). >> >> We have grouped drafts into five categories and decided about >> the actions to be taken for drafts of each category: >> >> --------------------------------------------------------------------- >> >> Cat. I: former WG drafts submitted to IESG already >> >> Action: Address possible IESG Comments/Discusses as they surface. >> >> I-Ds: draft-ietf-mip6-bootstrapping-integrated-dhc-05 >> draft-ietf-mip6-cn-ipsec-06 >> draft-ietf-mip6-ha-switch-05 >> draft-ietf-mip6-hiopt-08 >> draft-ietf-mip6-whyauthdataoption-04 >> draft-ietf-mip6-experimental-messages-03 >> draft-ietf-mip6-vsm-03 >> >> ---------------------------------------------------------------------- >> >> Cat. II: former WG drafts corresponding to MEXT charter work items >> >> Action: - MEXT to adopt drafts as WG drafts >> - authors to submit new versions if/when needed as >> draft- ietf-mext-... >> >> I-Ds (MEXT work item): draft-ietf-nemo-mib-03 work item (B.3) >> draft-ietf-nemo-prefix-delegation-02 (B.3) >> draft-ietf-monami6-mipv6-analysis-04 (A.3) >> >> draft-ietf-monami6-multihoming-motivation-scenario-02 (A.3) >> draft-ietf-monami6-multiplecoa-04 (A.3) >> draft-ietf-mip6-hareliability-03 (A.2) >> draft-ietf-mip6-nemo-v4traversal-05 (A.1) >> draft-ietf-mip6-radius-02 (A.6) >> >> ---------------------------------------------------------------------- >> >> Cat. III: individual drafts corresponding to MEXT charter work items >> that were accepted as former WG drafts but never >> submitted as such. >> >> Action: - MEXT to adopt drafts as WG drafts as long as the >> authors follow the >> conditions requested by the respective WG at the >> moment of acceptancy >> - authors to submit new versions if/when needed as >> draft- ietf-mext-... >> >> I-Ds (MEXT work item): draft-eddy-nemo-aero-reqs-01 (A.5) >> draft-soliman-monami6-flow-binding-04 (A.3) >> >> ---------------------------------------------------------------------- >> >> Cat. IV: individual drafts corresponding to MEXT charter work items >> that were *conditionally* accepted as former WG drafts. >> >> Action: - authors to update drafts so that they fullfills conditions. >> >> I-Ds (MEXT work item): draft-baldessari-c2ccc-nemo-req-01 (A.5) >> >> ---------------------------------------------------------------------- >> >> Cat. V: former WG drafts without corresponding MEXT charter work item >> >> Action: - MEXT to include this drafts as part of the rechartering >> discussion. >> >> I-Ds: draft-ietf-mip6-rfc4285bis-01 >> draft-ietf-mip6-generic-notification-message-00 >> >> -------------------------------------------------------------- >> ---------- >> >> Comments? >> >> Cheers, >> >> -- >> Julien and Marcelo, MEXT chairs >> >> >> _______________________________________________ >> 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 > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 25 07:59:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwH5C-0003dU-Bp; Sun, 25 Nov 2007 07:59:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwH5A-0003dM-Qq for mext@ietf.org; Sun, 25 Nov 2007 07:59:32 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IwH58-0002N1-BF for mext@ietf.org; Sun, 25 Nov 2007 07:59:32 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-153.messagelabs.com!1195995569!14185902!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 11726 invoked from network); 25 Nov 2007 12:59:29 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-15.tower-153.messagelabs.com with SMTP; 25 Nov 2007 12:59:29 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lAPCxQ9w002055; Sun, 25 Nov 2007 05:59:26 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lAPCxPJD001946; Sun, 25 Nov 2007 06:59:25 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.246]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id lAPCxMCG001940; Sun, 25 Nov 2007 06:59:23 -0600 (CST) Message-ID: <474971A9.4030102@gmail.com> Date: Sun, 25 Nov 2007 13:59:21 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [MEXT] MEXT Rechartering References: <699953.80351.qm@web84109.mail.mud.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071124-0, 24/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 marcelo bagnulo braun wrote: > Hi Behcet, > > this is probably beyond the rechartering we have in mind right now... I'd agree. BEsides, one wouldn't automatically include new MEXT work items that haven't been adopted already as WG items in mobility-related WGs. Adopting new pmipv6-whatever drafts extension would be normal subject to wg item adoption first. I'd ask Chairs/AD first. IMHO... Alex > > regards, marcelo > > El 24/11/2007, a las 23:00, Behcet Sarikaya escribió: > >> Hi Marcelo, >> How about including part if not all of netlmm extensions into the >> mext charter. After all they are extensions to PMIPv6 which is itself >> an extension of MIPv6 which is what mext has been chartered for. >> Regards, >> >> Behcet >> >> ----- Original Message ---- >> From: marcelo bagnulo braun >> To: mext@ietf.org >> Sent: Saturday, November 24, 2007 10:55:43 AM >> Subject: [MEXT] MEXT Rechartering >> >> Hi folks, >> >> Even though the WG just been created, we already have some new items >> that people seem to be interested in including in the MEXT charter, >> so we would like to open that discussion right away. Moreover, we are >> planning to devote part of the next meeting in Vancouver to discuss >> possible additional items to be included in the MEXT charter in the >> rechartering process. >> >> So in order to do this process, we would like that if you have items >> that you think should be included in the charter, please send a >> proposal to the MEXT ml so it can be discussed and also if you want >> to include it as part of the MEXT meeting rechartering discussion, >> ask for a slot. >> >> >> Thanks, marcelo >> >> _______________________________________________ >> 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 > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 25 08:03:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwH8a-0007cT-DT; Sun, 25 Nov 2007 08:03:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwH8Y-0007VK-Ig for mext@ietf.org; Sun, 25 Nov 2007 08:03:02 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IwH8Y-00061l-10 for mext@ietf.org; Sun, 25 Nov 2007 08:03:02 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-153.messagelabs.com!1195995780!10890513!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 30511 invoked from network); 25 Nov 2007 13:03:00 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-153.messagelabs.com with SMTP; 25 Nov 2007 13:03:00 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAPD30dg026193; Sun, 25 Nov 2007 06:03:00 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id lAPD2xSa021842; Sun, 25 Nov 2007 07:02:59 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.246]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id lAPD2v0G021813; Sun, 25 Nov 2007 07:02:58 -0600 (CST) Message-ID: <47497280.5090801@gmail.com> Date: Sun, 25 Nov 2007 14:02:56 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "T.J. Kniveton" Subject: Re: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <47489214.7090406@piuha.net> <4748ECDB.1080204@kniveton.com> In-Reply-To: <4748ECDB.1080204@kniveton.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071124-0, 24/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Vijay Devarapalli , 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 T.J. Kniveton wrote: > Jari Arkko wrote: >> Vijay, >> >> >>> High level question. Is there a need to rename all the drafts >>> as draft-ietf-mext...? This always causes confusion when you are >>> trying to go back through the revisions and try to find something >>> that was added/deleted. Can't the drafts retain the names >>> (mip6/nemo/monami6) and progress as MEXT WG documents? >>> >> >> I think this is no longer strictly speaking needed for drafts to >> show up in the right WG pages. However, having the name >> and WG match helps people to understand where drafts >> belong, recognize announcements, etc. As Marcelo wrote, >> there is no need for anyone to rush to submit a draft just >> because of the name change. However, when you have a >> need to change the draft for other reasons, I would >> actually like to see them use a new name as well. >> >> By the way, nothing passed to the AD or IESG should be >> renamed. >> >> Jari >> > > As Behcet pointed out, renaming the draft will reset the draft counter > to -00. We experienced this when renaming some of the "monet" drafts to > "nemo" drafts. However, it's usually not a big deal. Drafts that are > ready to go to IESG could probably keep their current names (since they > will just end up as RFCs anyway), but drafts that will be around for a > while should probably be renamed. I agree it resets the draft counter and a "00" looks fresh new idea although it's been refined already many times. We experienced this with NEMOv4 draft going from individual proposal to NEMO then MIP4 WGs each time resetting the counter. But a good ChangeLog in the draft can be a solution to that problem. Alex > > TJ > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 25 08:16: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 1IwHLC-0001Uq-8S; Sun, 25 Nov 2007 08:16:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwHLB-0001Ul-8c for mext@ietf.org; Sun, 25 Nov 2007 08:16:05 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IwHL8-0002sy-Qd for mext@ietf.org; Sun, 25 Nov 2007 08:16:05 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1195996561!41357829!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 14904 invoked from network); 25 Nov 2007 13:16:01 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-13.tower-119.messagelabs.com with SMTP; 25 Nov 2007 13:16:01 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lAPDG0KX003768; Sun, 25 Nov 2007 06:16:01 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lAPDG01e002286; Sun, 25 Nov 2007 07:16:00 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.246]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id lAPDFvcd002269; Sun, 25 Nov 2007 07:15:58 -0600 (CST) Message-ID: <4749758D.6070003@gmail.com> Date: Sun, 25 Nov 2007 14:15:57 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [MEXT] Next steps on prefix delegation References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> In-Reply-To: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071124-0, 24/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 marcelo bagnulo braun wrote: > Hi all, > > With respect to the NEMO prefix delegation issue, it is my opinion that > it would be preferred to have a single prefix delegation solution rather > than two. Moreover, that we should have strong technical reasons to do > more than one solution since this variety of mechanisms without strong > reasons adds needless complexity. > > So, my first question to the working group is: do you think there are > strong technical reasons to have more than one solution for prefix > delegation? I really hate that question :-) because you're not saying the implications. (sorry Marcelo nothing personal :-) I also understand that one solution is what standards are about :-) > If no, then which would be the preferred approach for prefix delegation > and why? The following is not on the "if no" branch. It's just support argumentation for the DHCPv6-based Prefix Delegation for allocating a prefix to the Mobile Router from an entity in the home network. -DHCP can be reused almost zero modifications (really 0 in some cases). -DHCP has interactions with DNS, this could be used as an advantage in the case of delegation of responsibility of reverse resolution. -allocating prefixes and addresses with MIP6 goes much beyond the typical MIP6 capabilities and design. -leases and timers of allocated addresses: DHCP has built-in, MIP6 would need to develop. -reliability: DHCP Server have graceful failover mechanisms with respect to allocated prefixes. MIP6 would have to develop with respect to allocated prefixes. -potential incoherencies with respect to other MIP6 extensions (PMIPv6 looks at allocating an address/prefix, some other MIP6-related bootstrapping draft IIRC). Alex > > Out goal is to try to wrap up this discussion in the next meting > > Thanks, marcelo > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 25 08:29: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 1IwHXm-0002yz-PV; Sun, 25 Nov 2007 08:29:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwHXl-0002ys-Rl for mext@ietf.org; Sun, 25 Nov 2007 08:29:05 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwHXh-0003G9-FE for mext@ietf.org; Sun, 25 Nov 2007 08:29:05 -0500 Received: from [192.168.1.129] (219.44.217.87.dynamic.jazztel.es [87.217.44.219])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp02.uc3m.es (Postfix) with ESMTP id 8EAD32659A3;Sun, 25 Nov 2007 14:29:00 +0100 (CET) In-Reply-To: <4749758D.6070003@gmail.com> References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <4749758D.6070003@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <38649A85-AA08-4CCC-8525-97CD86C6940C@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MEXT] Next steps on prefix delegation Date: Sun, 25 Nov 2007 14:29:00 +0100 To: Alexandru Petrescu X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-22.0714 TC:1F TRN:43 TV:5.0.1023(15566.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -1.9 (-) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Alex, El 25/11/2007, a las 14:15, Alexandru Petrescu escribi=F3: > marcelo bagnulo braun wrote: >> Hi all, >> With respect to the NEMO prefix delegation issue, it is my opinion =20= >> that it would be preferred to have a single prefix delegation =20 >> solution rather than two. Moreover, that we should have strong =20 >> technical reasons to do more than one solution since this variety =20 >> of mechanisms without strong reasons adds needless complexity. >> So, my first question to the working group is: do you think there =20 >> are strong technical reasons to have more than one solution for =20 >> prefix delegation? > > I really hate that question :-) because you're not saying the =20 > implications. What are the implications you are referring to? regards, marcelo > (sorry Marcelo nothing personal :-) I also understand that one =20 > solution is what standards are about :-) > >> If no, then which would be the preferred approach for prefix =20 >> delegation and why? > > The following is not on the "if no" branch. It's just support =20 > argumentation for the DHCPv6-based Prefix Delegation for allocating =20= > a prefix to the Mobile Router from an entity in the home network. > > -DHCP can be reused almost zero modifications (really 0 in some =20 > cases). > -DHCP has interactions with DNS, this could be used as an advantage > in the case of delegation of responsibility of reverse resolution. > -allocating prefixes and addresses with MIP6 goes much beyond the > typical MIP6 capabilities and design. > -leases and timers of allocated addresses: DHCP has built-in, MIP6 =20 > would > need to develop. > -reliability: DHCP Server have graceful failover mechanisms with =20 > respect > to allocated prefixes. MIP6 would have to develop with respect to > allocated prefixes. > -potential incoherencies with respect to other MIP6 extensions (PMIPv6 > looks at allocating an address/prefix, some other MIP6-related > bootstrapping draft IIRC). > > Alex > >> Out goal is to try to wrap up this discussion in the next meting >> Thanks, marcelo >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email =20 > ______________________________________________________________________ > > _______________________________________________ > 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 Nov 25 08:36:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwHej-0001Fp-2k; Sun, 25 Nov 2007 08:36:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwHei-0001Fg-9q for mext@ietf.org; Sun, 25 Nov 2007 08:36:16 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IwHeh-0006zz-HK for mext@ietf.org; Sun, 25 Nov 2007 08:36:16 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1195997774!22199810!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 7694 invoked from network); 25 Nov 2007 13:36:14 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-119.messagelabs.com with SMTP; 25 Nov 2007 13:36:14 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAPDaAGC000697; Sun, 25 Nov 2007 06:36:14 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id lAPDa9ht003149; Sun, 25 Nov 2007 07:36:10 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.246]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id lAPDa79l003123; Sun, 25 Nov 2007 07:36:08 -0600 (CST) Message-ID: <47497A47.6000002@gmail.com> Date: Sun, 25 Nov 2007 14:36:07 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [MEXT] Prefix Delegation documents References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@g mail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC 6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-stra sbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337 .emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@aza irenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> <47446BCB.5000000@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D35D@xmb-ams-337.emea.cisco.com> <4745B84B.6070002@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071124-0, 24/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: Vijay Devarapalli , 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 Marcelo, marcelo bagnulo braun wrote: > Hi Alex, > > El 22/11/2007, a las 18:11, Alexandru Petrescu escribió: > >> Pascal Thubert (pthubert) wrote: >>> Hi Alex >>> My take is that similar DHAAD flags should be present in both drafts >>> for similar reasons; last I proposed it was rejected; I think that >>> the argument was that locating the HA should be a DNS issue anyway. >>> From the discussion we had recently with Romain, I still think that >>> DHAAD and DNS can be complementary. >>> You have some good points on DNS. But at this time we address >>> prefixes not hosts. How the hosts on the MNP get names and publish >>> those is an interesting issue but out of scope at this time. >> >> How does CN reverse resolve the LFN's IPv6 address (for e.g. when it >> receives mail from it, to avoid spam)? I think MR or other DNS server >> _in_ the moving network should ultimately be in charge for that >> resolution (and not HA or some entities in the home net). >> > > why do you say that? > i mean, consider the case of the personal mobile router, do you think > that my PDA should be my DNS server in charge of the reverse DNS for my > mobil phone? Probably not my PDA, because too small (although my PDA runs a DHCP Server off-the-shelf, something surprising to me a few years ago), but a server in the moving network - yes. If the prefix is allocated to the moving network then I'd want to have all control within that moving network, including DNS. Remark, the MR shouldn't necessary be the DNS Server. > I mean, i may agree that in some cases, this can be a reasonable > approach, but in general i would assume that the DNS servr is located in > th home network (or even in the ISP of the home network) I agree, there should be a DNS Server in the home network, but one in the moving network as well, especially with larger than a PAN moving network. >> And that can only be achieved if the mechanism of prefix allocation is >> tightly coupled with DNS. >> > > right, but it also needs to be a tight mechanims between the address > autoconfiguration mechanism and the DNS update, since at the end of the > day, you don't need to update the prefix in the DNS but the actual > addresses that have been configured, right? I agree, there should be a tight interaction between address autoconfiguration mechanism and DNS updating. I want all DNS PTR requests about an address within a prefix allocated to that moving network to come to a DNS Server within that moving network. (btw, with respect to the question above, I think Secure DNS UPDATE RFC3007 allows to update anything: IN AAAA RR's _and_ PTR RR's - sorry RR: Resource Record not Return Routability). ISC DHCP Server implementation may allow a Client Mobile Router or a DHCP Server to update that entry). >> Otherwise, if you make MIP6 to delegate the prefix to MR then you should >> extend MIP6 to update the DNS server as well. I'm not saying this >> should be done, but that's the consequence, as I see it. >> > > I don't see why this is the case. You can have MIP to delegate the > prefix, and then the MR announces the prefix in RA and then the MNN > autoconfigures the prefix and then it should then updat the DNS, as any > other node that has auto-configured an address How about PTR queries (a 'reverse' resolution)? A CN makes a PTR DNS query about LFN's address (address being derived from the prefix you've put in RA). Who answers that query? The DNS Server in the home network? Or a DNS Server in the moving network? I'd like this latter. I _think_ this can be achieved only if the DHCP Server updates the DNS Server with the IP address of the DNS Server in the movign network. I may be wrong though... to be checked in implementation. Alex >> I understand people may want to do everything with MIP6 (PMIP6, DS-MIP6, >> Monami6, NEMO, etc) but at some point there are some existing things >> that could be reused too. >> > > with that, i fully agree > > >>> The fact that the HA uses NEMO extensions to pass the prefix to the >>> MR does not preclude the use of a DHCP-PD server in the back end. >>> It's just abstracting and simplifying that interaction. >> >> I'm wondering of the necessity of this (a NEMO-MIP6 extension to support >> DHCPv6-PD). I doubt that's needed, DHCPv6-PD would work all by itself, >> I think. >> >>> One problem with the DHCP-PD draft is lifetime of the lease: should >>> it die with the MR-HA tunnel? The Nemo based draft is conscious of >>> the volatility of the tunnel and the HA proxies the PD process for >>> the MR based on the MR demands. >> >> Right problem leasetime I think. >> >> I think if either MIP6-NEMO-PD extensions or DHCPv6-PD is used then in >> any case the DHCPv6 binding lease at the DHCPv6 Server should not >> expire, I don't want another moving network to be allocated the same >> prefix, because I may connect my moving network to that other moving >> network and addresses may collide. >> >> I think overall it is important to stick to one mechanism for >> dynamically allocating prefixes. >> > > again, i fully agree with you > > Regards, marcelo > > > >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 25 08:38: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 1IwHgn-0002px-Kx; Sun, 25 Nov 2007 08:38:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwHgl-0002pr-Qo for mext@ietf.org; Sun, 25 Nov 2007 08:38:23 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IwHgh-0003Xw-IP for mext@ietf.org; Sun, 25 Nov 2007 08:38:23 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1195997898!10520577!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12659 invoked from network); 25 Nov 2007 13:38:18 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-128.messagelabs.com with SMTP; 25 Nov 2007 13:38:18 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAPDcH96000947; Sun, 25 Nov 2007 06:38:18 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id lAPDcHWb003959; Sun, 25 Nov 2007 07:38:17 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.246]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id lAPDcFht003949; Sun, 25 Nov 2007 07:38:16 -0600 (CST) Message-ID: <47497AC7.30007@gmail.com> Date: Sun, 25 Nov 2007 14:38:15 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [MEXT] Next steps on prefix delegation References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <4749758D.6070003@gmail.com> <38649A85-AA08-4CCC-8525-97CD86C6940C@it.uc3m.es> In-Reply-To: <38649A85-AA08-4CCC-8525-97CD86C6940C@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071124-0, 24/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 marcelo bagnulo braun wrote: > Hi Alex, > > El 25/11/2007, a las 14:15, Alexandru Petrescu escribió: > >> marcelo bagnulo braun wrote: >>> Hi all, >>> With respect to the NEMO prefix delegation issue, it is my opinion >>> that it would be preferred to have a single prefix delegation >>> solution rather than two. Moreover, that we should have strong >>> technical reasons to do more than one solution since this variety of >>> mechanisms without strong reasons adds needless complexity. >>> So, my first question to the working group is: do you think there are >>> strong technical reasons to have more than one solution for prefix >>> delegation? >> >> I really hate that question :-) because you're not saying the >> implications. > > What are the implications you are referring to? Do you imply that if we agree there should be one solution and that it turns out voting leads to the MIP6-based prefix allocation then dhcpv6-pd-based prefix allocation for NEMO disappears? Alex > > regards, marcelo > > >> (sorry Marcelo nothing personal :-) I also understand that one >> solution is what standards are about :-) >> >>> If no, then which would be the preferred approach for prefix >>> delegation and why? >> >> The following is not on the "if no" branch. It's just support >> argumentation for the DHCPv6-based Prefix Delegation for allocating a >> prefix to the Mobile Router from an entity in the home network. >> >> -DHCP can be reused almost zero modifications (really 0 in some cases). >> -DHCP has interactions with DNS, this could be used as an advantage >> in the case of delegation of responsibility of reverse resolution. >> -allocating prefixes and addresses with MIP6 goes much beyond the >> typical MIP6 capabilities and design. >> -leases and timers of allocated addresses: DHCP has built-in, MIP6 would >> need to develop. >> -reliability: DHCP Server have graceful failover mechanisms with respect >> to allocated prefixes. MIP6 would have to develop with respect to >> allocated prefixes. >> -potential incoherencies with respect to other MIP6 extensions (PMIPv6 >> looks at allocating an address/prefix, some other MIP6-related >> bootstrapping draft IIRC). >> >> Alex >> >>> Out goal is to try to wrap up this discussion in the next meting >>> Thanks, marcelo >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 25 09:10: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 1IwIBY-0006ib-2S; Sun, 25 Nov 2007 09:10:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwIBX-0006iT-G7 for mext@ietf.org; Sun, 25 Nov 2007 09:10:11 -0500 Received: from smtp01.uc3m.es ([163.117.176.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwIBW-00082h-Ms for mext@ietf.org; Sun, 25 Nov 2007 09:10:11 -0500 Received: from [192.168.1.129] (219.44.217.87.dynamic.jazztel.es [87.217.44.219])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp01.uc3m.es (Postfix) with ESMTP id EF98E250DB8;Sun, 25 Nov 2007 15:04:38 +0100 (CET) In-Reply-To: <47497AC7.30007@gmail.com> References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <4749758D.6070003@gmail.com> <38649A85-AA08-4CCC-8525-97CD86C6940C@it.uc3m.es> <47497AC7.30007@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <47E1FC5E-BC3A-4C96-9D11-2055FB00F074@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MEXT] Next steps on prefix delegation Date: Sun, 25 Nov 2007 15:04:38 +0100 To: Alexandru Petrescu X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-10.6859 TC:1F TRN:26 TV:5.0.1023(15568.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.1 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 El 25/11/2007, a las 14:38, Alexandru Petrescu escribi=F3: > marcelo bagnulo braun wrote: >> Hi Alex, >> El 25/11/2007, a las 14:15, Alexandru Petrescu escribi=F3: >>> marcelo bagnulo braun wrote: >>>> Hi all, >>>> With respect to the NEMO prefix delegation issue, it is my =20 >>>> opinion that it would be preferred to have a single prefix =20 >>>> delegation solution rather than two. Moreover, that we should =20 >>>> have strong technical reasons to do more than one solution since =20= >>>> this variety of mechanisms without strong reasons adds needless =20 >>>> complexity. >>>> So, my first question to the working group is: do you think =20 >>>> there are strong technical reasons to have more than one =20 >>>> solution for prefix delegation? >>> >>> I really hate that question :-) because you're not saying the =20 >>> implications. >> What are the implications you are referring to? > > Do you imply that if we agree there should be one solution and that =20= > it turns out voting leads to the MIP6-based prefix allocation then =20 > dhcpv6-pd-based prefix allocation for NEMO disappears? I am trying not to imply anything, but stating it as much up front as =20= i can :-) We are chartered to work on prefix delegation for NEMO, so we need to =20= produce a solution for that problem. In principle, only one solution. =20= This means that if we find one solution that provides all the =20 features that we consider necessary, yes, we will discard other =20 solutions. It may be the case that we come to the conclusion that we need more =20 than one solution based on technical considerations, such as (for =20 example) that the different approaches work in different scenarios =20 and there is not a single approach that works for all the scenarios =20 that we deem necessary to support. However, we must be convinced that =20= this is the case and i don't think we are there yet. hence, my question to the wg. is this clearer now? Regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 25 12:03:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwKsT-0005qJ-Sk; Sun, 25 Nov 2007 12:02:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwKsS-0005q9-Cw for mext@ietf.org; Sun, 25 Nov 2007 12:02:40 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IwKsO-0001aI-Ue for mext@ietf.org; Sun, 25 Nov 2007 12:02:40 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-153.messagelabs.com!1196010155!7735318!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 12344 invoked from network); 25 Nov 2007 17:02:35 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-8.tower-153.messagelabs.com with SMTP; 25 Nov 2007 17:02:35 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lAPH2ZuU020508; Sun, 25 Nov 2007 10:02:35 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lAPH2YmD002315; Sun, 25 Nov 2007 11:02:34 -0600 (CST) Received: from [127.0.0.1] (mvp-10-169-4-137.corp.mot.com [10.169.4.137]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lAPH2To8002283; Sun, 25 Nov 2007 11:02:32 -0600 (CST) Message-ID: <4749AAA3.5090003@gmail.com> Date: Sun, 25 Nov 2007 18:02:27 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [MEXT] Next steps on prefix delegation References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <4749758D.6070003@gmail.com> <38649A85-AA08-4CCC-8525-97CD86C6940C@it.uc3m.es> <47497AC7.30007@gmail.com> <47E1FC5E-BC3A-4C96-9D11-2055FB00F074@it.uc3m.es> In-Reply-To: <47E1FC5E-BC3A-4C96-9D11-2055FB00F074@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071124-0, 24/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 marcelo bagnulo braun wrote: > > El 25/11/2007, a las 14:38, Alexandru Petrescu escribió: > >> marcelo bagnulo braun wrote: >>> Hi Alex, >>> El 25/11/2007, a las 14:15, Alexandru Petrescu escribió: >>>> marcelo bagnulo braun wrote: >>>>> Hi all, >>>>> With respect to the NEMO prefix delegation issue, it is my opinion >>>>> that it would be preferred to have a single prefix delegation >>>>> solution rather than two. Moreover, that we should have strong >>>>> technical reasons to do more than one solution since this variety >>>>> of mechanisms without strong reasons adds needless complexity. >>>>> So, my first question to the working group is: do you think there >>>>> are strong technical reasons to have more than one solution for >>>>> prefix delegation? >>>> >>>> I really hate that question :-) because you're not saying the >>>> implications. >>> What are the implications you are referring to? >> >> Do you imply that if we agree there should be one solution and that it >> turns out voting leads to the MIP6-based prefix allocation then >> dhcpv6-pd-based prefix allocation for NEMO disappears? > > I am trying not to imply anything, but stating it as much up front as i > can :-) > > We are chartered to work on prefix delegation for NEMO, so we need to > produce a solution for that problem. In principle, only one solution. > This means that if we find one solution that provides all the features > that we consider necessary, yes, we will discard other solutions. > It may be the case that we come to the conclusion that we need more than > one solution based on technical considerations, such as (for example) > that the different approaches work in different scenarios and there is > not a single approach that works for all the scenarios that we deem > necessary to support. However, we must be convinced that this is the > case and i don't think we are there yet. > > hence, my question to the wg. > > is this clearer now? YEs, it is clearer, thanks for the explanation. My answer to the question then is: yes, in principle one solution is. If on technical considerations and different scenarios then we need to support the other as well. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 25 12:16: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 1IwL69-0000aZ-T1; Sun, 25 Nov 2007 12:16:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwL68-0000aP-8J for mext@ietf.org; Sun, 25 Nov 2007 12:16:48 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwL64-0001zN-P6 for mext@ietf.org; Sun, 25 Nov 2007 12:16:48 -0500 Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Nov 2007 09:16:43 -0800 Message-ID: <4749ADFB.8010807@azairenet.com> Date: Sun, 25 Nov 2007 09:16:43 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [MEXT] Prefix delegation & Diameter Interaction References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <47495F23.2040107@gmx.net> In-Reply-To: <47495F23.2040107@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Nov 2007 17:16:44.0013 (UTC) FILETIME=[F3A921D0:01C82F86] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Well, this document seems to assume (or make a case) that the AAA manages the prefixes. We *do not* recommend that model. It is typically either the home agent or a DHCP server co-located with the home agent that manages the prefixes. Vijay Hannes Tschofenig wrote: > Hi all, > > in the DIME working group we have a document that provides the Diameter > interworking for prefix delegation. > Here is the document: > http://tools.ietf.org/wg/dime/draft-sarikaya-dime-prefix-delegation-ps-00.txt > > > It would help us in DIME if members of this group could give us some > feedback. > > Ciao > Hannes > > > _______________________________________________ > 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 Nov 25 13:04: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 1IwLqW-0006Li-BJ; Sun, 25 Nov 2007 13:04:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwLqU-0006Lc-G2 for mext@ietf.org; Sun, 25 Nov 2007 13:04:42 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwLqS-0003DU-3F for mext@ietf.org; Sun, 25 Nov 2007 13:04:42 -0500 Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Nov 2007 10:04:39 -0800 Message-ID: <4749B935.1060707@azairenet.com> Date: Sun, 25 Nov 2007 10:04:37 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hannes Tschofenig , mext@ietf.org Subject: Re: [MEXT] Prefix delegation & Diameter Interaction References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <47495F23.2040107@gmx.net> <4749ADFB.8010807@azairenet.com> In-Reply-To: <4749ADFB.8010807@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Nov 2007 18:04:39.0276 (UTC) FILETIME=[A57372C0:01C82F8D] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 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 Vijay Devarapalli wrote: > Well, this document seems to assume (or make a case) that the AAA > manages the prefixes. We *do not* recommend that model. It is > typically either the home agent or a DHCP server co-located with > the home agent that manages the prefixes. One minor clarification. By co-location, I did not mean that the HA and the DHCP server should be implemented on the same box. Vijay > > Vijay > > Hannes Tschofenig wrote: >> Hi all, >> >> in the DIME working group we have a document that provides the >> Diameter interworking for prefix delegation. >> Here is the document: >> http://tools.ietf.org/wg/dime/draft-sarikaya-dime-prefix-delegation-ps-00.txt >> >> >> It would help us in DIME if members of this group could give us some >> feedback. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> 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 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 25 13:19: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 1IwM4n-0001Og-ER; Sun, 25 Nov 2007 13:19:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwM4m-0001Ob-Sc for mext@ietf.org; Sun, 25 Nov 2007 13:19:28 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwM4j-0003ch-CY for mext@ietf.org; Sun, 25 Nov 2007 13:19:28 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 25 Nov 2007 10:19:25 -0800 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 lAPIJO0K015183; Sun, 25 Nov 2007 10:19:24 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAPIJOut017046; Sun, 25 Nov 2007 18:19:24 GMT Date: Sun, 25 Nov 2007 10:19:24 -0800 (PST) From: Sri Gundavelli To: Hannes Tschofenig Subject: Re: [MEXT] Prefix delegation & Diameter Interaction In-Reply-To: <47495F23.2040107@gmx.net> Message-ID: References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <47495F23.2040107@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1637; t=1196014764; x=1196878764; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20Prefix=20delegation=20&=20Diameter=20Interac tion |Sender:=20; bh=yq1nrtRMxawI3qANHgD9UJlOCuYYm/Uu1t5jMg6w5Bs=; b=CuVKGEltvyp+q5KU5L5N9VMmkFd652bvXB0viXYk7yXXlBmnlhtjip7Ls7xfCLxd5xOZHflL pCcMAw1kiLT+oB1CMAtX8m+hyoqaIjwK2UCnvATJasxRl3FPksXCIXxy; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 > in the DIME working group we have a document that provides the Diameter > interworking for prefix delegation. > Here is the document: > http://tools.ietf.org/wg/dime/draft-sarikaya-dime-prefix-delegation-ps-00.txt > Comments: - The document is making a case that AAA should manage the prefix delegation aspect, just as how it can manage an address for a node. In principle, I agree the home agent or other function that provides mobility can potentially offload the prefix mgmt function to AAA or other entity. It can use DHCPPD, AAA or a local pool for managing this. I agree with the document, that AAA can manage prefixes. The use of AAA is just one mechanism. Typically, if the addressing model is assignment of a prefix for a user, any bootstrapping solution using AAA, can certainly download one more attribute for the user prefix(es). But, I'm not sure if we need to have a PS for this, as supposed to capturing this in a solution document. As this is just a minor thing in all the details related to address mgmt function. Sri On Sun, 25 Nov 2007, Hannes Tschofenig wrote: > Hi all, > > in the DIME working group we have a document that provides the Diameter > interworking for prefix delegation. > Here is the document: > http://tools.ietf.org/wg/dime/draft-sarikaya-dime-prefix-delegation-ps-00.txt > > It would help us in DIME if members of this group could give us some > feedback. > > Ciao > Hannes > > > _______________________________________________ > 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 Nov 25 14:58:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwNcN-0005HH-99; Sun, 25 Nov 2007 14:58:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwNcM-0005E2-2o for mext@ietf.org; Sun, 25 Nov 2007 14:58:14 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwNcL-0000hX-6B for mext@ietf.org; Sun, 25 Nov 2007 14:58:14 -0500 X-IronPort-AV: E=Sophos;i="4.21,464,1188770400"; d="scan'208";a="158717391" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Nov 2007 20:58:12 +0100 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 lAPJwCLE013009; Sun, 25 Nov 2007 20:58:12 +0100 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 lAPJwCZZ019487; Sun, 25 Nov 2007 19:58:12 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); Sun, 25 Nov 2007 20:58:12 +0100 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: [MEXT] Prefix Delegation documents Date: Sun, 25 Nov 2007 20:58:05 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04D3D90A@xmb-ams-337.emea.cisco.com> In-Reply-To: <000e01c82da8$583f7ad0$08be7070$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Prefix Delegation documents Thread-Index: AcgtKtIwzMwzYHWXRl6jRqoh2lg6zQAAiISgAB6GHlAAfZQpsA== References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> <47446BCB.5000000@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D35D@xmb-ams-337.emea.cisco.com> <4745B84B.6070002@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D392@xmb-ams-337.emea.cisco.com> <000e01c82da8$583f7ad0$08be7070$@nl> From: "Pascal Thubert (pthubert)" To: "Teco Boot" X-OriginalArrivalTime: 25 Nov 2007 19:58:12.0319 (UTC) FILETIME=[82574EF0:01C82F9D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5172; t=1196020692; x=1196884692; 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[MEXT]=20=20Prefix=20Delegation=20documents |Sender:=20; bh=5fTIKfT1asnzAEdCgW0p8SiEOZT2eljQDIhBYceFnDs=; b=pO65TTYeYfeT0dlia3NYznBn+6TT6uxSRmapWZ2UuSeUgACWohSYzL54F/xf4aL6nX2exYX3 f7uOV7+JsPE+USrCTA7uZ/xcElslfQF4qGkGYteClKf084ZnfLcjoXKl; 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: Vijay Devarapalli , 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 Teco: I was referring to the model where a HA sits at the edge of a MANET and delegates prefixes for visitors to the MANET. It acts as a secondary HA, a bit like a HMIP MAP. Pascal >-----Original Message----- >From: Teco Boot [mailto:teco@inf-net.nl] >Sent: Friday, November 23, 2007 9:11 AM >To: Pascal Thubert (pthubert) >Cc: 'Vijay Devarapalli'; mext@ietf.org; 'Alexandru Petrescu' >Subject: RE: [MEXT] Prefix Delegation documents > > > >> -----Oorspronkelijk bericht----- >> Van: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] >> Verzonden: donderdag 22 november 2007 18:36 >> Aan: Alexandru Petrescu >> CC: Vijay Devarapalli; Teco Boot; mext@ietf.org >> Onderwerp: RE: [MEXT] Prefix Delegation documents >> >> Hi Alex: >> >> There are actually examples where a short time lease is just what's >> needed. It's good for privacy and a number of other reasons like >> getting >> a prefix that is topologically correct not-too-far. >> >> One of those examples is that of a MR visiting a MANET and getting a >> local prefix for activity within that MANET that is topologically >> correct in the area (AUTOCONF) and from which the MR can form a CoA >> that >> it can keep as it moves around. > >How can a HA know which prefixes are topologically correct in a MANET? >MR is on visiting link, do you assume there is a relation between HA and >this visiting link? > > >> >> Using NEMO to get the prefix enables the mobility of the delegated >> prefix in and out the MANET - using or not the MANET protocol while in >> the MANET space - till the MR finds that the prefix is useless and >> forgets about it all. > >I think the MR can notify the HA that the delegated prefix is no longer >being used and ownership is given back to HA. >We can use the same mechanism for short time leases (e.g. transient) and >long time leases (e.g. persistent). > >Teco. > >> >> Pascal >> >> >-----Original Message----- >> >From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> >Sent: Thursday, November 22, 2007 6:12 PM >> >To: Pascal Thubert (pthubert) >> >Cc: Vijay Devarapalli; Teco Boot; mext@ietf.org >> >Subject: Re: [MEXT] Prefix Delegation documents >> > >> >Pascal Thubert (pthubert) wrote: >> >> Hi Alex >> >> >> >> My take is that similar DHAAD flags should be present in both drafts >> >> for similar reasons; last I proposed it was rejected; I think that >> >> the argument was that locating the HA should be a DNS issue anyway. >> >> From the discussion we had recently with Romain, I still think that >> >> DHAAD and DNS can be complementary. >> >> >> >> You have some good points on DNS. But at this time we address >> >> prefixes not hosts. How the hosts on the MNP get names and publish >> >> those is an interesting issue but out of scope at this time. >> > >> >How does CN reverse resolve the LFN's IPv6 address (for e.g. when it >> >receives mail from it, to avoid spam)? I think MR or other DNS server >> >_in_ the moving network should ultimately be in charge for that >> >resolution (and not HA or some entities in the home net). >> > >> >And that can only be achieved if the mechanism of prefix allocation is >> >tightly coupled with DNS. >> > >> >Otherwise, if you make MIP6 to delegate the prefix to MR then you >> should >> >extend MIP6 to update the DNS server as well. I'm not saying this >> >should be done, but that's the consequence, as I see it. >> > >> >I understand people may want to do everything with MIP6 (PMIP6, >> DS-MIP6, >> >Monami6, NEMO, etc) but at some point there are some existing things >> >that could be reused too. >> > >> >> The fact that the HA uses NEMO extensions to pass the prefix to the >> >> MR does not preclude the use of a DHCP-PD server in the back end. >> >> It's just abstracting and simplifying that interaction. >> > >> >I'm wondering of the necessity of this (a NEMO-MIP6 extension to >> support >> >DHCPv6-PD). I doubt that's needed, DHCPv6-PD would work all by >> itself, >> >I think. >> > >> >> One problem with the DHCP-PD draft is lifetime of the lease: should >> >> it die with the MR-HA tunnel? The Nemo based draft is conscious of >> >> the volatility of the tunnel and the HA proxies the PD process for >> >> the MR based on the MR demands. >> > >> >Right problem leasetime I think. >> > >> >I think if either MIP6-NEMO-PD extensions or DHCPv6-PD is used then in >> >any case the DHCPv6 binding lease at the DHCPv6 Server should not >> >expire, I don't want another moving network to be allocated the same >> >prefix, because I may connect my moving network to that other moving >> >network and addresses may collide. >> > >> >I think overall it is important to stick to one mechanism for >> >dynamically allocating prefixes. >> > >> >Alex >> > >> > >> >______________________________________________________________________ >> >This email has been scanned by the MessageLabs Email Security System. >> >For more information please visit http://www.messagelabs.com/email >> >______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 25 15:00: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 1IwNeW-00084q-Vr; Sun, 25 Nov 2007 15:00:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwNeV-00080p-Gm for mext@ietf.org; Sun, 25 Nov 2007 15:00:27 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwNeV-0000kJ-11 for mext@ietf.org; Sun, 25 Nov 2007 15:00:27 -0500 X-IronPort-AV: E=Sophos;i="4.21,464,1188770400"; d="scan'208";a="158717447" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Nov 2007 21:00:26 +0100 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 lAPK0QS5013295; Sun, 25 Nov 2007 21:00:26 +0100 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 lAPK0QZZ019991; Sun, 25 Nov 2007 20:00:26 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); Sun, 25 Nov 2007 21:00:26 +0100 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: [MEXT] Prefix Delegation documents Date: Sun, 25 Nov 2007 21:00:18 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04D3D90B@xmb-ams-337.emea.cisco.com> In-Reply-To: <4745D5D5.10905@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Prefix Delegation documents Thread-Index: AcgtPGjJEKvoQGO+TreV9O5G0YCFYgCYTkyA References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> <47446BCB.5000000@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D35D@xmb-ams-337.emea.cisco.com> <4745B84B.6070002@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D392@xmb-ams-337.emea.cisco.com> <4745D5D5.10905@gmail.com> From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 25 Nov 2007 20:00:26.0191 (UTC) FILETIME=[D2228DF0:01C82F9D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2433; t=1196020826; x=1196884826; 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[MEXT]=20=20Prefix=20Delegation=20documents |Sender:=20; bh=dMRRrv3dULx8IdVHsVBQQKgy0AIB7GGqVwlNqhRs5yk=; b=tmknrd20fPti3SGc0PgU64QRcbEEMubKeJ4nK+LyYZqOcrR34i5ftnKbgirJccLklL7EdE57 ETWJcLk/jv7uf7YkoII30r77O57g7Oh4NbeDTGLI0nSH3ixmZyzq8TUW; 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: 0a7aa2e6e558383d84476dc338324fab Cc: Vijay Devarapalli , 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 Alex: It will run what's necessary and standard :) delegation within NEMO enables a tighter coupling and dependency management, and less messages. Pascal >-----Original Message----- >From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >Sent: Thursday, November 22, 2007 8:18 PM >To: Pascal Thubert (pthubert) >Cc: Vijay Devarapalli; Teco Boot; mext@ietf.org >Subject: Re: [MEXT] Prefix Delegation documents > >Salut Pascal, > >Pascal Thubert (pthubert) wrote: >> Hi Alex: >> >> There are actually examples where a short time lease is just what's >> needed. It's good for privacy and a number of other reasons like >> getting a prefix that is topologically correct not-too-far. > >I can agree that that there are scenarios where short time leases of a >prefix allocated by DHCP to a Mobile Router make sense. A user PAN is >an example. (a larger entity as a ship doing on2ly 2-3 handovers during >a transatlantic cruise probably needs more lease time). > >I wanted to say that there are also scenarios where prefixes allocated >to a moving network are longer term, and the MR-HA tunnel being down >shouldn't mean that that prefix is no longer used in that ship. > >> One of those examples is that of a MR visiting a MANET and getting a >> local prefix for activity within that MANET that is topologically >> correct in the area (AUTOCONF) and from which the MR can form a CoA >> that it can keep as it moves around. > >Somehow yes, I agree with you Mobile Router visiting a MANET and getting >a 'local' prefix (but still 'global' topologically correct) from it it >will probably be short-lived. > >> Using NEMO to get the prefix enables the mobility of the delegated >> prefix in and out the MANET - using or not the MANET protocol while >> in the MANET space - till the MR finds that the prefix is useless and >> forgets about it all. > >In order for the MANET network to deliver prefixes to visitors, do you >think a MANET network is more likely to run a HA inside or a DHCPv6 >Server? (my Windows Mobile PDA runs DHCPv4 Server, to not name a >manufacturer). > >Alex > >______________________________________________________________________ >This email has been scanned by the MessageLabs Email Security System. >For more information please visit http://www.messagelabs.com/email >______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From RichardorpheusMiller@rutlandherald.com Sun Nov 25 16:45:17 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwPHx-0007Zl-JC; Sun, 25 Nov 2007 16:45:17 -0500 Received: from 137stb24.codetel.net.do ([64.32.94.137] helo=servidor) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IwPHx-00036c-2S; Sun, 25 Nov 2007 16:45:17 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host35565661.rutlandherald.com (8.13.1/8.13.1) with SMTP id 0tUDKUjL92.700150.9lr.n2j.5662368901824 for ; Sun, 25 Nov 2007 17:45:46 +0400 Message-ID: <12ba801c82fac$abab9bd0$0300000a@Servidor> From: "David Robinson" To: Subject: Your health Date: Sun, 25 Nov 2007 17:45:46 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_12BA4_01C82FAC.ABAB9BD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_12BA4_01C82FAC.ABAB9BD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_12BA4_01C82FAC.ABAB9BD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_12BA4_01C82FAC.ABAB9BD0-- From mext-bounces@ietf.org Sun Nov 25 20:20: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 1IwSeF-0002kl-As; Sun, 25 Nov 2007 20:20:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwSeD-0002ka-Oh for mext@ietf.org; Sun, 25 Nov 2007 20:20:29 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwSeC-0008BB-Bd for mext@ietf.org; Sun, 25 Nov 2007 20:20:29 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lAQ1KNEw010133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 25 Nov 2007 17:20:24 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lAQ1KMOL022039; Sun, 25 Nov 2007 17:20:23 -0800 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Nov 2007 17:20:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps Date: Sun, 25 Nov 2007 17:20:21 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps Thread-Index: Acgt2vpYPayQwUtKTpKa7erUaRmQZwA4nLOQAEM8hZA= From: "Giaretta, Gerardo" To: "Vijay Devarapalli" , "marcelo bagnulo braun" , X-OriginalArrivalTime: 26 Nov 2007 01:20:22.0801 (UTC) FILETIME=[8434C810:01C82FCA] X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: Julien Laganier 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 Marcelo and Vijay, draft-ietf-mip6-aaa-ha-goals needs an update after the WGLC in MIP6. A revision will be available after the Vancouver IETF meeting. Thanks Gerardo -----Original Message----- From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com]=20 Sent: Saturday, November 24, 2007 9:24 AM To: marcelo bagnulo braun; mext@ietf.org Cc: Julien Laganier Subject: RE: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps=20 Marcelo, The following drafts are missing.=20 draft-ietf-mip6-aaa-ha-goals - I think this document completed=20 MIP6 WG last call. It is currently expired. draft-devarapalli-mip6-authprotocol-bootstrap - There is an ongoing consensus(?) call to make this a WG document. Not sure if it is actually a consensus call. Something about gauging interest. :) 4283bis - There is no draft on this yet, but a need to update 4283 was identified on the NETLMM mailing list and then=20 discussed later on the mext mailing list. The update is to mainly include other subtypes for MN identifier. For example, the MAC address would be the new subtype. Currently the=20 document only defines NAI. Finally, what happened to=20 draft-mitsuya-monami6-flow-distribution-policy-04.txt. I=20 thought this was also going to be adopted as a MONAMI6 WG=20 document. I might have missed some emails. Vijay > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Friday, November 23, 2007 6:10 AM > To: mext@ietf.org > Subject: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps=20 >=20 > Folks, >=20 > We have been discussing with our AD the way forward w.r.t. WG=20 > drafts inherited from the previous WGs (MIP6, NEMO and MONAMI6). >=20 > We have grouped drafts into five categories and decided about=20 > the actions to be taken for drafts of each category: >=20 > --------------------------------------------------------------------- >=20 > Cat. I: former WG drafts submitted to IESG already >=20 > Action: Address possible IESG Comments/Discusses as they surface. >=20 > I-Ds: draft-ietf-mip6-bootstrapping-integrated-dhc-05 > draft-ietf-mip6-cn-ipsec-06 > draft-ietf-mip6-ha-switch-05 > draft-ietf-mip6-hiopt-08 > draft-ietf-mip6-whyauthdataoption-04 > draft-ietf-mip6-experimental-messages-03 > draft-ietf-mip6-vsm-03 >=20 > ---------------------------------------------------------------------- >=20 > Cat. II: former WG drafts corresponding to MEXT charter work items >=20 > Action: - MEXT to adopt drafts as WG drafts > - authors to submit new versions if/when needed as=20 > draft- ietf-mext-... >=20 > I-Ds (MEXT work item): draft-ietf-nemo-mib-03 work item (B.3) > draft-ietf-nemo-prefix-delegation-02 (B.3) > draft-ietf-monami6-mipv6-analysis-04 (A.3) > =09 > draft-ietf-monami6-multihoming-motivation-scenario-02 (A.3) > draft-ietf-monami6-multiplecoa-04 (A.3) > draft-ietf-mip6-hareliability-03 (A.2) > draft-ietf-mip6-nemo-v4traversal-05 (A.1) > draft-ietf-mip6-radius-02 (A.6) >=20 > ---------------------------------------------------------------------- >=20 > Cat. III: individual drafts corresponding to MEXT charter work items > that were accepted as former WG drafts but never=20 > submitted as such. >=20 > Action: - MEXT to adopt drafts as WG drafts as long as the=20 > authors follow the > conditions requested by the respective WG at the=20 > moment of acceptancy > - authors to submit new versions if/when needed as=20 > draft- ietf-mext-... >=20 > I-Ds (MEXT work item): draft-eddy-nemo-aero-reqs-01 (A.5) > draft-soliman-monami6-flow-binding-04 (A.3) >=20 > ---------------------------------------------------------------------- >=20 > Cat. IV: individual drafts corresponding to MEXT charter work items > that were *conditionally* accepted as former WG drafts. >=20 > Action: - authors to update drafts so that they fullfills conditions. >=20 > I-Ds (MEXT work item): draft-baldessari-c2ccc-nemo-req-01 (A.5) >=20 > ---------------------------------------------------------------------- >=20 > Cat. V: former WG drafts without corresponding MEXT charter work item >=20 > Action: - MEXT to include this drafts as part of the rechartering > discussion. >=20 > I-Ds: draft-ietf-mip6-rfc4285bis-01 > draft-ietf-mip6-generic-notification-message-00 >=20 > -------------------------------------------------------------- > ---------- >=20 > Comments? >=20 > Cheers, >=20 > -- > Julien and Marcelo, MEXT chairs >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext >=20 _______________________________________________ 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 Nov 25 21:56:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwU8h-0005sp-A7; Sun, 25 Nov 2007 21:56:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwU8g-0005sk-Hv for mext@ietf.org; Sun, 25 Nov 2007 21:56:02 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwU8e-0007ag-6y for mext@ietf.org; Sun, 25 Nov 2007 21:56:02 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id D364A108009 for ; Sun, 25 Nov 2007 21:55:56 -0500 (EST) 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 31278-17 for ; Sun, 25 Nov 2007 21:55:56 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Sun, 25 Nov 2007 21:55:56 -0500 (EST) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Nov 2007 21:54:36 -0500 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: [MEXT] Prefix delegation & Diameter Interaction Date: Sun, 25 Nov 2007 21:55:55 -0500 Message-ID: <4D35478224365146822AE9E3AD4A26668777BD@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Prefix delegation & Diameter Interaction Thread-Index: AcgvhwbsR5oAtG+kRD6q1CVUkIaH2wAUFhSg From: "Chowdhury, Kuntal" To: "Vijay Devarapalli" , "Hannes Tschofenig" X-OriginalArrivalTime: 26 Nov 2007 02:54:36.0327 (UTC) FILETIME=[ADF86370:01C82FD7] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com 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 I agree with Vijay. During mip6 bootstrapping solution discussion we had a proposal to assign HL prefix from the AAA. The WG decided to stay away from that. BR, Kuntal =20 -----Original Message----- From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 Sent: Sunday, November 25, 2007 11:17 AM To: Hannes Tschofenig Cc: mext@ietf.org Subject: Re: [MEXT] Prefix delegation & Diameter Interaction Well, this document seems to assume (or make a case) that the AAA manages the prefixes. We *do not* recommend that model. It is typically either the home agent or a DHCP server co-located with the home agent that manages the prefixes. Vijay Hannes Tschofenig wrote: > Hi all, >=20 > in the DIME working group we have a document that provides the=20 > Diameter interworking for prefix delegation. > Here is the document: > http://tools.ietf.org/wg/dime/draft-sarikaya-dime-prefix-delegation-ps > -00.txt >=20 >=20 > It would help us in DIME if members of this group could give us some=20 > feedback. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > 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 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 25 22:36: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 1IwUlL-0005NZ-05; Sun, 25 Nov 2007 22:35:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUlJ-0005NQ-OT for mext@ietf.org; Sun, 25 Nov 2007 22:35:57 -0500 Received: from nlpi001.sbcis.sbc.com ([207.115.36.30] helo=nlpi001.prodigy.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwUlJ-0003Bd-By for mext@ietf.org; Sun, 25 Nov 2007 22:35:57 -0500 X-ORBL: [70.242.121.146] Received: from ny3104051930 (ppp-70-242-121-146.dsl.rcsntx.swbell.net [70.242.121.146]) by nlpi001.prodigy.net (8.13.8 out.dk.spool/8.13.8) with ESMTP id lAQ3ZgCD002400; Sun, 25 Nov 2007 21:35:44 -0600 Message-ID: <011a01c82fdd$d573e7c0$0701a8c0@china.huawei.com> From: "Frank Xia" To: "Vijay Devarapalli" , "Hannes Tschofenig" References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <47495F23.2040107@gmx.net> <4749ADFB.8010807@azairenet.com> Subject: Re: [MEXT] Prefix delegation & Diameter Interaction Date: Sun, 25 Nov 2007 21:38:38 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 2.8 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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="===============0930589996==" Errors-To: mext-bounces@ietf.org --===============0930589996== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgVmlqYXkNCg0KQUFBIHNlcnZlcnMgIG1hbmFnaW5nIGFkZHJlc3MgcG9vbCBpcyBvbmUgb2Yg dGhlIGJhc2ljIGZ1bnRpb25zIGluIHRoZSBpbmR1c3RyeS4gICANCg0KSW4gdGhlIHBvaW50LXRv LXBvaW50IHNjZW5hcmlvLCBkaWZmZXJlbnQgTU5zIGhhdmUgZGlmZmVyZW50IHByZWZpeGVzLiAg VGhhdCBpcyAsDQpwcmVmaXggbWFuYWdpbmcgaXMgdGhlIG5hdHVyYWwgZXh0ZW5zaW9uIGZvciB0 aGUgYWRkcmVzcyBtYW5hZ2VtZW50Lg0KDQpQbGVhc2Ugc2VlIG90aGVyICBpbmxpbmUgcmVzcG9u c2UuLi4NCg0KQlINCkZyYW5rDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9t OiAiVmlqYXkgRGV2YXJhcGFsbGkiIDx2aWpheS5kZXZhcmFwYWxsaUBhemFpcmVuZXQuY29tPg0K VG86ICJIYW5uZXMgVHNjaG9mZW5pZyIgPEhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQ+DQpDYzog PG1leHRAaWV0Zi5vcmc+DQpTZW50OiBTdW5kYXksIE5vdmVtYmVyIDI1LCAyMDA3IDExOjE2IEFN DQpTdWJqZWN0OiBSZTogW01FWFRdIFByZWZpeCBkZWxlZ2F0aW9uICYgRGlhbWV0ZXIgSW50ZXJh Y3Rpb24NCg0KDQo+IFdlbGwsIHRoaXMgZG9jdW1lbnQgc2VlbXMgdG8gYXNzdW1lIChvciBtYWtl IGEgY2FzZSkgdGhhdCB0aGUgQUFBDQo+IG1hbmFnZXMgdGhlIHByZWZpeGVzLiBXZSAqZG8gbm90 KiByZWNvbW1lbmQgdGhhdCBtb2RlbC4gSXQgaXMNCj4gdHlwaWNhbGx5IGVpdGhlciB0aGUgaG9t ZSBhZ2VudCBvciBhIERIQ1Agc2VydmVyIGNvLWxvY2F0ZWQgd2l0aA0KPiB0aGUgaG9tZSBhZ2Vu dCB0aGF0IG1hbmFnZXMgdGhlIHByZWZpeGVzLg0KRnJhbms9Pkl0IGlzIHN1cmUgdGhhdCBob21l IGFnZW50ICBvciBidWlsdC1pbiBESENQIHNlcnZlciBjYW4gbWFuYWdlDQpwcmVmaXhlcy4gICBU aGlzIGlzIGxvY2FsIHByZWZpeCBtYW5hZ2VtZW50IG1vZGUuICBJTUhPLCAgaXQgaXMgbm90IG9w dGltYWwuIA0KSWYgd2UgdGhpbmsgdGhhdCAgcHJlZml4IG1hbmFnZW1lbnQgaXMgdGhlIGV4dGVu c2lvbiBvZiBhZGRyZXNzIG1hbmFnZW1lbnQsDQppdCBpcyBlYXN5IHRvIHRoaW5rIGFib3V0IHJl bW90ZSBwcmVmaXggbWFuYWdlbWVudCBtb2RlLiANCg0KPiANCj4gVmlqYXkNCj4gDQo+IEhhbm5l cyBUc2Nob2ZlbmlnIHdyb3RlOg0KPiA+IEhpIGFsbCwNCj4gPiANCj4gPiBpbiB0aGUgRElNRSB3 b3JraW5nIGdyb3VwIHdlIGhhdmUgYSBkb2N1bWVudCB0aGF0IHByb3ZpZGVzIHRoZSBEaWFtZXRl ciANCj4gPiBpbnRlcndvcmtpbmcgZm9yIHByZWZpeCBkZWxlZ2F0aW9uLg0KPiA+IEhlcmUgaXMg dGhlIGRvY3VtZW50Og0KPiA+IGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9kaW1lL2RyYWZ0LXNh cmlrYXlhLWRpbWUtcHJlZml4LWRlbGVnYXRpb24tcHMtMDAudHh0IA0KPiA+IA0KPiA+IA0KPiA+ IEl0IHdvdWxkIGhlbHAgdXMgaW4gRElNRSBpZiBtZW1iZXJzIG9mIHRoaXMgZ3JvdXAgY291bGQg Z2l2ZSB1cyBzb21lIA0KPiA+IGZlZWRiYWNrLg0KPiA+IA0KPiA+IENpYW8NCj4gPiBIYW5uZXMN Cj4gPiANCj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+IE1FWFQgbWFpbGluZyBsaXN0DQo+ID4gTUVYVEBpZXRmLm9yZw0KPiA+IGh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21leHQNCj4gDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBNRVhUIG1haWxp bmcgbGlzdA0KPiBNRVhUQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21leHQ= --===============0930589996== 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 --===============0930589996==-- From mext-bounces@ietf.org Sun Nov 25 22:45: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 1IwUuP-0005MW-RP; Sun, 25 Nov 2007 22:45:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwUuO-0005MQ-AO for mext@ietf.org; Sun, 25 Nov 2007 22:45:20 -0500 Received: from nlpi043.sbcis.sbc.com ([207.115.36.72] helo=nlpi043.prodigy.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwUuK-0000LU-TZ for mext@ietf.org; Sun, 25 Nov 2007 22:45:20 -0500 X-ORBL: [70.242.121.146] Received: from ny3104051930 (ppp-70-242-121-146.dsl.rcsntx.swbell.net [70.242.121.146]) by nlpi043.prodigy.net (8.13.8 out.dk.spool/8.13.8) with ESMTP id lAQ3j1pe002763; Sun, 25 Nov 2007 21:45:04 -0600 Message-ID: <012701c82fdf$23de68d0$0701a8c0@china.huawei.com> From: "Frank Xia" To: "Chowdhury, Kuntal" , "Vijay Devarapalli" , "Hannes Tschofenig" References: <4D35478224365146822AE9E3AD4A26668777BD@exchtewks3.starentnetworks.com> Subject: Re: [MEXT] Prefix delegation & Diameter Interaction Date: Sun, 25 Nov 2007 21:47:57 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 2.8 (++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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="===============2023454793==" Errors-To: mext-bounces@ietf.org --===============2023454793== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgS3VudGFsDQoNCkNvdWxkIHlvdSBnaXZlIHNvbWUgYnJpZWYgIGJhY2tncm91bmQgaW5mb3Jt YXRpb24gYWJvdXQgdGhlIGRpc2N1c3Npb24geW91IHJlZmVyZWQgdG8/DQoNCklmIHRoZSBkaXNj dXNzaW9uIHdhcyBhYm91dCB1c2luZyBSQURJVVMgZm9yIHByZWZpeCBkZWxhZ2F0aW9uLCAgSSB0 aGluayBpdCBtYWRlIHNlbnNlIGJlY2F1c2UNClJBRElVUyBwcm90b2NvbCBoYXMgc29tZSBsaW1p dGF0aW9ucywgc3VjaCBhcyAgdGhhdCBSQURJVVMgc2VydmVyIGNhbid0IHNlbmQgdW5zb2xpY2l0 ZWQNCm1lc3NhZ2UgdG8gY2xpZW50IChSRkMzNTc2IGlzIGluZm9ybWF0aW9uYWwpLg0KDQpCdXQs IERpYW1ldGVyIGlzIGRpZmZlcmVudCAuLi4NCg0KQlINCkZyYW5rDQoNCi0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiQ2hvd2RodXJ5LCBLdW50YWwiIDxrY2hvd2RodXJ5QHN0 YXJlbnRuZXR3b3Jrcy5jb20+DQpUbzogIlZpamF5IERldmFyYXBhbGxpIiA8dmlqYXkuZGV2YXJh cGFsbGlAYXphaXJlbmV0LmNvbT47ICJIYW5uZXMgVHNjaG9mZW5pZyIgPEhhbm5lcy5Uc2Nob2Zl bmlnQGdteC5uZXQ+DQpDYzogPG1leHRAaWV0Zi5vcmc+DQpTZW50OiBTdW5kYXksIE5vdmVtYmVy IDI1LCAyMDA3IDg6NTUgUE0NClN1YmplY3Q6IFJFOiBbTUVYVF0gUHJlZml4IGRlbGVnYXRpb24g JiBEaWFtZXRlciBJbnRlcmFjdGlvbg0KDQoNCkkgYWdyZWUgd2l0aCBWaWpheS4gRHVyaW5nIG1p cDYgYm9vdHN0cmFwcGluZyBzb2x1dGlvbiBkaXNjdXNzaW9uIHdlIGhhZA0KYSBwcm9wb3NhbCB0 byBhc3NpZ24gSEwgcHJlZml4IGZyb20gdGhlIEFBQS4gVGhlIFdHIGRlY2lkZWQgdG8gc3RheSBh d2F5DQpmcm9tIHRoYXQuDQoNCkJSLA0KS3VudGFsDQogDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBWaWpheSBEZXZhcmFwYWxsaSBbbWFpbHRvOnZpamF5LmRldmFyYXBhbGxp QGF6YWlyZW5ldC5jb21dIA0KU2VudDogU3VuZGF5LCBOb3ZlbWJlciAyNSwgMjAwNyAxMToxNyBB TQ0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnDQpDYzogbWV4dEBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtNRVhUXSBQcmVmaXggZGVsZWdhdGlvbiAmIERpYW1ldGVyIEludGVyYWN0aW9uDQoNCldlbGws IHRoaXMgZG9jdW1lbnQgc2VlbXMgdG8gYXNzdW1lIChvciBtYWtlIGEgY2FzZSkgdGhhdCB0aGUg QUFBDQptYW5hZ2VzIHRoZSBwcmVmaXhlcy4gV2UgKmRvIG5vdCogcmVjb21tZW5kIHRoYXQgbW9k ZWwuIEl0IGlzIHR5cGljYWxseQ0KZWl0aGVyIHRoZSBob21lIGFnZW50IG9yIGEgREhDUCBzZXJ2 ZXIgY28tbG9jYXRlZCB3aXRoIHRoZSBob21lIGFnZW50DQp0aGF0IG1hbmFnZXMgdGhlIHByZWZp eGVzLg0KDQpWaWpheQ0KDQpIYW5uZXMgVHNjaG9mZW5pZyB3cm90ZToNCj4gSGkgYWxsLA0KPiAN Cj4gaW4gdGhlIERJTUUgd29ya2luZyBncm91cCB3ZSBoYXZlIGEgZG9jdW1lbnQgdGhhdCBwcm92 aWRlcyB0aGUgDQo+IERpYW1ldGVyIGludGVyd29ya2luZyBmb3IgcHJlZml4IGRlbGVnYXRpb24u DQo+IEhlcmUgaXMgdGhlIGRvY3VtZW50Og0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvZGlt ZS9kcmFmdC1zYXJpa2F5YS1kaW1lLXByZWZpeC1kZWxlZ2F0aW9uLXBzDQo+IC0wMC50eHQNCj4g DQo+IA0KPiBJdCB3b3VsZCBoZWxwIHVzIGluIERJTUUgaWYgbWVtYmVycyBvZiB0aGlzIGdyb3Vw IGNvdWxkIGdpdmUgdXMgc29tZSANCj4gZmVlZGJhY2suDQo+IA0KPiBDaWFvDQo+IEhhbm5lcw0K PiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IE1FWFQgbWFpbGluZyBsaXN0DQo+IE1FWFRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4dA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpNRVhUIG1haWxpbmcgbGlzdA0KTUVYVEBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4dA0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTUVYVCBtYWlsaW5nIGxp c3QNCk1FWFRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21leHQNCg== --===============2023454793== 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 --===============2023454793==-- From mext-bounces@ietf.org Sun Nov 25 23:17: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 1IwVPj-0006Qe-Uc; Sun, 25 Nov 2007 23:17:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwVPi-0006QW-5z for mext@ietf.org; Sun, 25 Nov 2007 23:17:42 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwVPh-0004GA-EF for mext@ietf.org; Sun, 25 Nov 2007 23:17:42 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id lAQ4Ha2Q008239 for ; Mon, 26 Nov 2007 13:17:36 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id lAQ4Hbm23353 for ; Mon, 26 Nov 2007 13:17:37 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id lAQ4HZg25758 for ; Mon, 26 Nov 2007 13:17:35 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 12:17:26 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Mon, 26 Nov 2007 12:17:22 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Mon, 26 Nov 2007 12:17:22 +0800 From: "Benjamin Lim" To: Subject: RE: [MEXT] Comments on draft-ietf-monami6-multiplecoa-04.txt Date: Mon, 26 Nov 2007 12:17:22 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: AcgsR/qszufZXqtDS0m1Ggdq+RxSYADlEb5gAAALgzA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Message-ID: X-OriginalArrivalTime: 26 Nov 2007 04:17:26.0259 (UTC) FILETIME=[4047D430:01C82FE3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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, My 2 'sense' on one point raised. =8==8<=8== > 3) Bulk Registrations and CNs: It is not clear why bulk > registrations are not allowed for CNs. Is it so much more > complex to handle bulk registrations once that is defined for > the HA and once the CNs handle MCoAs one at a time? [Ben] This point I agree with George. I feel that we might need to consider extending Bulk Reg to CN. >From what I understand on why bulk registration is not used for CN is that the complexity it creates trying to figure out how to protect the BU with multiple CoKs and one HoK and in the same time proving to the CN that all the specified CoAs in the bulk BU are valid routing addresses to MN. It boils down to the matter on whether the benefit of bulk registration is worth the solving of such a complex procedure. One benefit I see in bulk registration is the effect it has on saving the power consumption for the MN. E.g. MN can use one of its IF to send a bulk BU to HA to bind CoAs for its other interfaces. This means that those IFs can be in idle mode only to be woken up upon the need to receive/send packets. This saves power on maintaining the multiple IFs of the MN. So such saving in power at the MN might be worth considering exploring on this matter. Also, I feel that other considerations on what impact would MN trigger when using bulk registration. For instance, in my recently submitted ID (http://www.ietf.org/internet-drafts/draft-lim-mext-multiple-coa-verify-00.t xt), I mention MN using bulk registration might be able to bind CoAs of victims at HA and thereby leading to a flooding attack to those victims. I believe it is worth taking such issue into consideration. Regards, Benjamin Lim _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 02:25: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 1IwYLV-0007L6-E9; Mon, 26 Nov 2007 02:25:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwYLT-0007Kz-Tr for mext@ietf.org; Mon, 26 Nov 2007 02:25:31 -0500 Received: from deimos.multihop.net ([74.0.36.190] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwYLM-0005IV-6H for mext@ietf.org; Mon, 26 Nov 2007 02:25:31 -0500 Received: by deimos.multihop.net (Postfix, from userid 1013) id 5FB7DA0A9C6; Sun, 25 Nov 2007 23:25:21 -0800 (PST) X-Spam-Score: -4.4 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on deimos.multihop.net X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Received: from [192.168.4.25] (ibmx31.tehama.multihop.net [192.168.4.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 88AC4A0A987; Sun, 25 Nov 2007 23:25:08 -0800 (PST) Message-ID: <474A74D3.30205@kniveton.com> Date: Sun, 25 Nov 2007 23:25:07 -0800 From: "T.J. Kniveton" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [MEXT] Next steps on prefix delegation References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <4749758D.6070003@gmail.com> <38649A85-AA08-4CCC-8525-97CD86C6940C@it.uc3m.es> <47497AC7.30007@gmail.com> <47E1FC5E-BC3A-4C96-9D11-2055FB00F074@it.uc3m.es> In-Reply-To: <47E1FC5E-BC3A-4C96-9D11-2055FB00F074@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 marcelo bagnulo braun wrote: > > It may be the case that we come to the conclusion that we need more > than one solution based on technical considerations, such as (for > example) that the different approaches work in different scenarios and > there is not a single approach that works for all the scenarios that > we deem necessary to support. However, we must be convinced that this > is the case and i don't think we are there yet. Yes, it is the case that the two solutions are based on different technical considerations, and that they work in different scenarios. They have different properties, and require different levels of implementation complexity to achieve them. Making an informed decision would require understanding these trade-offs, ideally by implementing one or both. The reason that Pascal and I wrote the NEMO delegation method was that we felt there were important cases that were not necessarily addressed by requiring the DHCPv6-based method. Since the group originally decided to do both, it will require further input to determine what's the best course of action. That is input that, unfortunately, I was not able to tease out of the participants so far. Maybe that will be different in Vancouver. TJ > > hence, my question to the wg. > > is this clearer now? > > Regards, marcelo > > > _______________________________________________ > 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 Mon Nov 26 02:35:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwYUk-00064l-2R; Mon, 26 Nov 2007 02:35:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwYUi-0005zi-UO for mext@ietf.org; Mon, 26 Nov 2007 02:35:04 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwYUb-0005Vc-OH for mext@ietf.org; Mon, 26 Nov 2007 02:35:04 -0500 X-IronPort-AV: E=Sophos;i="4.21,465,1188770400"; d="scan'208";a="158732130" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2007 08:34:55 +0100 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 lAQ7YtHP024398; Mon, 26 Nov 2007 08:34:55 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAQ7YpZZ005428; Mon, 26 Nov 2007 07:34:51 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 08:34:50 +0100 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: [MEXT] Next steps on prefix delegation Date: Mon, 26 Nov 2007 08:34:07 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04D3D97C@xmb-ams-337.emea.cisco.com> In-Reply-To: <474A74D3.30205@kniveton.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Next steps on prefix delegation Thread-Index: Acgv/b6kQ9NIXyeIQVCK5ZQwmM/RBwAACA3A References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es><4749758D.6070003@gmail.com><38649A85-AA08-4CCC-8525-97CD86C6940C@it.uc3m.es><47497AC7.30007@gmail.com><47E1FC5E-BC3A-4C96-9D11-2055FB00F074@it.uc3m.es> <474A74D3.30205@kniveton.com> From: "Pascal Thubert (pthubert)" To: "T.J. Kniveton" , "marcelo bagnulo braun" X-OriginalArrivalTime: 26 Nov 2007 07:34:50.0976 (UTC) FILETIME=[D4483600:01C82FFE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2567; t=1196062495; x=1196926495; 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[MEXT]=20Next=20steps=20on=20prefix=20delegation |Sender:=20; bh=7LovqVmrBeAhu5z92Rkgi6qvByGwIPXaReguFz2Qs0o=; b=hNsm8NqxOt8yZTKNSCRWYmdhzh6AmW8S864vZliCgCwVVdbcDGcmt2umFpcdoGpk3Yz/9MZ+ mAR+YAwtwitDLa+Mv2WFtGC96WqRKTQUABWQN73zj9yD92PN1WJu2pnJ; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Right: Please note that draft-ietf-nemo-prefix-delegation came after the DHCP-PD work.=20 So we had to explain why we did this and were prepare to get the question over again.=20 This is why the document has strong requirement and rationale sections (3 and 4).=20 In particular, please have a look at: "4.4. Why not Alternate standard based solutions? " Note also that the draft does not prevent using DHCP-PD in the back end. In fact, that is recommended. What the draft does is enable the HA to proxy the PD just the way it proxies the ND. This saves exchanges, makes flows simpler, and maintains back end states when the MR is not reachable.=20 Pascal >-----Original Message----- >From: T.J. Kniveton [mailto:tj@kniveton.com] >Sent: Monday, November 26, 2007 8:25 AM >To: marcelo bagnulo braun >Cc: mext@ietf.org >Subject: Re: [MEXT] Next steps on prefix delegation > >marcelo bagnulo braun wrote: >> >> It may be the case that we come to the conclusion that we need more >> than one solution based on technical considerations, such as (for >> example) that the different approaches work in different scenarios and >> there is not a single approach that works for all the scenarios that >> we deem necessary to support. However, we must be convinced that this >> is the case and i don't think we are there yet. > >Yes, it is the case that the two solutions are based on different >technical considerations, and that they work in different scenarios. >They have different properties, and require different levels of >implementation complexity to achieve them. Making an informed decision >would require understanding these trade-offs, ideally by implementing >one or both. The reason that Pascal and I wrote the NEMO delegation >method was that we felt there were important cases that were not >necessarily addressed by requiring the DHCPv6-based method. > >Since the group originally decided to do both, it will require further >input to determine what's the best course of action. That is input that, >unfortunately, I was not able to tease out of the participants so far. >Maybe that will be different in Vancouver. > >TJ >> >> hence, my question to the wg. >> >> is this clearer now? >> >> Regards, marcelo >> >> >> _______________________________________________ >> 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 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 03:16: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 1IwZ9A-0007Rv-Bb; Mon, 26 Nov 2007 03:16:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwZ98-0007Qx-Rk for mext@ietf.org; Mon, 26 Nov 2007 03:16:50 -0500 Received: from rv-out-0910.google.com ([209.85.198.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwZ8y-0006bp-9Z for mext@ietf.org; Mon, 26 Nov 2007 03:16:50 -0500 Received: by rv-out-0910.google.com with SMTP id l15so444145rvb for ; Mon, 26 Nov 2007 00:16:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=0SSwdXyLNoHVFxFv+gMfzWftZXfTP1xd7KLlyP9og9k=; b=tBfY5r82rWU107f37rIXGGxtQHGRFXpv+z5liaiq7ar/QLDQ2w+l44ogO6BPg7AGkbIUoq/C1xc4T7fe9pNEgf6qIqiFWQbEy9Cq7Ym1P7qBgPaaOctwTQ1ui/7hhxq2wha07UrXTFndIMsO+gTcNPSHzWSZ8tC+JeK9JUhb2Sk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=hkI6p3w8vrf0J9cLd05rz820+PqLH2N6hZGHNdjf/nLzcS0FVhfQaDYqGQhZdvqtvtc6ZXmahUfuf39auCod0dClGyOQbTJ8KOUwz8CWTzceWc7OxpHTSpV20vdkXDVHC9mibJB2rKpfnrUEAkL7YFQ2qFew/bFtFtwkpxrDs10= Received: by 10.141.161.6 with SMTP id n6mr976120rvo.1196064999645; Mon, 26 Nov 2007 00:16:39 -0800 (PST) Received: by 10.140.135.15 with HTTP; Mon, 26 Nov 2007 00:16:39 -0800 (PST) Message-ID: Date: Mon, 26 Nov 2007 08:16:39 +0000 From: "George Tsirtsis" To: "Sri Gundavelli" Subject: Re: [MEXT] MEXT charter In-Reply-To: <022701c82d42$a85d5700$1220fea9@amer.cisco.com> MIME-Version: 1.0 References: <47420EC7.80606@piuha.net> <022701c82d42$a85d5700$1220fea9@amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d9aaf4f837d0910b987cb9188300fdd Cc: Julien Laganier , 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="===============0656873448==" Errors-To: mext-bounces@ietf.org --===============0656873448== Content-Type: multipart/alternative; boundary="----=_Part_19187_29278989.1196064999615" ------=_Part_19187_29278989.1196064999615 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Sri, According to this draft the sender of the notification message can resend the notification if it sets the A flag and does not receive an ack. This is correctly defined as a MAY, but I think some language should also be added WRT the fact that lack of acknowledgement could also mean that the receiver does not support generic notifications as all; or is some other behavior expected in such a case? Thanks George On 11/22/07, Sri Gundavelli wrote: > > This is a WG document and I thought this was in the charter and does > not require a charter update. > > > https://www.ietf.org/internet-drafts/draft-ietf-mip6-generic-notification-me > ssage-00.txt > > > Sri > > > > -----Original Message----- > > From: Jari Arkko [mailto:jari.arkko@piuha.net] > > Sent: Monday, November 19, 2007 2:32 PM > > To: mext@ietf.org > > Subject: [MEXT] MEXT charter > > > > > > The charter that I sent to the secretary is shown below. I've > > updated the milestones plus taken some of the editorial > > comments from Thierry and Nicolas into account. However, > > I did not want to make any bigger changes due to the discussion > > we had with them in Chicago, because that would require a > > new IESG approval. But I note that given the interest for > > binding revocation, a charter update will probably be > > needed soon anyway. We can take care of remaining issues > > there. > > > > ---- > > > > Mobility EXTensions for IPv6 (MEXT) > > > > > > 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, network mobility (NEMO) 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 (Mobile IPv6) > > o RFC 3963 (NEMO) > > o RFC 4877 (Mobile IPv6 Operation with IKEv2) > > > > The MEXT Working Group continues the work of the former 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 Mobile IPv6 and NEMO 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 Mobile IPv6 or NEMO capable dual-stack hosts. > > > > (A.2) A protocol based solution for enhancing the reliability of home > > agents and a method to force a host/router 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: > > > > Done Submit I-D 'Mobile IPv6 Vendor Specific Option' > > to IESG for > > publication as a Proposed Standard > > Done Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG > > for publication as a Proposed Standard. > > Done Submit I-D 'Mobility Header Home Agent Switch Message' to > > IESG for publication as a Proposed Standard. > > > > Dec 2007 Submit Multiple CoA Registration to IESG > > Dec 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for > > publication as Informational. > > Dec 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for > > publication as a Proposed Standard. > > > > Feb 2008 Submit -00 draft on Route Optimization Needs for Aircraft > > and Spacecraft Deployments > > Feb 2008 Submit -00 draft on Route Optimization Needs for > > Automobile > > and Highway Deployments > > Feb 2008 Submit -00 draft on Route Optimization needs for Personal > > Mobile Router > > Feb 2008 Submit I-D 'Goals for AAA HA Interface' to IESG for > > publication as Informational. > > > > Mar 2008 Submit the final doc on Prefix Delegation for NEMO to the > > IESG, for Proposed Standard > > > > May 2008 Submit -00 draft for solution to > > aircraft/spacecraft problem > > May 2008 Submit final doc on Route Optimization Needs for Aircraft > > and Spacecraft Deployments, for Informational > > May 2008 Submit final doc on Route Optimization Needs for > > Automobile > > and Highway Deployments, for Informational > > May 2008 Submit final doc on Route Optimization needs for Personal > > Mobile Router, for Informational > > > > Jun 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for > > publication as a proposed standard. > > Jun 2008 Determine how to proceed with 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 the final doc on MIB for NEMO Basic Support to the > > IESG, for Proposed Standard > > Aug 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG > > for publication as Informational. > > > > Oct 2008 Submit Flow/binding policy format to IESG, for > > Proposed Standard > > Oct 2008 Submit Flow/binding policy transport to IESG, for Proposed > > Standard > > > > Nov 2008 Submit final doc for solution to > > aircraft/spacecraft problem > > to the IESG, for Proposed Standard > > Nov 2008 Recharter to work on the remaining automotive/Personal > > Mobile Router solutions > > > > Dec 2008 Submit I-D(s) related to specific updates and > > corrections of > > RFC 3775 to IESG for publication as Proposed Standard. > > Dec 2008 Submit I-D 'Home agent reliability' to IESG for > > publication > > as a Proposed Standard. > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > ------=_Part_19187_29278989.1196064999615 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Sri,
 
According to this draft the sender of the notification message can resend the notification if it sets the A flag and does not receive an ack. This is correctly defined as a MAY, but I think some language should also be added WRT the fact that lack of acknowledgement could also mean that the receiver does not support generic notifications as all; or is some other behavior expected in such a case?
 
Thanks
George

 
On 11/22/07, Sri Gundavelli <sgundave@cisco.com> wrote:
This is a WG document and I thought this was in the charter and does
not require a charter update.

https://www.ietf.org/internet-drafts/draft-ietf-mip6-generic-notification-me
ssage-00.txt


Sri


> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]
> Sent: Monday, November 19, 2007 2:32 PM
> To: mext@ietf.org
> Subject: [MEXT] MEXT charter
>
>
> The charter that I sent to the secretary is shown below. I've
> updated the milestones plus taken some of the editorial
> comments from Thierry and Nicolas into account. However,
> I did not want to make any bigger changes due to the discussion
> we had with them in Chicago, because that would require a
> new IESG approval. But I note that given the interest for
> binding revocation, a charter update will probably be
> needed soon anyway. We can take care of remaining issues
> there.
>
> ----
>
> Mobility EXTensions for IPv6 (MEXT)
>
>
> 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, network mobility (NEMO) 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 (Mobile IPv6)
> o RFC 3963 (NEMO)
> o RFC 4877 (Mobile IPv6 Operation with IKEv2)
>
> The MEXT Working Group continues the work of the former 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 Mobile IPv6 and NEMO 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 Mobile IPv6 or NEMO capable dual-stack hosts.
>
> (A.2) A protocol based solution for enhancing the reliability of home
>       agents and a method to force a host/router 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:
>
> Done        Submit I-D 'Mobile IPv6 Vendor Specific Option'
> to IESG for
> publication as a Proposed Standard
> Done        Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG
> for publication as a Proposed Standard.
> Done        Submit I-D 'Mobility Header Home Agent Switch Message' to
> IESG for publication as a Proposed Standard.
>
> Dec 2007    Submit Multiple CoA Registration to IESG
> Dec 2007    Submit I-D 'Motivation for Authentication I-D' to IESG for
> publication as Informational.
> Dec 2007    Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for
> publication as a Proposed Standard.
>
> Feb 2008    Submit -00 draft on Route Optimization Needs for Aircraft
> and Spacecraft Deployments
> Feb 2008    Submit -00 draft on Route Optimization Needs for
> Automobile
> and Highway Deployments
> Feb 2008    Submit -00 draft on Route Optimization needs for Personal
> Mobile Router
> Feb 2008    Submit I-D 'Goals for AAA HA Interface' to IESG for
> publication as Informational.
>
> Mar 2008    Submit the final doc on Prefix Delegation for NEMO to the
> IESG, for Proposed Standard
>
> May 2008    Submit -00 draft for solution to
> aircraft/spacecraft problem
> May 2008    Submit final doc on Route Optimization Needs for Aircraft
> and Spacecraft Deployments, for Informational
> May 2008    Submit final doc on Route Optimization Needs for
> Automobile
> and Highway Deployments, for Informational
> May 2008    Submit final doc on Route Optimization needs for Personal
> Mobile Router, for Informational
>
> Jun 2008    Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for
> publication as a proposed standard.
> Jun 2008    Determine how to proceed with 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 the final doc on MIB for NEMO Basic Support to the
> IESG, for Proposed Standard
> Aug 2008    Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG
> for publication as Informational.
>
> Oct 2008    Submit Flow/binding policy format to IESG, for
> Proposed Standard
> Oct 2008    Submit Flow/binding policy transport to IESG, for Proposed
> Standard
>
> Nov 2008    Submit final doc for solution to
> aircraft/spacecraft problem
> to the IESG, for Proposed Standard
> Nov 2008    Recharter to work on the remaining automotive/Personal
> Mobile Router solutions
>
> Dec 2008    Submit I-D(s) related to specific updates and
> corrections of
> RFC 3775 to IESG for publication as Proposed Standard.
> Dec 2008    Submit I-D 'Home agent reliability' to IESG for
> publication
> as a Proposed Standard.
>
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www1.ietf.org/mailman/listinfo/mext

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

------=_Part_19187_29278989.1196064999615-- --===============0656873448== 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 --===============0656873448==-- From mext-bounces@ietf.org Mon Nov 26 03:33: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 1IwZOv-0003DM-LX; Mon, 26 Nov 2007 03:33:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwZOt-00037n-WB for mext@ietf.org; Mon, 26 Nov 2007 03:33:08 -0500 Received: from rv-out-0910.google.com ([209.85.198.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwZOm-00070q-BJ for mext@ietf.org; Mon, 26 Nov 2007 03:33:07 -0500 Received: by rv-out-0910.google.com with SMTP id l15so446848rvb for ; Mon, 26 Nov 2007 00:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=abLX5C3UOfRnvxezkCQlauUUeKbynKghM6QZSg8d7qY=; b=BS+NE9GHHRVQ8xhi35b7mwbrOXvW9RWVLTkhWoMlBwf5rtNgVQOWJmlGoVaTd9y4nr8QmEeXHKrsF39IPVEKJpMtlsrJdKU05YpOJ6JE8WXuYko7NxuKhPJcyhinZKdhmRzslEt2+TaikRv9qzMr0L2Lsfdb7ksqk1fP2Aw24Zg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ikORTtcQF9U9IiTxCbjZkzXEDeN4TsIsm/lo0zRcSSnlwpVcxLRF5LN+KF5UwbAqFyEemxmYeski383NODgfU3PJ55hRrD7UTRkWCWRUuVKZF7mx+HA01X82+Uym5zKl8qDz21Lf+vfafWmJ1R9/AXeP9aTUrjpSTI3l5pB0CEE= Received: by 10.141.87.13 with SMTP id p13mr980955rvl.1196065979861; Mon, 26 Nov 2007 00:32:59 -0800 (PST) Received: by 10.140.135.15 with HTTP; Mon, 26 Nov 2007 00:32:59 -0800 (PST) Message-ID: Date: Mon, 26 Nov 2007 08:32:59 +0000 From: "George Tsirtsis" To: "marcelo bagnulo braun" Subject: Re: Potential recharter items (was Re: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps In-Reply-To: <93960661-DB67-4A94-89FE-AA48EF1DC7D9@it.uc3m.es> MIME-Version: 1.0 References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <93960661-DB67-4A94-89FE-AA48EF1DC7D9@it.uc3m.es> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: mext@ietf.org, Vijay Devarapalli , Julien Laganier 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="===============1264082966==" Errors-To: mext-bounces@ietf.org --===============1264082966== Content-Type: multipart/alternative; boundary="----=_Part_19236_17376185.1196065979849" ------=_Part_19236_17376185.1196065979849 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Marcelo/Vijay, I would prefer not to take this up as a WG document. The draft adds functionality to a mechanism that is known to be problematic, while a bette= r alternative exists and is already specified. If someone needs this to be documented then maybe it can be progressed as an AD sponsored RFC, but IMO it is not worth the full attention of the WG. Note that the above is not critisism on the quality of the specific draft, but rather based on the simple fact that we have already defined an overal mechanism with better security for bootstrapping and securing MIPv6, and it would be good for the IETF to be providing the market with clear signals once in a while ;-) Regards George On 11/24/07, marcelo bagnulo braun wrote: > > Hi Vijay, > > El 24/11/2007, a las 18:24, Vijay Devarapalli escribi=F3: > > > > > > draft-devarapalli-mip6-authprotocol-bootstrap - There is an > > ongoing consensus(?) call to make this a WG document. Not sure > > if it is actually a consensus call. Something about gauging > > interest. :) > > > > this should be included in the rechartering discussion, what other > people feel about including this item in the recharter? > > > 4283bis - There is no draft on this yet, but a need to update > > 4283 was identified on the NETLMM mailing list and then > > discussed later on the mext mailing list. The update is to > > mainly include other subtypes for MN identifier. For example, > > the MAC address would be the new subtype. Currently the > > document only defines NAI. > > > > same thing here, this should be included in the rechartering > discussion, what other people feel about including this item in the > recharter? > > Regards, marcelo > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > ------=_Part_19236_17376185.1196065979849 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Marcelo/Vijay,
 
I would prefer not to take this up as a WG document. The draft adds fu= nctionality to a mechanism that is known to be problematic, while a better = alternative exists and is already specified. If someone needs this to be do= cumented then maybe it can be progressed as an AD sponsored RFC, but IMO it= is not worth the full attention of the WG.=20
 
Note that the above is not critisism on the quality of the specific dr= aft, but rather based on the simple fact that we have already defined an ov= eral mechanism with better security for bootstrapping and securing MIPv6, a= nd it would be good for the IETF to be providing the market with clear sign= als once in a while ;-)=20
 
Regards
George

 
On 11/24/07, marcelo bagnulo braun <marcel= o@it.uc3m.es > wrote:=20
Hi Vijay,

El 24/11/2007, = a las 18:24, Vijay Devarapalli escribi=F3:




> draft-de= varapalli-mip6-authprotocol-bootstrap - There is an=20
> ongoing consensus(?) call to make this a WG document. Not sure
= > if it is actually a consensus call. Something about gauging
> in= terest. :)
>

this should be included in the rechartering discu= ssion, what other=20
people feel about including this item in the recharter?

> 428= 3bis - There is no draft on this yet, but a need to update
> 4283 was= identified on the NETLMM mailing list and then
> discussed later on = the mext mailing list. The update is to=20
> mainly include other subtypes for MN identifier. For example,
&= gt; the MAC address would be the new subtype. Currently the
> documen= t only defines NAI.
>

same thing here, this should be included= in the rechartering=20
discussion, what other people feel about including this item in the
= recharter?

Regards, marcelo




_____________________= __________________________
MEXT mailing list
MEXT@ietf.org
https://www1.ietf.org/mailman/listinfo/mext
------=_Part_19236_17376185.1196065979849-- --===============1264082966== 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 --===============1264082966==-- From mext-bounces@ietf.org Mon Nov 26 04:01: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 1IwZqZ-0002lY-9F; Mon, 26 Nov 2007 04:01:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwZqX-0002lT-IR for mext@ietf.org; Mon, 26 Nov 2007 04:01:41 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwZqQ-0007uP-TV for mext@ietf.org; Mon, 26 Nov 2007 04:01:41 -0500 Received: (qmail 32034 invoked from network); 26 Nov 2007 10:01:33 +0100 Received: from unknown (HELO M90Teco) (217.169.232.211) by server9.hosting2go.nl with SMTP; 26 Nov 2007 10:01:32 +0100 From: "Teco Boot" To: References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> In-Reply-To: Date: Mon, 26 Nov 2007 10:00:57 +0100 Message-ID: <007f01c8300a$ee331330$ca993990$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcguxKLO6rD3815GTXqvm1YoLDazzABRMmIA Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [MEXT] RSVP TSPEC for flow-distribution-rules 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 > > Finally, what happened to > > draft-mitsuya-monami6-flow-distribution-policy-04.txt. I > > thought this was also going to be adopted as a MONAMI6 WG > > document. I might have missed some emails. > > There are two documents about flow distribution languages documents. > - draft-mitsuya-monami6-flow-distribution-policy-04.txt > - draft-larsson-monami6-filter-rules-02.txt > > We agreed to merge the two documents and > published draft-larsson-mext-flow-distribution-rules-00.txt > I suggested to check using RSVP TSPEC for flow-distribution-rules before. This has similar functionality and integration with upper layers could be more straightforward. I'm afraid I don't have time to work out this idea. I would appreciate someone picks up. Teco. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 04:12: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 1Iwa0o-00031R-0Z; Mon, 26 Nov 2007 04:12:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwa0n-00031M-3V for mext@ietf.org; Mon, 26 Nov 2007 04:12:17 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iwa0g-0008Gx-Dp for mext@ietf.org; Mon, 26 Nov 2007 04:12:17 -0500 Received: (qmail invoked by alias); 26 Nov 2007 09:12:09 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp033) with SMTP; 26 Nov 2007 10:12:09 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+2ARlTnJm2mcmgCAq02/Y8Jncphkci+liP2h0Ixn Bfn6eJuuhlZxic Message-ID: <474A8DE7.5030203@gmx.net> Date: Mon, 26 Nov 2007 10:12:07 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> In-Reply-To: <007f01c8300a$ee331330$ca993990$@nl> 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: e1e48a527f609d1be2bc8d8a70eb76cb 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 Teco, Teco Boot wrote: >>> Finally, what happened to >>> draft-mitsuya-monami6-flow-distribution-policy-04.txt. I >>> thought this was also going to be adopted as a MONAMI6 WG >>> document. I might have missed some emails. >>> >> There are two documents about flow distribution languages documents. >> - draft-mitsuya-monami6-flow-distribution-policy-04.txt >> - draft-larsson-monami6-filter-rules-02.txt >> >> We agreed to merge the two documents and >> published draft-larsson-mext-flow-distribution-rules-00.txt >> >> > > I suggested to check using RSVP TSPEC for flow-distribution-rules before. > This has similar functionality and integration with upper layers could be > more straightforward. > I'm afraid I don't have time to work out this idea. I would appreciate > someone picks up. > Are you suggesting to use RSVP for signaling the packet filters? Or: Are you suggesting to look at the packet formats for describing the traffic filters? Ciao Hannes > Teco. > > > > _______________________________________________ > 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 Mon Nov 26 04:30:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwaHs-0008JZ-Sh; Mon, 26 Nov 2007 04:29:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwaHp-000847-Ar for mext@ietf.org; Mon, 26 Nov 2007 04:29:53 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IwaHi-0000Ek-3e for mext@ietf.org; Mon, 26 Nov 2007 04:29:53 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-119.messagelabs.com!1196069385!27229535!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 23604 invoked from network); 26 Nov 2007 09:29:45 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-119.messagelabs.com with SMTP; 26 Nov 2007 09:29:45 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAQ9TeI6018865; Mon, 26 Nov 2007 02:29:40 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id lAQ9TepM001629; Mon, 26 Nov 2007 03:29:40 -0600 (CST) Received: from [127.0.0.1] (WSLPTGBWI0010BD.ea.mot.com [10.161.194.37]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id lAQ9TcrS001594; Mon, 26 Nov 2007 03:29:38 -0600 (CST) Message-ID: <474A9202.1060007@gmail.com> Date: Mon, 26 Nov 2007 10:29:38 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: less messages (was: [MEXT] Prefix Delegation documents) References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> <47446BCB.5000000@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D35D@xmb-ams-337.emea.cisco.com> <4745B84B.6070002@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D392@xmb-ams-337.emea.cisco.com> <4745D5D5.10905@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04D3D90B@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04D3D90B@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071124-0, 24/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Vijay Devarapalli , 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 Pascal Thubert (pthubert) wrote: > Hi Alex: > > It will run what's necessary and standard :) delegation within NEMO > enables a tighter coupling and dependency management, and less > messages. Less messages is something good to do. In some cases if the DNS Server is within the moving network then there'll be less DNS query messages exchanged over the MR-HA tunnel. There'll be much reuse from the DNS cache. Having the DNS Server in the moving network can be achieved either by taking advantage of DHCP Client or Server updating the DNS, or by extending MIP6 HA to update the DNS, or simply by the MR updating the DNS with DNS UPDATE (the update should include the DNS Server's address in the moving network.) The existing open source software I'm aware that could do this is part of DHCP Server, but anything else could do. They have different requirements, technically different solutions. But it's good to reduce the number of messages. Alex > > Pascal > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, November 22, >> 2007 8:18 PM To: Pascal Thubert (pthubert) Cc: Vijay Devarapalli; >> Teco Boot; mext@ietf.org Subject: Re: [MEXT] Prefix Delegation >> documents >> >> Salut Pascal, >> >> Pascal Thubert (pthubert) wrote: >>> Hi Alex: >>> >>> There are actually examples where a short time lease is just >>> what's needed. It's good for privacy and a number of other >>> reasons like getting a prefix that is topologically correct >>> not-too-far. >> I can agree that that there are scenarios where short time leases >> of a prefix allocated by DHCP to a Mobile Router make sense. A >> user PAN is an example. (a larger entity as a ship doing on2ly 2-3 >> handovers > during >> a transatlantic cruise probably needs more lease time). >> >> I wanted to say that there are also scenarios where prefixes >> allocated to a moving network are longer term, and the MR-HA tunnel >> being down shouldn't mean that that prefix is no longer used in >> that ship. >> >>> One of those examples is that of a MR visiting a MANET and >>> getting a local prefix for activity within that MANET that is >>> topologically correct in the area (AUTOCONF) and from which the >>> MR can form a CoA that it can keep as it moves around. >> Somehow yes, I agree with you Mobile Router visiting a MANET and > getting >> a 'local' prefix (but still 'global' topologically correct) from it >> it will probably be short-lived. >> >>> Using NEMO to get the prefix enables the mobility of the >>> delegated prefix in and out the MANET - using or not the MANET >>> protocol while in the MANET space - till the MR finds that the >>> prefix is useless and forgets about it all. >> In order for the MANET network to deliver prefixes to visitors, do >> you think a MANET network is more likely to run a HA inside or a >> DHCPv6 Server? (my Windows Mobile PDA runs DHCPv4 Server, to not >> name a manufacturer). >> >> Alex >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 04:38:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwaPy-0007I3-TI; Mon, 26 Nov 2007 04:38:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwaPx-0007Hq-OR for mext@ietf.org; Mon, 26 Nov 2007 04:38:17 -0500 Received: from smtp01.uc3m.es ([163.117.176.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwaPp-0000TT-BT for mext@ietf.org; Mon, 26 Nov 2007 04:38:17 -0500 Received: from [163.117.139.227] (unknown [163.117.139.227])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp01.uc3m.es (Postfix) with ESMTP id 32B5E2516C4;Mon, 26 Nov 2007 10:38:08 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <7B0B8530-53B3-4F05-9B37-E6722EE1C2A4@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps Date: Mon, 26 Nov 2007 10:38:08 +0100 To: "Giaretta, Gerardo" X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-19.5062 TC:1F TRN:57 TV:5.0.1023(15568.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -1.9 (-) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: Julien Laganier , Vijay Devarapalli , 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 Gerardo, thanks for taking care of this. Please submit the new draft right =20 after vancouver meeting. We are requested to submit the document to =20 the IESG for february and i guess we should allow people to comment =20 on the new version. Regards, marcelo El 26/11/2007, a las 2:20, Giaretta, Gerardo escribi=F3: > Hi Marcelo and Vijay, > > draft-ietf-mip6-aaa-ha-goals needs an update after the WGLC in MIP6. A > revision will be available after the Vancouver IETF meeting. > > Thanks > Gerardo > > -----Original Message----- > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com] > Sent: Saturday, November 24, 2007 9:24 AM > To: marcelo bagnulo braun; mext@ietf.org > Cc: Julien Laganier > Subject: RE: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps > > Marcelo, > > The following drafts are missing. > > draft-ietf-mip6-aaa-ha-goals - I think this document completed > MIP6 WG last call. It is currently expired. > > draft-devarapalli-mip6-authprotocol-bootstrap - There is an > ongoing consensus(?) call to make this a WG document. Not sure > if it is actually a consensus call. Something about gauging > interest. :) > > 4283bis - There is no draft on this yet, but a need to update > 4283 was identified on the NETLMM mailing list and then > discussed later on the mext mailing list. The update is to > mainly include other subtypes for MN identifier. For example, > the MAC address would be the new subtype. Currently the > document only defines NAI. > > Finally, what happened to > draft-mitsuya-monami6-flow-distribution-policy-04.txt. I > thought this was also going to be adopted as a MONAMI6 WG > document. I might have missed some emails. > > Vijay > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Friday, November 23, 2007 6:10 AM >> To: mext@ietf.org >> Subject: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps >> >> Folks, >> >> We have been discussing with our AD the way forward w.r.t. WG >> drafts inherited from the previous WGs (MIP6, NEMO and MONAMI6). >> >> We have grouped drafts into five categories and decided about >> the actions to be taken for drafts of each category: >> >> --------------------------------------------------------------------- >> >> Cat. I: former WG drafts submitted to IESG already >> >> Action: Address possible IESG Comments/Discusses as they surface. >> >> I-Ds: draft-ietf-mip6-bootstrapping-integrated-dhc-05 >> draft-ietf-mip6-cn-ipsec-06 >> draft-ietf-mip6-ha-switch-05 >> draft-ietf-mip6-hiopt-08 >> draft-ietf-mip6-whyauthdataoption-04 >> draft-ietf-mip6-experimental-messages-03 >> draft-ietf-mip6-vsm-03 >> >> ---------------------------------------------------------------------=20= >> - >> >> Cat. II: former WG drafts corresponding to MEXT charter work items >> >> Action: - MEXT to adopt drafts as WG drafts >> - authors to submit new versions if/when needed as >> draft- ietf-mext-... >> >> I-Ds (MEXT work item): draft-ietf-nemo-mib-03 work item (B.3) >> draft-ietf-nemo-prefix-delegation-02 (B.3) >> draft-ietf-monami6-mipv6-analysis-04 (A.3) >> =09 >> draft-ietf-monami6-multihoming-motivation-scenario-02 (A.3) >> draft-ietf-monami6-multiplecoa-04 (A.3) >> draft-ietf-mip6-hareliability-03 (A.2) >> draft-ietf-mip6-nemo-v4traversal-05 (A.1) >> draft-ietf-mip6-radius-02 (A.6) >> >> ---------------------------------------------------------------------=20= >> - >> >> Cat. III: individual drafts corresponding to MEXT charter work items >> that were accepted as former WG drafts but never >> submitted as such. >> >> Action: - MEXT to adopt drafts as WG drafts as long as the >> authors follow the >> conditions requested by the respective WG at the >> moment of acceptancy >> - authors to submit new versions if/when needed as >> draft- ietf-mext-... >> >> I-Ds (MEXT work item): draft-eddy-nemo-aero-reqs-01 (A.5) >> draft-soliman-monami6-flow-binding-04 (A.3) >> >> ---------------------------------------------------------------------=20= >> - >> >> Cat. IV: individual drafts corresponding to MEXT charter work items >> that were *conditionally* accepted as former WG drafts. >> >> Action: - authors to update drafts so that they fullfills conditions. >> >> I-Ds (MEXT work item): draft-baldessari-c2ccc-nemo-req-01 (A.5) >> >> ---------------------------------------------------------------------=20= >> - >> >> Cat. V: former WG drafts without corresponding MEXT charter work item >> >> Action: - MEXT to include this drafts as part of the rechartering >> discussion. >> >> I-Ds: draft-ietf-mip6-rfc4285bis-01 >> draft-ietf-mip6-generic-notification-message-00 >> >> -------------------------------------------------------------- >> ---------- >> >> Comments? >> >> Cheers, >> >> -- >> Julien and Marcelo, MEXT chairs >> >> >> _______________________________________________ >> 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 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 05:01: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 1IwamT-0008Ou-8b; Mon, 26 Nov 2007 05:01:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwamR-0008Op-Eq for mext@ietf.org; Mon, 26 Nov 2007 05:01:31 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwamL-00011q-U5 for mext@ietf.org; Mon, 26 Nov 2007 05:01:31 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 4E0AF28000350; Mon, 26 Nov 2007 11:01:25 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gicpaDss90Uu; Mon, 26 Nov 2007 11:01:25 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3AD2728000303; Mon, 26 Nov 2007 11:01:15 +0100 (CET) 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: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps Date: Mon, 26 Nov 2007 11:01:14 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF317C5B@mx1.office> In-Reply-To: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps Thread-Index: Acgt23oAJn/DO0SmTdKKzziAksWQWgCNrFmA From: "Roberto Baldessari" To: "marcelo bagnulo braun" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 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 Marcelo, > ---------------------------------------------------------------------- >=20 > Cat. IV: individual drafts corresponding to MEXT charter work items > that were *conditionally* accepted as former WG drafts. >=20 > Action: - authors to update drafts so that they fullfills conditions. >=20 > I-Ds (MEXT work item): draft-baldessari-c2ccc-nemo-req-01 (A.5) >=20 > ---------------------------------------------------------------------- For automotive requirements, we did not make it in time to submit a = joint C2C-CC/CALM ID for Vancouver. Anyway, Thierry and I are working on = it. Thierry will also be in Vancouver.=20 As suggested from the feedback in Chicago, we are moving from = draft-baldessari-c2ccc-nemo-req-01 to something like = draft-mext-nemo-ro-automotive-req-00, which will represent both C2C-CC = and ISO CALM.=20 Thanks, Roberto _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 05:15: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 1Iwazx-00034j-JR; Mon, 26 Nov 2007 05:15:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwazw-00034d-CS for mext@ietf.org; Mon, 26 Nov 2007 05:15:28 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwazo-0001MH-QN for mext@ietf.org; Mon, 26 Nov 2007 05:15:28 -0500 Received: from [163.117.139.227] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.227])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp02.uc3m.es (Postfix) with ESMTP id 165B7268F62;Mon, 26 Nov 2007 11:15:20 +0100 (CET) In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF317C5B@mx1.office> References: <5F6519BF2DE0404D99B7C75607FF76FF317C5B@mx1.office> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <9ADBA154-C271-4460-95E2-8E4FF908BBEB@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps Date: Mon, 26 Nov 2007 11:15:20 +0100 To: "Roberto Baldessari" X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-14.1048 TC:1F TRN:19 TV:5.0.1023(15568.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -1.9 (-) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 good, the only difference is that it should be draft-ietf-mext-ro-=20 automotive-req-00 El 26/11/2007, a las 11:01, Roberto Baldessari escribi=F3: > Hi Marcelo, > > >> ---------------------------------------------------------------------=20= >> - >> >> Cat. IV: individual drafts corresponding to MEXT charter work items >> that were *conditionally* accepted as former WG drafts. >> >> Action: - authors to update drafts so that they fullfills conditions. >> >> I-Ds (MEXT work item): draft-baldessari-c2ccc-nemo-req-01 (A.5) >> >> ---------------------------------------------------------------------=20= >> - > > For automotive requirements, we did not make it in time to submit a =20= > joint C2C-CC/CALM ID for Vancouver. Anyway, Thierry and I are =20 > working on it. Thierry will also be in Vancouver. > As suggested from the feedback in Chicago, we are moving from draft-=20= > baldessari-c2ccc-nemo-req-01 to something like draft-mext-nemo-ro-=20 > automotive-req-00, which will represent both C2C-CC and ISO CALM. > > Thanks, > > Roberto > > _______________________________________________ > 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 ds-Stokell@ifsol.co.uk Mon Nov 26 07:22:46 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwcz7-0000jZ-TR for nemo-archive@lists.ietf.org; Mon, 26 Nov 2007 07:22:45 -0500 Received: from cable-38-28.roman.airbites.ro ([89.32.38.28]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwcz7-0007E1-1b for nemo-archive@lists.ietf.org; Mon, 26 Nov 2007 07:22:45 -0500 Received: by 10.41.230.158 with SMTP id pPEYxoNPmGBIH; Mon, 26 Nov 2007 14:22:50 -0000 (GMT) Received: by 192.168.206.157 with SMTP id LGrbpxfZRajfjZ.5047670220942; Mon, 26 Nov 2007 14:22:48 -0000 (GMT) Message-ID: <000501c83037$d03751c0$1c262059@75c74c5a8508421> From: "ds Stokell" To: Subject: bykatad Date: Mon, 26 Nov 2007 14:22:45 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C83037.D03751C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a ------=_NextPart_000_0005_01C83037.D03751C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable order today and get your Rolex delivered in time for christmas = http://www.tcinglar.com/ ------=_NextPart_000_0005_01C83037.D03751C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
order today and get your Rolex delivered in = time for=20 christmas http://www.tcinglar.com/
------=_NextPart_000_0005_01C83037.D03751C0-- From mext-bounces@ietf.org Mon Nov 26 07:53: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 1IwdS5-00082C-4D; Mon, 26 Nov 2007 07:52:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwdS4-000827-DR for mext@ietf.org; Mon, 26 Nov 2007 07:52:40 -0500 Received: from mout.perfora.net ([74.208.4.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwdS4-0007o4-0k for mext@ietf.org; Mon, 26 Nov 2007 07:52:40 -0500 Received: from IBM52A5038A94F ([121.136.51.146]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1IwdRx2OQq-0008Gc; Mon, 26 Nov 2007 07:52:38 -0500 From: "Alper Yegin" To: "'Vijay Devarapalli'" , "'Hannes Tschofenig'" Subject: RE: [MEXT] Prefix delegation & Diameter Interaction Date: Mon, 26 Nov 2007 14:52:30 +0200 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: AcgvhvmdZq21mVoZTZOIiZ82t/f3aAApBedg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4749ADFB.8010807@azairenet.com> Message-Id: <0MKp8S-1IwdRx2OQq-0008Gc@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/lJKhXSoPAEOcA8hF3ruQJWuW808DaL4RVTz3 8BdMXV5YCjXJZVGYx6mQlXmLqcx0DVWEGXnWlncxkQV7BZDkfT cl9vEVdEgWA2PyUhwOwvw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Vijay, Can you explain why you do not recommend AAA-assignment of prefixes? Alper > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Sunday, November 25, 2007 7:17 PM > To: Hannes Tschofenig > Cc: mext@ietf.org > Subject: Re: [MEXT] Prefix delegation & Diameter Interaction > > Well, this document seems to assume (or make a case) that the AAA > manages the prefixes. We *do not* recommend that model. It is > typically either the home agent or a DHCP server co-located with > the home agent that manages the prefixes. > > Vijay > > Hannes Tschofenig wrote: > > Hi all, > > > > in the DIME working group we have a document that provides the Diameter > > interworking for prefix delegation. > > Here is the document: > > http://tools.ietf.org/wg/dime/draft-sarikaya-dime-prefix-delegation-ps- > 00.txt > > > > > > It would help us in DIME if members of this group could give us some > > feedback. > > > > Ciao > > Hannes > > > > > > _______________________________________________ > > 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 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 08:28:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwe0c-0003OC-DQ; Mon, 26 Nov 2007 08:28:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwe0b-0003Mb-HM for mext@ietf.org; Mon, 26 Nov 2007 08:28:21 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwe0U-0005md-DG for mext@ietf.org; Mon, 26 Nov 2007 08:28:21 -0500 Received: by ug-out-1314.google.com with SMTP id u2so2401772uge for ; Mon, 26 Nov 2007 05:28:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=HsKg/UuhUgOJ9AjJKUr3DfkzzHaGU7RgxBRYDTC0iEw=; b=ruKb4Y1IJT3I6KjU0lz4nHLUplIoERAynNXU12gdt8SDWDuDd3N6bbE1+oyXEsKndSgEqbHfb8weuzeJn9jyxjQOmT/FwvW7U1kfH+INQy7SDb3j9zh8BH5h3LSFosdt9giJP5weZRiqJc+aBldszoQ7sgOgIl/qiUCZ0diyEs4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=pJHfVXAKwckCwsnrDE5b8E06mREbehnCJfDZVAwg3tUk3Te3yG6Uyau6Zp33oMkqPPTRhpKgXcDK6K/dAndoYv1LawoaxlcNAl8hz0fS+dolI4A9VaAR1DrNlFCKJMvIORYOo4Bwj+MmB5G3PIPCKYCjLAa37pQxJ3kmx3H4g7E= Received: by 10.78.122.16 with SMTP id u16mr2812275huc.1196083693452; Mon, 26 Nov 2007 05:28:13 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id f4sm847352nfh.2007.11.26.05.28.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2007 05:28:12 -0800 (PST) From: Julien Laganier To: mext@ietf.org Subject: Re: [MEXT] Next steps on prefix delegation Date: Mon, 26 Nov 2007 14:28:27 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> In-Reply-To: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200711261428.27978.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: 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 =46olks, Please see below: On Sunday 25 November 2007, marcelo bagnulo braun wrote: > Hi all, > > With respect to the NEMO prefix delegation issue, it is my opinion > that it would be preferred to have a single prefix delegation > solution rather than two. Moreover, that we should have strong > technical reasons to do more than one solution since this variety of > mechanisms without strong reasons adds needless complexity. > > So, my first question to the working group is: do you think there are > strong technical reasons to have more than one solution for prefix > delegation? > > If no, then which would be the preferred approach for prefix > delegation and why? > > Out goal is to try to wrap up this discussion in the next meting I would like to complement Marcelo's question with some more questions=20 from my side. I am quoting below one of the Architectural Principles of=20 the Internet [RFC1958]: =A0 =A03.2 If there are several ways of doing the same thing, choose one. =A0 =A0If a previous design, in the Internet context or elsewhere, has =A0 =A0successfully solved the same problem, choose the same solution unless =A0 =A0there is a good technical reason not to. =A0Duplication of the same =A0 =A0protocol functionality should be avoided as far as possible, without =A0 =A0of course using this argument to reject improvements. In light of this, it seems to me that we should select one mechanism=20 only for prefix delegation in the context of NEMO. If DHCPv6-PD would=20 work, it seems that it should be the only solution adopted. Things are=20 not that simple however and it is possible that very good reasons=20 justify the specification of a new mechanism for prefix delegation in=20 the context of NEMO.=20 To help the WG understand the tradeoffs involved and make an educated=20 choice, I'd like to ask the following questions: =A0 =A0o What could possibly make the existing DHCPv6 PD unsuitable to be =A0 =A0 =A0used for NEMO PD?=20 =A0 =A0o In case DHCPv6 is suitable but introduces limitations in the =A0 =A0 =A0context of NEMO that makes it desirable to standardize another =A0 =A0 =A0prefix delegation mechanism for NEMO, what would be the =A0 =A0 =A0limitations? Once we have answered these questions I believe the WG will be in the=20 best position to make the best choice. Cheers, =2D-julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 08:43: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 1IweFG-0006Gj-BZ; Mon, 26 Nov 2007 08:43:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IweFE-0006FZ-5A for mext@ietf.org; Mon, 26 Nov 2007 08:43:28 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IweFD-0000a4-K1 for mext@ietf.org; Mon, 26 Nov 2007 08:43:28 -0500 Received: (qmail 27604 invoked from network); 26 Nov 2007 14:43:25 +0100 Received: from unknown (HELO M90Teco) (217.169.232.211) by server9.hosting2go.nl with SMTP; 26 Nov 2007 14:43:25 +0100 From: "Teco Boot" To: "'Hannes Tschofenig'" References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> In-Reply-To: <474A8DE7.5030203@gmx.net> Subject: RE: [MEXT] RSVP TSPEC for flow-distribution-rules Date: Mon, 26 Nov 2007 14:42:49 +0100 Message-ID: <008601c83032$4e95b030$ebc11090$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgwDH5+bg2Pxv41QDCvZEDohCEnIAAJQS3Q Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Hannes, I suggest reusing what we already have. Maybe RSVP is already in place, in that case RSVP packets are sent over the tunnel. In the MONAMI6 context; I think we need a protocol for signaling traffic flow policy. This is related to MIP. Within this protocol, we need some kind of traffic specification, here we could reuse RSVP TSPEC. Cheers, Teco. > -----Oorspronkelijk bericht----- > Van: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Verzonden: maandag 26 november 2007 10:12 > Aan: Teco Boot > CC: mext@ietf.org > Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules > > Hi Teco, > > Teco Boot wrote: > >>> Finally, what happened to > >>> draft-mitsuya-monami6-flow-distribution-policy-04.txt. I > >>> thought this was also going to be adopted as a MONAMI6 WG > >>> document. I might have missed some emails. > >>> > >> There are two documents about flow distribution languages documents. > >> - draft-mitsuya-monami6-flow-distribution-policy-04.txt > >> - draft-larsson-monami6-filter-rules-02.txt > >> > >> We agreed to merge the two documents and > >> published draft-larsson-mext-flow-distribution-rules-00.txt > >> > >> > > > > I suggested to check using RSVP TSPEC for flow-distribution-rules > before. > > This has similar functionality and integration with upper layers > could be > > more straightforward. > > I'm afraid I don't have time to work out this idea. I would > appreciate > > someone picks up. > > > Are you suggesting to use RSVP for signaling the packet filters? > Or: Are you suggesting to look at the packet formats for describing the > traffic filters? > > > Ciao > Hannes > > > Teco. > > > > > > > > _______________________________________________ > > 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 Mon Nov 26 10:43: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 1Iwg7P-0007DQ-4D; Mon, 26 Nov 2007 10:43:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwg7N-0007Cv-Vm; Mon, 26 Nov 2007 10:43:30 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwg7N-0003i0-K0; Mon, 26 Nov 2007 10:43:29 -0500 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id lAQFhSw3029838; Mon, 26 Nov 2007 09:43:28 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 09:43:28 -0600 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 09:43:28 -0600 Message-ID: <474AE9E2.3040703@ericsson.com> Date: Mon, 26 Nov 2007 10:44:34 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: mext@ietf.org, mboned@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Nov 2007 15:43:28.0636 (UTC) FILETIME=[16F81BC0:01C83043] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [MEXT] Multicast Mobility session in Mobopts @IETF70 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 Folks, We will be having a session on multicast mobility as a part of the mobopts meeting at IETF70. Please find the agenda of the session below 5 min Introduction Behcet, Suresh 20 min Requirements Related Presentations IGMP/MLD Requirements Asaeda Mobile IPTV Requirements Hui Mobile IPv6 Requirements Thomas 5 min Mboned Requirements Marshall 5 min Solutions Overview Behcet, Suresh 23 min Discussion based on Jari's Questions All 2 min Summary and next steps Suresh, Behcet So please take some time to attend this session and provide your input on these items. We would like to get as much review as possible before we go forward. Thanks Suresh _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 10:59:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgMK-0000oM-Hg; Mon, 26 Nov 2007 10:58:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgMI-0000oH-GS for mext@ietf.org; Mon, 26 Nov 2007 10:58:54 -0500 Received: from an-out-0708.google.com ([209.85.132.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwgMC-0001O0-0A for mext@ietf.org; Mon, 26 Nov 2007 10:58:54 -0500 Received: by an-out-0708.google.com with SMTP id d11so124885and for ; Mon, 26 Nov 2007 07:58:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=JGrihnBQDDmwWLsPUsGE0OYOjoOY0LFkAOzywYy/0Hw=; b=kAZ/hkvu8jU05CdNVjr13tIKtPClEQ+J5oUIZtQqCp2a9hhl93rTmLO3mrWq6hPRPKMr/eoyQplI/7LrjElXy+483T9edVt6BAN4S1xOvLOUimsTONU5x+rtJvp3ovhfUVe33KcTaesJZ3kn5d/8ZKqbKB4/HKzlD9InF4F2aCY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=SHHsT2NSCh4SfpxGSoNJDhOkcZyAtKYbGl9MMUyOB8lOhPdy9UxQOxYh+l/O1AZ+y1i7D3rl/cs04Cej7pZEWWxCmtRc3lXPGwuGpIqS185LMIIpVRLcdkihlTfwkzpHtNDVggNmxtDxtu4X4CCLRdlNoYpuojnWN+O5h2m5S/0= Received: by 10.100.229.10 with SMTP id b10mr4153206anh.1196092727762; Mon, 26 Nov 2007 07:58:47 -0800 (PST) Received: from ?10.0.1.194? ( [219.110.64.224]) by mx.google.com with ESMTPS id h27sm2910490elf.2007.11.26.07.58.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2007 07:58:45 -0800 (PST) From: RYUJI WAKIKAWA To: Julien Laganier In-Reply-To: <200711261428.27978.julien.IETF@laposte.net> Subject: Re: [MEXT] Next steps on prefix delegation References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <200711261428.27978.julien.IETF@laposte.net> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 27 Nov 2007 00:58:38 +0900 X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 Julien and all, Agree that solo solution is always better, but I support both solutions for MNP delegation. DHCP PD is simple solution, but it requires DHCP functionalities at HA and MR. DHDP PD seems practical when MR boots up in home network. However, when MR boots up in foreign network, MR must creates a tunnel to send any DHCP messages. It means it takes several message exchanges between MR and HA to get MNP in bootstrap. PMIP uses similar way of NEMO PD to assign prefix to MN during binding registration. If MR uses IKE for HoA assignment, it can setup a tunnel and obtain its MNP simultaneously by initial BU. We have to remember that MR is also MIP6-MN. MIP6 WG standardized several ways to assign HoA to MN. Another question is that shall we have a mechanism to assign HoA and prefix at the same time? We should update both documents or write another document how NEMO bootstrap work with MIP6 bootstrap mechanisms. There are certainly pros & cons. Operator should select one. regards ryuji On 2007/11/26, at 22:28, Julien Laganier wrote: > Folks, > > Please see below: > > On Sunday 25 November 2007, marcelo bagnulo braun wrote: >> Hi all, >> >> With respect to the NEMO prefix delegation issue, it is my opinion >> that it would be preferred to have a single prefix delegation >> solution rather than two. Moreover, that we should have strong >> technical reasons to do more than one solution since this variety of >> mechanisms without strong reasons adds needless complexity. >> >> So, my first question to the working group is: do you think there are >> strong technical reasons to have more than one solution for prefix >> delegation? >> >> If no, then which would be the preferred approach for prefix >> delegation and why? >> >> Out goal is to try to wrap up this discussion in the next meting > > I would like to complement Marcelo's question with some more questions > from my side. I am quoting below one of the Architectural Principles > of > the Internet [RFC1958]: > > 3.2 If there are several ways of doing the same thing, choose one. > If a previous design, in the Internet context or elsewhere, has > successfully solved the same problem, choose the same solution > unless > there is a good technical reason not to. Duplication of the same > protocol functionality should be avoided as far as possible, > without > of course using this argument to reject improvements. > > In light of this, it seems to me that we should select one mechanism > only for prefix delegation in the context of NEMO. If DHCPv6-PD would > work, it seems that it should be the only solution adopted. Things are > not that simple however and it is possible that very good reasons > justify the specification of a new mechanism for prefix delegation in > the context of NEMO. > > To help the WG understand the tradeoffs involved and make an educated > choice, I'd like to ask the following questions: > > o What could possibly make the existing DHCPv6 PD unsuitable to be > used for NEMO PD? > > o In case DHCPv6 is suitable but introduces limitations in the > context of NEMO that makes it desirable to standardize another > prefix delegation mechanism for NEMO, what would be the > limitations? > > Once we have answered these questions I believe the WG will be in the > best position to make the best choice. > > Cheers, > > --julien > > _______________________________________________ > 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 Mon Nov 26 11:30: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 1IwgqW-0004OZ-QK; Mon, 26 Nov 2007 11:30:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgqV-0004OE-QB for mext@ietf.org; Mon, 26 Nov 2007 11:30:07 -0500 Received: from an-out-0708.google.com ([209.85.132.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwgqP-0002Ur-B8 for mext@ietf.org; Mon, 26 Nov 2007 11:30:07 -0500 Received: by an-out-0708.google.com with SMTP id d11so128174and for ; Mon, 26 Nov 2007 08:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=T/+OhZVUOT3mLP/F+2uEoOsJQabSc6vVBWEJplXETlc=; b=DnxFUOkYXOcGV/CaWJbEMa0ERluyR9hOFNnVsS2JgmJvyR8Y3sz55ewbdIayQ2jl8uEjLqYWZoibV0Jq+ULSFddJQbNlP93UmmqQ7OnbrhT1NdhDZuBXOJGhjo4q+YzEy4+yNcTMAY/LpNyoaIh64liJTbKy7Fd7i96SIcBHl1E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=bCqB+x7Iv+Dg7Ta4uuUVF8QcETvTNoZzEoFrZBQC5Y9tGCg18trL93js7g48RIFX47twNcxsbzXg4NNyvFX0f1vxzAnIoA1x+9VcoKK3Zwe/3lK+2IbHyPOcKSvq5yq+lzpcrMR/lMfDXxpOOzL74lBZAEJ+vkzrORUZI5ED7o0= Received: by 10.100.239.12 with SMTP id m12mr4213860anh.1196094601073; Mon, 26 Nov 2007 08:30:01 -0800 (PST) Received: from ?10.0.1.194? ( [219.110.64.224]) by mx.google.com with ESMTPS id p33sm2993775elf.2007.11.26.08.29.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2007 08:29:56 -0800 (PST) From: RYUJI WAKIKAWA To: Benjamin Lim In-Reply-To: Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-04.txt References: Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 27 Nov 2007 01:29:42 +0900 X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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 Benjamin, On 2007/11/26, at 13:17, Benjamin Lim wrote: > Hi, > > My 2 'sense' on one point raised. > > =8==8<=8== >> 3) Bulk Registrations and CNs: It is not clear why bulk >> registrations are not allowed for CNs. Is it so much more >> complex to handle bulk registrations once that is defined for >> the HA and once the CNs handle MCoAs one at a time? > [Ben] This point I agree with George. I feel that we might need to > consider > extending Bulk Reg to CN. > >> From what I understand on why bulk registration is not used for CN >> is that > the complexity it creates trying to figure out how to protect the BU > with > multiple CoKs and one HoK and in the same time proving to the CN > that all > the specified CoAs in the bulk BU are valid routing addresses to MN. > It > boils down to the matter on whether the benefit of bulk registration > is > worth the solving of such a complex procedure. One benefit I see in > bulk > registration is the effect it has on saving the power consumption > for the > MN. E.g. MN can use one of its IF to send a bulk BU to HA to bind > CoAs for right. If we support RO, we have to extend RR for bulk-registration. We need some mechanism to verify all the CoAs in a BU. > its other interfaces. This means that those IFs can be in idle mode > only to > be woken up upon the need to receive/send packets. This saves power on > maintaining the multiple IFs of the MN. So such saving in power at > the MN > might be worth considering exploring on this matter. For power saving purpose, the best way is that MN registers that CoA only to HA. MN just bulk-registers all the CoA in HA and waits for packets at the idle IF. > Also, I feel that other considerations on what impact would MN > trigger when > using bulk registration. For instance, in my recently submitted ID > (http://www.ietf.org/internet-drafts/draft-lim-mext-multiple-coa-verify-00.t > xt), I mention MN using bulk registration might be able to bind CoAs > of > victims at HA and thereby leading to a flooding attack to those > victims. I > believe it is worth taking such issue into consideration. Thanks for writing that document. We discussed this issue on Monami6 ML before. I am still not sure how serious this attack is. When the MN sends bulk-BU to HA, the MN has to create IPsec SA with the HA. The scenario looks very limited because not all the nodes can launch the attack. Even RFC3775 does not verify CoA for home registration. regards, ryuji > > > Regards, > Benjamin Lim > > > > _______________________________________________ > 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 smirnovaev@feiliks.com Mon Nov 26 11:32:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwgsz-0005I6-UY for nemo-archive@lists.ietf.org; Mon, 26 Nov 2007 11:32:41 -0500 Received: from [41.201.200.237] (helo=lioej) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iwgss-0002cb-L9 for nemo-archive@lists.ietf.org; Mon, 26 Nov 2007 11:32:41 -0500 Received: from wfelw ([204.138.95.221]) by lioej with Microsoft SMTPSVC(5.0.2195.5329); Mon, 26 Nov 2007 17:32:30 +0100 Message-ID: <474AF51E.2030107@feiliks.com> Date: Mon, 26 Nov 2007 17:32:30 +0100 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: Is there anymore stuffing Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Investors are all over ETgu 5 Things to think about this weekend: 1. The world is crying out for relief from the high cost of energy 2. Without much relief in site from authorities, businesses are looking for their own solutions to energy problems. 3. EnerBrite (E T G U) provides real solutions to energy costs, reducing them as much as 30%. 4. One facility after another is boasting the huge savings e tGU's SensorStat has brought to their business. 5. EnerBrite will be releasing more news in a media campaign this coming week. It's a trading frenzy on E tg U all week. Volume was going through the roof all week and Wednesday and Friday saw Market Makers pushing the price down and grabbing huge blocks in expectation of next weeks trading. Now is the time to grab e TGU. Act fast Monday morning. From mext-bounces@ietf.org Mon Nov 26 12:37:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwhtf-0002f7-Hs; Mon, 26 Nov 2007 12:37:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwhtc-0002em-Sb for mext@ietf.org; Mon, 26 Nov 2007 12:37:25 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwhtS-0005eO-Ty for mext@ietf.org; Mon, 26 Nov 2007 12:37:24 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 26 Nov 2007 09:37:14 -0800 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 lAQHbEN8013035; Mon, 26 Nov 2007 09:37:14 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAQHb9B0002094; Mon, 26 Nov 2007 17:37:09 GMT Date: Mon, 26 Nov 2007 09:37:08 -0800 (PST) From: Sri Gundavelli To: George Tsirtsis Subject: Re: [MEXT] MEXT charter In-Reply-To: Message-ID: References: <47420EC7.80606@piuha.net> <022701c82d42$a85d5700$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=664; t=1196098634; x=1196962634; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20MEXT=20charter |Sender:=20; bh=Zh87f3GdBth35Jby2ir00zyT1m3KMyhkuvnrxFf955Q=; b=DJ8b2oHbSCexmaM9SBq0JVT7Byx2PprQP2w7oyyxFsSOMEDB0fDH/M94kZB80qnggQM0+RpV N2jVFR76aH0tJjtd72n93Ez/Tuf2sHEXXW5eR2EgnJ8hf9/0AHNJf0Hx; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Julien Laganier , 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 George, On Mon, 26 Nov 2007, George Tsirtsis wrote: > Hi Sri, > > According to this draft the sender of the notification message can resend > the notification if it sets the A flag and does not receive an ack. This is > correctly defined as a MAY, but I think some language should also be added > WRT the fact that lack of acknowledgement could also mean that the receiver > does not support generic notifications as all; or is some other behavior > expected in such a case? Thanks for the comment. I agree, we need to provide the hint to the sender that the receiver may not support this option and the suggested action. Regards Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 13:22: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 1IwibQ-0002ZP-O3; Mon, 26 Nov 2007 13:22:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwibO-0002ZK-Jf for mext@ietf.org; Mon, 26 Nov 2007 13:22:38 -0500 Received: from hu-out-0506.google.com ([72.14.214.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwibK-0007dl-Hg for mext@ietf.org; Mon, 26 Nov 2007 13:22:38 -0500 Received: by hu-out-0506.google.com with SMTP id 31so595780huc for ; Mon, 26 Nov 2007 10:22:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=IO2Xa2Tya5+WL1uaz9XoPH+KhmcW2mZGx+Y9x4VW+zo=; b=p/H1YvCLm/6WZHyscLFhR2p1oUa0MzF4KmMcv4lFOctU3lFc5Gj+U4hXy7uPphNOZz0EbpryLfeMGeuOzeij0qDCn3fjieXEC2wK/CtEQjTqpgcro3MsXPdpHqKpljZ+kxx04CtabVlXuVHTIrFFYg5OABj+HSCqngViHJRHiYU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=SdYKSlm33GFyFKiVG8Imog1qmhLndL9ubrrKOzNv/pNJpbGye9HCGknzDQH84RZ+dbh6rsncPhrKPa5bqAHB1cyzVhSCfiQDEytnLkhwYbowPBnS5JOlrf2zVAB5vnXk+iGKpMyOU4/vwrXtHGf/NNZ5XuOKRAgBu+awwR4rj5Y= Received: by 10.78.168.1 with SMTP id q1mr3283883hue.1196101353450; Mon, 26 Nov 2007 10:22:33 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id k9sm713691nfh.2007.11.26.10.22.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2007 10:22:31 -0800 (PST) From: Julien Laganier To: RYUJI WAKIKAWA Subject: Re: [MEXT] Next steps on prefix delegation Date: Mon, 26 Nov 2007 19:22:41 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <200711261428.27978.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711261922.42067.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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 Hello Ryuji, I'd still like the questions I've asked to be answered, but anyway: : On Monday 26 November 2007, RYUJI WAKIKAWA wrote: > Hi Julien and all, > > Agree that solo solution is always better, but I support both > solutions for MNP delegation. > > DHCP PD is simple solution, but it requires DHCP functionalities at > HA and MR. > DHDP PD seems practical when MR boots up in home network. > However, when MR boots up in foreign network, MR must creates a > tunnel to send any DHCP messages. > It means it takes several message exchanges between MR and HA to get > MNP in bootstrap. Since booting a node typically consumes quite some time it seems the delay incurred by an additional message exchange could be considered as neglogible. > PMIP uses similar way of NEMO PD to assign prefix to MN during > binding registration. This discussion is about NEMO prefix delegation; AFAICT PMIP doesn't require *delegation* of prefixes, thus it is not a good comparison w.r.t. this discussion. > If MR uses IKE for HoA assignment, it can setup a tunnel and obtain > its MNP simultaneously by initial BU. As I said above if the MR is booting up I don't see the MNP assignment as time critical. > We have to remember that MR is also MIP6-MN. MIP6 WG standardized > several ways to assign HoA to MN. Well, first of all it is not because one choice was made in one situation that this choice applies in every other situation. In this specific case the HoA assignment is an *address* *assignment*, and we're talking here about *prefix* *delegation*. What makes the two fundamentally dissimilar is that to assigns addresses you can use stateless or statefull mechanism, whereas to delegate a prefix a stateful mechanism is required. Thus I do not see the comparison between MIPv6 HoA assignment and NEMO PD as relevant. > Another question is that shall we have a mechanism to assign HoA and > prefix at the same time? I don't think so, this looks like an optimization on something that isn't time critical anyway. What would be the point of coupling these two, maybe I'm missing something. Modularity is a feature IMHO. > We should update both documents or write another document how NEMO > bootstrap work with MIP6 bootstrap mechanisms. > > There are certainly pros & cons. Operator should select one. Well, one thing I'm sure is that having two mechanisms is a drawback since it might require coordination between vendors and administrators on the operator and MN sides. When a single mechanism is present no such coordination is needed. Cheers, --julien > On 2007/11/26, at 22:28, Julien Laganier wrote: > > Folks, > > > > Please see below: > > > > On Sunday 25 November 2007, marcelo bagnulo braun wrote: > >> Hi all, > >> > >> With respect to the NEMO prefix delegation issue, it is my opinion > >> that it would be preferred to have a single prefix delegation > >> solution rather than two. Moreover, that we should have strong > >> technical reasons to do more than one solution since this variety > >> of mechanisms without strong reasons adds needless complexity. > >> > >> So, my first question to the working group is: do you think there > >> are strong technical reasons to have more than one solution for > >> prefix delegation? > >> > >> If no, then which would be the preferred approach for prefix > >> delegation and why? > >> > >> Out goal is to try to wrap up this discussion in the next meting > > > > I would like to complement Marcelo's question with some more > > questions from my side. I am quoting below one of the Architectural > > Principles of > > the Internet [RFC1958]: > > > > 3.2 If there are several ways of doing the same thing, choose > > one. If a previous design, in the Internet context or elsewhere, > > has successfully solved the same problem, choose the same solution > > unless > > there is a good technical reason not to. Duplication of the > > same protocol functionality should be avoided as far as possible, > > without > > of course using this argument to reject improvements. > > > > In light of this, it seems to me that we should select one > > mechanism only for prefix delegation in the context of NEMO. If > > DHCPv6-PD would work, it seems that it should be the only solution > > adopted. Things are not that simple however and it is possible that > > very good reasons justify the specification of a new mechanism for > > prefix delegation in the context of NEMO. > > > > To help the WG understand the tradeoffs involved and make an > > educated choice, I'd like to ask the following questions: > > > > o What could possibly make the existing DHCPv6 PD unsuitable to > > be used for NEMO PD? > > > > o In case DHCPv6 is suitable but introduces limitations in the > > context of NEMO that makes it desirable to standardize another > > prefix delegation mechanism for NEMO, what would be the > > limitations? > > > > Once we have answered these questions I believe the WG will be in > > the best position to make the best choice. > > > > Cheers, > > > > --julien > > > > _______________________________________________ > > 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 Mon Nov 26 13:40: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 1IwisB-0007xA-TY; Mon, 26 Nov 2007 13:39:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwisA-0007lD-50 for mext@ietf.org; Mon, 26 Nov 2007 13:39:58 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwis5-000869-6E for mext@ietf.org; Mon, 26 Nov 2007 13:39:58 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Nov 2007 10:39:52 -0800 Message-ID: <474B12F7.8000700@azairenet.com> Date: Mon, 26 Nov 2007 10:39:51 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [MEXT] Prefix delegation & Diameter Interaction References: <0MKp8S-1IwdRx2OQq-0008Gc@mrelay.perfora.net> In-Reply-To: <0MKp8S-1IwdRx2OQq-0008Gc@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Nov 2007 18:39:52.0512 (UTC) FILETIME=[BB736C00:01C8305B] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: 'Hannes Tschofenig' , 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 Alper Yegin wrote: > Vijay, > > Can you explain why you do not recommend AAA-assignment of prefixes? We have been through this many times on the MIP6 mailing list. The earlier discussions were based on AAA assigning the home address. We have always concluded otherwise. I don't see much different between AAA managing home prefixes and home addresses. I am not planning to rehash those discussions. Vijay > > Alper > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >> Sent: Sunday, November 25, 2007 7:17 PM >> To: Hannes Tschofenig >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Prefix delegation & Diameter Interaction >> >> Well, this document seems to assume (or make a case) that the AAA >> manages the prefixes. We *do not* recommend that model. It is >> typically either the home agent or a DHCP server co-located with >> the home agent that manages the prefixes. >> >> Vijay >> >> Hannes Tschofenig wrote: >>> Hi all, >>> >>> in the DIME working group we have a document that provides the Diameter >>> interworking for prefix delegation. >>> Here is the document: >>> http://tools.ietf.org/wg/dime/draft-sarikaya-dime-prefix-delegation-ps- >> 00.txt >>> >>> It would help us in DIME if members of this group could give us some >>> feedback. >>> >>> Ciao >>> Hannes >>> >>> >>> _______________________________________________ >>> 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 > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 13:53: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 1Iwj5L-0007wc-8X; Mon, 26 Nov 2007 13:53:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwj5J-0007w9-AH for mext@ietf.org; Mon, 26 Nov 2007 13:53:33 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwj5I-00023b-U9 for mext@ietf.org; Mon, 26 Nov 2007 13:53:33 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Nov 2007 10:53:31 -0800 Message-ID: <474B162B.5090804@azairenet.com> Date: Mon, 26 Nov 2007 10:53:31 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Julien Laganier Subject: Re: [MEXT] Next steps on prefix delegation References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <200711261428.27978.julien.IETF@laposte.net> In-Reply-To: <200711261428.27978.julien.IETF@laposte.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Nov 2007 18:53:31.0944 (UTC) FILETIME=[A3DED280:01C8305D] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Julien Laganier wrote: > To help the WG understand the tradeoffs involved and make an educated > choice, I'd like to ask the following questions: > > o What could possibly make the existing DHCPv6 PD unsuitable to be > used for NEMO PD? Having to implement a DHCPv6 relay functionality on the home agent is one issue. And many folks don't seem to be too comfortable with running DHCPv6 over the tunnel between the mobile router and the home agent. There is a parallel discussion going on on the MIP4 mailing list about using DHCP. http://www1.ietf.org/mail-archive/web/mip4/current/msg02727.html > o In case DHCPv6 is suitable but introduces limitations in the > context of NEMO that makes it desirable to standardize another > prefix delegation mechanism for NEMO, what would be the > limitations? It will work. The issue is more about which solution is more easily implementable/deployable. For example, it is quite straight forward for the mobile router to request for a mobile network prefix in the binding update and get a prefix in the binding ack. The home agent just needs to have a local pool of mobile network prefixes. Vijay > Once we have answered these questions I believe the WG will be in the > best position to make the best choice. > > Cheers, > > --julien > > _______________________________________________ > 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 Mon Nov 26 14:05: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 1IwjGR-0003KD-7Q; Mon, 26 Nov 2007 14:05:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjGP-0003K2-Qd for mext@ietf.org; Mon, 26 Nov 2007 14:05:01 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwjGN-0000KK-CV for mext@ietf.org; Mon, 26 Nov 2007 14:05:01 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Nov 2007 11:04:58 -0800 Message-ID: <474B18DA.8010708@azairenet.com> Date: Mon, 26 Nov 2007 11:04:58 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Frank Xia Subject: Re: [MEXT] Prefix delegation & Diameter Interaction References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <47495F23.2040107@gmx.net> <4749ADFB.8010807@azairenet.com> <011a01c82fdd$d573e7c0$0701a8c0@china.huawei.com> In-Reply-To: <011a01c82fdd$d573e7c0$0701a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Nov 2007 19:04:58.0846 (UTC) FILETIME=[3D4BBFE0:01C8305F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Hannes Tschofenig , 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 Frank Xia wrote: > Hi Vijay > > AAA servers managing address pool is one of the basic funtions in the industry. Thats news to me. AFAIK, static home addresses are stored in the subscription profile of the user. Home addresses allocated dynamically typically from the home agent. Vijay > In the point-to-point scenario, different MNs have different prefixes. That is , > prefix managing is the natural extension for the address management. > > Please see other inline response... > > BR > Frank > > ----- Original Message ----- > From: "Vijay Devarapalli" > To: "Hannes Tschofenig" > Cc: > Sent: Sunday, November 25, 2007 11:16 AM > Subject: Re: [MEXT] Prefix delegation & Diameter Interaction > > >> Well, this document seems to assume (or make a case) that the AAA >> manages the prefixes. We *do not* recommend that model. It is >> typically either the home agent or a DHCP server co-located with >> the home agent that manages the prefixes. > Frank=>It is sure that home agent or built-in DHCP server can manage > prefixes. This is local prefix management mode. IMHO, it is not optimal. > If we think that prefix management is the extension of address management, > it is easy to think about remote prefix management mode. > >> Vijay >> >> Hannes Tschofenig wrote: >>> Hi all, >>> >>> in the DIME working group we have a document that provides the Diameter >>> interworking for prefix delegation. >>> Here is the document: >>> http://tools.ietf.org/wg/dime/draft-sarikaya-dime-prefix-delegation-ps-00.txt >>> >>> >>> It would help us in DIME if members of this group could give us some >>> feedback. >>> >>> Ciao >>> Hannes >>> >>> >>> _______________________________________________ >>> 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 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 14:29: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 1Iwjdl-0007bY-NK; Mon, 26 Nov 2007 14:29:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwjdk-0007bJ-68 for mext@ietf.org; Mon, 26 Nov 2007 14:29:08 -0500 Received: from usaga04-in.huawei.com ([206.16.17.180] helo=usaga01-in.huawei.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwjdj-0002yf-OV for mext@ietf.org; Mon, 26 Nov 2007 14:29:08 -0500 Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS400A5MOSI8L@usaga04-in.huawei.com> for mext@ietf.org; Mon, 26 Nov 2007 13:29:07 -0600 (CST) Received: from ny3104051930 ([10.124.12.88]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JS4000VJOSGFV@usaga04-in.huawei.com> for mext@ietf.org; Mon, 26 Nov 2007 13:29:06 -0600 (CST) Date: Mon, 26 Nov 2007 13:31:59 -0600 From: Frank Xia Subject: Re: [MEXT] Prefix delegation & Diameter Interaction To: Vijay Devarapalli Message-id: <011401c83063$0398a4d0$580c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <47495F23.2040107@gmx.net> <4749ADFB.8010807@azairenet.com> <011a01c82fdd$d573e7c0$0701a8c0@china.huawei.com> <474B18DA.8010708@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Hannes Tschofenig , 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 Vijay AAA servers can manage static address pool which is discribed in your email. At the same time, AAA servers can manage dynamic static address pool. For example, AAA servers allocate dynamic addresses for each PPP sessiones. BR Frank ----- Original Message ----- From: "Vijay Devarapalli" To: "Frank Xia" Cc: "Hannes Tschofenig" ; Sent: Monday, November 26, 2007 1:04 PM Subject: Re: [MEXT] Prefix delegation & Diameter Interaction > Frank Xia wrote: > > Hi Vijay > > > > AAA servers managing address pool is one of the basic funtions in the industry. > > Thats news to me. AFAIK, static home addresses are stored in > the subscription profile of the user. Home addresses allocated > dynamically typically from the home agent. > > Vijay > > > In the point-to-point scenario, different MNs have different prefixes. That is , > > prefix managing is the natural extension for the address management. > > > > Please see other inline response... > > > > BR > > Frank > > > > ----- Original Message ----- > > From: "Vijay Devarapalli" > > To: "Hannes Tschofenig" > > Cc: > > Sent: Sunday, November 25, 2007 11:16 AM > > Subject: Re: [MEXT] Prefix delegation & Diameter Interaction > > > > > >> Well, this document seems to assume (or make a case) that the AAA > >> manages the prefixes. We *do not* recommend that model. It is > >> typically either the home agent or a DHCP server co-located with > >> the home agent that manages the prefixes. > > Frank=>It is sure that home agent or built-in DHCP server can manage > > prefixes. This is local prefix management mode. IMHO, it is not optimal. > > If we think that prefix management is the extension of address management, > > it is easy to think about remote prefix management mode. > > > >> Vijay > >> > >> Hannes Tschofenig wrote: > >>> Hi all, > >>> > >>> in the DIME working group we have a document that provides the Diameter > >>> interworking for prefix delegation. > >>> Here is the document: > >>> http://tools.ietf.org/wg/dime/draft-sarikaya-dime-prefix-delegation-ps-00.txt > >>> > >>> > >>> It would help us in DIME if members of this group could give us some > >>> feedback. > >>> > >>> Ciao > >>> Hannes > >>> > >>> > >>> _______________________________________________ > >>> 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 > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 14:34: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 1Iwjiw-0001fe-83; Mon, 26 Nov 2007 14:34:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwjiu-0001fZ-Tt for mext@ietf.org; Mon, 26 Nov 2007 14:34:29 -0500 Received: from web84110.mail.mud.yahoo.com ([68.142.206.197]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iwjit-00036H-Ie for mext@ietf.org; Mon, 26 Nov 2007 14:34:28 -0500 Received: (qmail 54656 invoked by uid 60001); 26 Nov 2007 19:34:27 -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=nK8wNLkza7yhWKJKPchsoBv7lPPbKPvp0eUN+rz6Rcz3bHQgSQshSLrlZnLp+rqY5mkG1XXFCTIPNbMVfZcyH/kCd41nxC1JDpwObLGCLipaVBk21YdjYMfIBaHG5rBmlJZz5TMuLJG4H3kzrfm/X9Oh8qX5YXqdJTlGTf2s81Y=; X-YMail-OSG: AdZCawYVM1mqa39eIUN2duNTi5TGDMFEg7SUq8.Q83gIIClkeZ1.JpC9.RR63akTfA-- Received: from [206.16.17.212] by web84110.mail.mud.yahoo.com via HTTP; Mon, 26 Nov 2007 11:34:26 PST X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.152 Date: Mon, 26 Nov 2007 11:34:26 -0800 (PST) From: Behcet Sarikaya Subject: Re: [MEXT] Next steps on prefix delegation To: RYUJI WAKIKAWA MIME-Version: 1.0 Message-ID: <18771.36792.qm@web84110.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1709402458==" Errors-To: mext-bounces@ietf.org --===============1709402458== Content-Type: multipart/alternative; boundary="0-81162754-1196105666=:36792" --0-81162754-1196105666=:36792 Content-Type: text/plain; charset=us-ascii Hi Ryuji, DHCP PD does not require DHCP functionality at the MR. HA can get a prefix for MR even if MR boots up in foreign network. Regards, Behcet ----- Original Message ---- From: Julien Laganier To: RYUJI WAKIKAWA Cc: mext@ietf.org Sent: Monday, November 26, 2007 12:22:41 PM Subject: Re: [MEXT] Next steps on prefix delegation Hello Ryuji, I'd still like the questions I've asked to be answered, but anyway: : On Monday 26 November 2007, RYUJI WAKIKAWA wrote: > Hi Julien and all, > > Agree that solo solution is always better, but I support both > solutions for MNP delegation. > > DHCP PD is simple solution, but it requires DHCP functionalities at > HA and MR. > DHDP PD seems practical when MR boots up in home network. > However, when MR boots up in foreign network, MR must creates a > tunnel to send any DHCP messages. > It means it takes several message exchanges between MR and HA to get > MNP in bootstrap. Since booting a node typically consumes quite some time it seems the delay incurred by an additional message exchange could be considered as neglogible. > PMIP uses similar way of NEMO PD to assign prefix to MN during > binding registration. This discussion is about NEMO prefix delegation; AFAICT PMIP doesn't require *delegation* of prefixes, thus it is not a good comparison w.r.t. this discussion. > If MR uses IKE for HoA assignment, it can setup a tunnel and obtain > its MNP simultaneously by initial BU. As I said above if the MR is booting up I don't see the MNP assignment as time critical. > We have to remember that MR is also MIP6-MN. MIP6 WG standardized > several ways to assign HoA to MN. Well, first of all it is not because one choice was made in one situation that this choice applies in every other situation. In this specific case the HoA assignment is an *address* *assignment*, and we're talking here about *prefix* *delegation*. What makes the two fundamentally dissimilar is that to assigns addresses you can use stateless or statefull mechanism, whereas to delegate a prefix a stateful mechanism is required. Thus I do not see the comparison between MIPv6 HoA assignment and NEMO PD as relevant. > Another question is that shall we have a mechanism to assign HoA and > prefix at the same time? I don't think so, this looks like an optimization on something that isn't time critical anyway. What would be the point of coupling these two, maybe I'm missing something. Modularity is a feature IMHO. > We should update both documents or write another document how NEMO > bootstrap work with MIP6 bootstrap mechanisms. > > There are certainly pros & cons. Operator should select one. Well, one thing I'm sure is that having two mechanisms is a drawback since it might require coordination between vendors and administrators on the operator and MN sides. When a single mechanism is present no such coordination is needed. Cheers, --julien > On 2007/11/26, at 22:28, Julien Laganier wrote: > > Folks, > > > > Please see below: > > > > On Sunday 25 November 2007, marcelo bagnulo braun wrote: > >> Hi all, > >> > >> With respect to the NEMO prefix delegation issue, it is my opinion > >> that it would be preferred to have a single prefix delegation > >> solution rather than two. Moreover, that we should have strong > >> technical reasons to do more than one solution since this variety > >> of mechanisms without strong reasons adds needless complexity. > >> > >> So, my first question to the working group is: do you think there > >> are strong technical reasons to have more than one solution for > >> prefix delegation? > >> > >> If no, then which would be the preferred approach for prefix > >> delegation and why? > >> > >> Out goal is to try to wrap up this discussion in the next meting > > > > I would like to complement Marcelo's question with some more > > questions from my side. I am quoting below one of the Architectural > > Principles of > > the Internet [RFC1958]: > > > > 3.2 If there are several ways of doing the same thing, choose > > one. If a previous design, in the Internet context or elsewhere, > > has successfully solved the same problem, choose the same solution > > unless > > there is a good technical reason not to. Duplication of the > > same protocol functionality should be avoided as far as possible, > > without > > of course using this argument to reject improvements. > > > > In light of this, it seems to me that we should select one > > mechanism only for prefix delegation in the context of NEMO. If > > DHCPv6-PD would work, it seems that it should be the only solution > > adopted. Things are not that simple however and it is possible that > > very good reasons justify the specification of a new mechanism for > > prefix delegation in the context of NEMO. > > > > To help the WG understand the tradeoffs involved and make an > > educated choice, I'd like to ask the following questions: > > > > o What could possibly make the existing DHCPv6 PD unsuitable to > > be used for NEMO PD? > > > > o In case DHCPv6 is suitable but introduces limitations in the > > context of NEMO that makes it desirable to standardize another > > prefix delegation mechanism for NEMO, what would be the > > limitations? > > > > Once we have answered these questions I believe the WG will be in > > the best position to make the best choice. > > > > Cheers, > > > > --julien > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --0-81162754-1196105666=:36792 Content-Type: text/html; charset=us-ascii
Hi Ryuji,
  DHCP PD does not require DHCP functionality at the MR. HA can get a prefix for MR even if MR boots up in foreign network.

Regards,

Behcet

----- Original Message ----
From: Julien Laganier <julien.IETF@laposte.net>
To: RYUJI WAKIKAWA <ryuji.wakikawa@gmail.com>
Cc: mext@ietf.org
Sent: Monday, November 26, 2007 12:22:41 PM
Subject: Re: [MEXT] Next steps on prefix delegation

Hello Ryuji,

I'd still like the questions I've asked to be answered, but anyway:

<chair hat off>:

On Monday 26 November 2007, RYUJI WAKIKAWA wrote:
> Hi Julien and all,
>
> Agree that solo solution is always better, but I support both
> solutions for MNP delegation.
>
> DHCP PD is simple solution, but it requires DHCP functionalities at
> HA and MR.
> DHDP PD seems practical when MR boots up in home network.
> However, when MR boots up in foreign network, MR must creates a
> tunnel to send any DHCP messages.
> It means it takes several message exchanges between MR and HA to get
> MNP in bootstrap.

Since booting a node typically consumes quite some time it seems the
delay incurred by an additional message exchange could be considered as
neglogible.

> PMIP uses similar way of NEMO PD to assign prefix to MN during
> binding registration.

This discussion is about NEMO prefix delegation; AFAICT PMIP doesn't
require *delegation* of prefixes, thus it is not a good comparison
w.r.t. this discussion.

> If MR uses IKE for HoA assignment, it can setup a tunnel and obtain
> its MNP simultaneously by initial BU.

As I said above if the MR is booting up I don't see the MNP assignment
as time critical.

> We have to remember that MR is also MIP6-MN.  MIP6 WG standardized
> several ways to assign HoA to  MN.

Well, first of all it is not because one choice was made in one
situation that this choice applies in every other situation.

In this specific case the HoA assignment is an *address* *assignment*,
and we're talking here about *prefix* *delegation*.

What makes the two fundamentally dissimilar is that to assigns addresses
you can use stateless or statefull mechanism, whereas to delegate a
prefix a stateful mechanism is required.

Thus I do not see the comparison between MIPv6 HoA assignment and NEMO
PD as relevant.

> Another question is that shall we have a mechanism to assign HoA and
> prefix at the same time?

I don't think so, this looks like an optimization on something that
isn't time critical anyway. What would be the point of coupling these
two, maybe I'm missing something. Modularity is a feature IMHO.

> We should update both documents or write another document how NEMO
> bootstrap work with MIP6 bootstrap mechanisms.
>
> There are certainly pros & cons. Operator should select one.

Well, one thing I'm sure is that having two mechanisms is a drawback
since it might require coordination between vendors and administrators
on the operator and MN sides. When a single mechanism is present no
such coordination is needed.

Cheers,

--julien

> On 2007/11/26, at 22:28, Julien Laganier wrote:
> > Folks,
> >
> > Please see below:
> >
> > On Sunday 25 November 2007, marcelo bagnulo braun wrote:
> >> Hi all,
> >>
> >> With respect to the NEMO prefix delegation issue, it is my opinion
> >> that it would be preferred to have a single prefix delegation
> >> solution rather than two. Moreover, that we should have strong
> >> technical reasons to do more than one solution since this variety
> >> of mechanisms without strong reasons adds needless complexity.
> >>
> >> So, my first question to the working group is: do you think there
> >> are strong technical reasons to have more than one solution for
> >> prefix delegation?
> >>
> >> If no, then which would be the preferred approach for prefix
> >> delegation and why?
> >>
> >> Out goal is to try to wrap up this discussion in the next meting
> >
> > I would like to complement Marcelo's question with some more
> > questions from my side. I am quoting below one of the Architectural
> > Principles of
> > the Internet [RFC1958]:
> >
> >    3.2 If there are several ways of doing the same thing, choose
> > one. If a previous design, in the Internet context or elsewhere,
> > has successfully solved the same problem, choose the same solution
> > unless
> >    there is a good technical reason not to.  Duplication of the
> > same protocol functionality should be avoided as far as possible,
> > without
> >    of course using this argument to reject improvements.
> >
> > In light of this, it seems to me that we should select one
> > mechanism only for prefix delegation in the context of NEMO. If
> > DHCPv6-PD would work, it seems that it should be the only solution
> > adopted. Things are not that simple however and it is possible that
> > very good reasons justify the specification of a new mechanism for
> > prefix delegation in the context of NEMO.
> >
> > To help the WG understand the tradeoffs involved and make an
> > educated choice, I'd like to ask the following questions:
> >
> >    o What could possibly make the existing DHCPv6 PD unsuitable to
> > be used for NEMO PD?
> >
> >    o In case DHCPv6 is suitable but introduces limitations in the
> >      context of NEMO that makes it desirable to standardize another
> >      prefix delegation mechanism for NEMO, what would be the
> >      limitations?
> >
> > Once we have answered these questions I believe the WG will be in
> > the best position to make the best choice.
> >
> > Cheers,
> >
> > --julien
> >
> > _______________________________________________
> > MEXT mailing list
> > MEXT@ietf.org
> > https://www1.ietf.org/mailman/listinfo/mext



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

--0-81162754-1196105666=:36792-- --===============1709402458== 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 --===============1709402458==-- From mext-bounces@ietf.org Mon Nov 26 14:46: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 1Iwju1-0006b2-Vu; Mon, 26 Nov 2007 14:45:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwju0-0006aj-Bk for mext@ietf.org; Mon, 26 Nov 2007 14:45:56 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iwjtz-0003Kx-J1 for mext@ietf.org; Mon, 26 Nov 2007 14:45:56 -0500 Received: (qmail invoked by alias); 26 Nov 2007 19:45:53 -0000 Received: from p54985274.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.82.116] by mail.gmx.net (mp052) with SMTP; 26 Nov 2007 20:45:53 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+bnSc+xH2bjRbEjV7F/SY/AJhuuWNJLzSlCGmYpf UA53pP5k1+JsFl Message-ID: <474B2270.8080405@gmx.net> Date: Mon, 26 Nov 2007 20:45:52 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [MEXT] Prefix delegation & Diameter Interaction References: <0MKp8S-1IwdRx2OQq-0008Gc@mrelay.perfora.net> <474B12F7.8000700@azairenet.com> In-Reply-To: <474B12F7.8000700@azairenet.com> 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: 0fa76816851382eb71b0a882ccdc29ac 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 Vijay, maybe you can provide some pointers to past discussions and conclusions. You cannot expect that everyone follows all mailing lists and now this work is being proposed for DIME. Ciao Hannes PS: I once had comments for a QoS document and I got the following response "I don't have time to give you a tutorial on this QoS issue. We discussed this at length in face-to-face meeting at the IETF XYZ meeting." The document got delayed for more than a year when the same questions showed up later again.... Vijay Devarapalli wrote: > Alper Yegin wrote: >> Vijay, >> >> Can you explain why you do not recommend AAA-assignment of prefixes? > > We have been through this many times on the MIP6 mailing list. > The earlier discussions were based on AAA assigning the home > address. We have always concluded otherwise. I don't see much > different between AAA managing home prefixes and home addresses. > I am not planning to rehash those discussions. > > Vijay > > >> >> Alper >> >>> -----Original Message----- >>> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >>> Sent: Sunday, November 25, 2007 7:17 PM >>> To: Hannes Tschofenig >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Prefix delegation & Diameter Interaction >>> >>> Well, this document seems to assume (or make a case) that the AAA >>> manages the prefixes. We *do not* recommend that model. It is >>> typically either the home agent or a DHCP server co-located with >>> the home agent that manages the prefixes. >>> >>> Vijay >>> >>> Hannes Tschofenig wrote: >>>> Hi all, >>>> >>>> in the DIME working group we have a document that provides the >>>> Diameter >>>> interworking for prefix delegation. >>>> Here is the document: >>>> http://tools.ietf.org/wg/dime/draft-sarikaya-dime-prefix-delegation-ps- >>>> >>> 00.txt >>>> >>>> It would help us in DIME if members of this group could give us some >>>> feedback. >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> _______________________________________________ >>>> 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 >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 15:42: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 1Iwkmm-0001Ci-CY; Mon, 26 Nov 2007 15:42:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwkml-00016x-6p for mext@ietf.org; Mon, 26 Nov 2007 15:42:31 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iwkmh-0002in-No for mext@ietf.org; Mon, 26 Nov 2007 15:42:31 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-119.messagelabs.com!1196109746!27310891!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 20185 invoked from network); 26 Nov 2007 20:42:27 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-119.messagelabs.com with SMTP; 26 Nov 2007 20:42:27 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAQKgQ2N025381; Mon, 26 Nov 2007 13:42:26 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lAQKgQka000992; Mon, 26 Nov 2007 14:42:26 -0600 (CST) Received: from [127.0.0.1] ([10.129.41.26]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lAQKgOTV000975; Mon, 26 Nov 2007 14:42:24 -0600 (CST) Message-ID: <474B2FAF.4030709@gmail.com> Date: Mon, 26 Nov 2007 21:42:23 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [MEXT] Prefix delegation & Diameter Interaction References: <0MKp8S-1IwdRx2OQq-0008Gc@mrelay.perfora.net> <474B12F7.8000700@azairenet.com> <474B2270.8080405@gmx.net> In-Reply-To: <474B2270.8080405@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071124-0, 24/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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 Hannes Tschofenig wrote: > Hi Vijay, > > maybe you can provide some pointers to past discussions and conclusions. > You cannot expect that everyone follows all mailing lists and now this > work is being proposed for DIME. Sorry for intruding... it's difficult for someone to dig archives, as much as it is for you. I share the part of Vijay's view that somehow somewhere in the MIP6 discussions (was that during MIP WG? MIP6 WG? playground at SUN? ietf.org list?) and during the meeting minutes it was pretty clear that the MN's Home Address would not be allocated by the AAA system. MIP6 would be supposed to work with any system to allocate addresses. That's my personal rememberings. Not to correct in any way, just to share a view. Alex > > Ciao > Hannes > > PS: I once had comments for a QoS document and I got the following > response "I don't have time to give you a tutorial on this QoS issue. We > discussed this at length in face-to-face meeting at the IETF XYZ meeting." > > The document got delayed for more than a year when the same questions > showed up later again.... > > Vijay Devarapalli wrote: >> Alper Yegin wrote: >>> Vijay, >>> >>> Can you explain why you do not recommend AAA-assignment of prefixes? >> >> We have been through this many times on the MIP6 mailing list. >> The earlier discussions were based on AAA assigning the home >> address. We have always concluded otherwise. I don't see much >> different between AAA managing home prefixes and home addresses. >> I am not planning to rehash those discussions. >> >> Vijay >> >> >>> >>> Alper >>> >>>> -----Original Message----- >>>> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >>>> Sent: Sunday, November 25, 2007 7:17 PM >>>> To: Hannes Tschofenig >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Prefix delegation & Diameter Interaction >>>> >>>> Well, this document seems to assume (or make a case) that the AAA >>>> manages the prefixes. We *do not* recommend that model. It is >>>> typically either the home agent or a DHCP server co-located with >>>> the home agent that manages the prefixes. >>>> >>>> Vijay >>>> >>>> Hannes Tschofenig wrote: >>>>> Hi all, >>>>> >>>>> in the DIME working group we have a document that provides the >>>>> Diameter >>>>> interworking for prefix delegation. >>>>> Here is the document: >>>>> http://tools.ietf.org/wg/dime/draft-sarikaya-dime-prefix-delegation-ps- >>>>> >>>> 00.txt >>>>> >>>>> It would help us in DIME if members of this group could give us some >>>>> feedback. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 15:47: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 1Iwkr9-0005CH-R8; Mon, 26 Nov 2007 15:47:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwkr8-0005CA-Pq for mext@ietf.org; Mon, 26 Nov 2007 15:47:02 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iwkr8-0004eL-3U for mext@ietf.org; Mon, 26 Nov 2007 15:47:02 -0500 Received: (qmail invoked by alias); 26 Nov 2007 20:47:01 -0000 Received: from p54985274.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.82.116] by mail.gmx.net (mp006) with SMTP; 26 Nov 2007 21:47:01 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18vz94TKE8vl5fEDZ7hs6qT44gDqINOzi2LMTmwJp VptE7dX7N2xzen Message-ID: <474B30C3.7060508@gmx.net> Date: Mon, 26 Nov 2007 21:46:59 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [MEXT] Prefix delegation & Diameter Interaction References: <0MKp8S-1IwdRx2OQq-0008Gc@mrelay.perfora.net> <474B12F7.8000700@azairenet.com> <474B2270.8080405@gmx.net> <474B2FAF.4030709@gmail.com> In-Reply-To: <474B2FAF.4030709@gmail.com> 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: 79899194edc4f33a41f49410777972f8 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 Quick comment: Alexandru Petrescu wrote: > Hannes Tschofenig wrote: >> Hi Vijay, >> >> maybe you can provide some pointers to past discussions and >> conclusions. You cannot expect that everyone follows all mailing >> lists and now this work is being proposed for DIME. > > Sorry for intruding... it's difficult for someone to dig archives, as > much as it is for you. Are you saying that it is as difficult for me to find the pointer to the discussion as it is for Vijay? When I participated in discussions then I typically remember the context and roughly the time when they happened. This makes it easier to find it. Ciao Hannes _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 15:54: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 1IwkyM-0006Fw-DC; Mon, 26 Nov 2007 15:54:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwkyL-0006Fr-S6 for mext@ietf.org; Mon, 26 Nov 2007 15:54:29 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwkyL-0004qq-Gh for mext@ietf.org; Mon, 26 Nov 2007 15:54:29 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 26 Nov 2007 12:54:29 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAQKsSGo015187; Mon, 26 Nov 2007 12:54:28 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAQKsNB0015792; Mon, 26 Nov 2007 20:54:23 GMT Date: Mon, 26 Nov 2007 12:54:23 -0800 (PST) From: Sri Gundavelli To: Hannes Tschofenig Subject: Re: [MEXT] Prefix delegation & Diameter Interaction In-Reply-To: <474B30C3.7060508@gmx.net> Message-ID: References: <0MKp8S-1IwdRx2OQq-0008Gc@mrelay.perfora.net> <474B12F7.8000700@azairenet.com> <474B2270.8080405@gmx.net> <474B2FAF.4030709@gmail.com> <474B30C3.7060508@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1037; t=1196110468; x=1196974468; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20Prefix=20delegation=20&=20Diameter=20Interac tion |Sender:=20; bh=iMajpiyEYh3Y+B/GHDVBSvPMTU0O9c1S+MQAYe1477M=; b=Zb5NSte/3BQNhxZ8/vccqKSTxwEv9LoRGKxPCHcrCtX8Rhi3XkBlbMiXP7sK6HBq7Roo/F7/ CohiwaD/dkK2FAhbyYHKGOCF0IjfgLg1dR9+bWMHq3kjvmhddmPfGxHB; 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: ea4ac80f790299f943f0a53be7e1a21a 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 On Mon, 26 Nov 2007, Hannes Tschofenig wrote: > Quick comment: > > Alexandru Petrescu wrote: >> Hannes Tschofenig wrote: >> > Hi Vijay, >> > >> > maybe you can provide some pointers to past discussions and conclusions. >> > You cannot expect that everyone follows all mailing lists and now this >> > work is being proposed for DIME. >> >> Sorry for intruding... it's difficult for someone to dig archives, as much >> as it is for you. > Are you saying that it is as difficult for me to find the pointer to the > discussion as it is for Vijay? > When I participated in discussions then I typically remember the context and > roughly the time when they happened. This makes it easier to find it. > But, if the discussion took place so long ages ago. May be its worth revisiting that and to ensure the assumptions that were used for arriving at that conclusion are still valid. Or, some one can atleast state one or two arguments from that discussion, if at all, if they remember those. Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 16:15:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwlIK-00049L-O6; Mon, 26 Nov 2007 16:15:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwlIH-00046c-IO; Mon, 26 Nov 2007 16:15:05 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwlIE-0003a9-AG; Mon, 26 Nov 2007 16:15:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 44B3F328BD; Mon, 26 Nov 2007 21:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IwlIE-0003WG-5y; Mon, 26 Nov 2007 16:15:02 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Mon, 26 Nov 2007 16:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Cc: Julien Laganier , mext@ietf.org Subject: [MEXT] WG Action: Mobility EXTensions for IPv6 WG (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 A new IETF working group has been formed in the Internet Area. For additional information, please contact the Area Directors or the WG Chairs. +++ Mobility EXTensions for IPv6 (mext) ==================================== Current Status: Active Working Group Chair(s): Julien Laganier Marcelo Bagnulo 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, network mobility (NEMO) 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 (Mobile IPv6) o RFC 3963 (NEMO) o RFC 4877 (Mobile IPv6 Operation with IKEv2) The MEXT Working Group continues the work of the former 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 Mobile IPv6 and NEMO 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 Mobile IPv6 or NEMO capable dual-stack hosts. (A.2) A protocol based solution for enhancing the reliability of home agents and a method to force a host/router 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: Done Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard Done Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard. Done Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard. Dec 2007 Submit Multiple CoA Registration to IESG Dec 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational. Dec 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard. Feb 2008 Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments Feb 2008 Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments Feb 2008 Submit -00 draft on Route Optimization needs for Personal Mobile Router Feb 2008 Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational. Mar 2008 Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard May 2008 Submit -00 draft for solution to aircraft/spacecraft problem May 2008 Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational May 2008 Submit final doc on Route Optimization Needs for Automobile and Highway Deployments, for Informational May 2008 Submit final doc on Route Optimization needs for Personal Mobile Router, for Informational Jun 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. Jun 2008 Determine how to proceed with 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 the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard Aug 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Oct 2008 Submit Flow/binding policy format to IESG, for Proposed Standard Oct 2008 Submit Flow/binding policy transport to IESG, for Proposed Standard Nov 2008 Submit final doc for solution to aircraft/spacecraft problem to the IESG, for Proposed Standard Nov 2008 Recharter to work on the remaining automotive/Personal Mobile Router solutions Dec 2008 Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. Dec 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 nemo-bounces@ietf.org Mon Nov 26 16:15: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 1IwlIo-0007fU-Uq; Mon, 26 Nov 2007 16:15:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwlIi-00075N-SU; Mon, 26 Nov 2007 16:15:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwlIi-0005Oz-LO; Mon, 26 Nov 2007 16:15:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 893D82AC48; Mon, 26 Nov 2007 21:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IwlIE-0003WR-7t; Mon, 26 Nov 2007 16:15:02 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Mon, 26 Nov 2007 16:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: nemo@ietf.org, Thierry Ernst , TJ Kniveton Subject: [nemo] WG Action: Conclusion of Network Mobility WG (nemo) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org The Network Mobility WG (nemo)in the Internet Area has concluded. The IESG contact persons are Jari Arkko and Mark Townsley. The mailing list will remain active. "The work continues in the new MEXT WG, combining the Mobile IPv6 related efforts from the MIP6, NEMO, and MONAMI6 WGs. The new WG has its own mailing list. The MIP6, NEMO, and MONAMI6 mailing lists will continue to exist and the archives will be kept available. However, all discussion should be moved to mext@ietf.org instead." From mext-bounces@ietf.org Mon Nov 26 16:17: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 1IwlKn-0005gR-J8; Mon, 26 Nov 2007 16:17:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwlKl-0005Xu-UN for mext@ietf.org; Mon, 26 Nov 2007 16:17:40 -0500 Received: from deimos.multihop.net ([74.0.36.190] helo=multihop.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwlKl-0005ki-12 for mext@ietf.org; Mon, 26 Nov 2007 16:17:39 -0500 Received: by deimos.multihop.net (Postfix, from userid 1013) id 7CBB4A05F21; Mon, 26 Nov 2007 13:17:38 -0800 (PST) X-Spam-Score: -2.6 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on deimos.multihop.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.3 Received: from [192.103.16.145] (tj-desktop.nokia.net [192.103.16.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 327EFA05105; Mon, 26 Nov 2007 13:17:37 -0800 (PST) Message-ID: <474B37E8.7000200@kniveton.com> Date: Mon, 26 Nov 2007 13:17:28 -0800 From: "T.J. Kniveton" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: RYUJI WAKIKAWA Subject: Re: [MEXT] Next steps on prefix delegation References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <200711261428.27978.julien.IETF@laposte.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: mext@ietf.org, Julien Laganier 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 think that Ryuji's message shows that: If you want to select one prefix delegation mechanism for NEMO, and have it fit a situation where a mobile network is away from the home infrastructure, and have the number of messages passed be reasonably low, with low complexity... then, more engineering work is needed. As I said before, there is a reason that there are two drafts instead of one. If you consider this "several ways of doing the same thing" as per RFC 1958, then more work will be necessary to create one way of doing it that works well. If, on the other hand, you want to make the assumption that any network with NEMO will have DHCP deployed, and you are not concerned about bootstrapping a tunnel to the home network to exchange DHCP messages, then DHCP is the way to go. But in this case, the minimum effort needed would be to lay out the assumptions and have some consensus in the group that this is a reasonable engineering compromise. TJ RYUJI WAKIKAWA wrote: > Hi Julien and all, > > Agree that solo solution is always better, but I support both > solutions for MNP delegation. > > DHCP PD is simple solution, but it requires DHCP functionalities at HA > and MR. > DHDP PD seems practical when MR boots up in home network. > However, when MR boots up in foreign network, MR must creates a tunnel > to send any DHCP messages. > It means it takes several message exchanges between MR and HA to get > MNP in bootstrap. > > PMIP uses similar way of NEMO PD to assign prefix to MN during binding > registration. > If MR uses IKE for HoA assignment, it can setup a tunnel and obtain > its MNP simultaneously by initial BU. > > We have to remember that MR is also MIP6-MN. MIP6 WG standardized > several ways to assign HoA to MN. > > Another question is that shall we have a mechanism to assign HoA and > prefix at the same time? > We should update both documents or write another document how NEMO > bootstrap work > with MIP6 bootstrap mechanisms. > > There are certainly pros & cons. Operator should select one. > > regards > ryuji > > > > On 2007/11/26, at 22:28, Julien Laganier wrote: > >> Folks, >> >> Please see below: >> >> On Sunday 25 November 2007, marcelo bagnulo braun wrote: >>> Hi all, >>> >>> With respect to the NEMO prefix delegation issue, it is my opinion >>> that it would be preferred to have a single prefix delegation >>> solution rather than two. Moreover, that we should have strong >>> technical reasons to do more than one solution since this variety of >>> mechanisms without strong reasons adds needless complexity. >>> >>> So, my first question to the working group is: do you think there are >>> strong technical reasons to have more than one solution for prefix >>> delegation? >>> >>> If no, then which would be the preferred approach for prefix >>> delegation and why? >>> >>> Out goal is to try to wrap up this discussion in the next meting >> >> I would like to complement Marcelo's question with some more questions >> from my side. I am quoting below one of the Architectural Principles of >> the Internet [RFC1958]: >> >> 3.2 If there are several ways of doing the same thing, choose one. >> If a previous design, in the Internet context or elsewhere, has >> successfully solved the same problem, choose the same solution unless >> there is a good technical reason not to. Duplication of the same >> protocol functionality should be avoided as far as possible, without >> of course using this argument to reject improvements. >> >> In light of this, it seems to me that we should select one mechanism >> only for prefix delegation in the context of NEMO. If DHCPv6-PD would >> work, it seems that it should be the only solution adopted. Things are >> not that simple however and it is possible that very good reasons >> justify the specification of a new mechanism for prefix delegation in >> the context of NEMO. >> >> To help the WG understand the tradeoffs involved and make an educated >> choice, I'd like to ask the following questions: >> >> o What could possibly make the existing DHCPv6 PD unsuitable to be >> used for NEMO PD? >> >> o In case DHCPv6 is suitable but introduces limitations in the >> context of NEMO that makes it desirable to standardize another >> prefix delegation mechanism for NEMO, what would be the >> limitations? >> >> Once we have answered these questions I believe the WG will be in the >> best position to make the best choice. >> >> Cheers, >> >> --julien >> >> _______________________________________________ >> 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 > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 16:32: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 1IwlZC-0002GZ-Sc; Mon, 26 Nov 2007 16:32:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwlZB-00028T-Km for mext@ietf.org; Mon, 26 Nov 2007 16:32:33 -0500 Received: from smtp7-g19.free.fr ([212.27.42.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwlZB-0007yh-56 for mext@ietf.org; Mon, 26 Nov 2007 16:32:33 -0500 Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id CECAF322807; Mon, 26 Nov 2007 22:32:31 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp7-g19.free.fr (Postfix) with ESMTP id 69E823227F5; Mon, 26 Nov 2007 22:32:31 +0100 (CET) Message-ID: <474B3B6E.1010709@gmail.com> Date: Mon, 26 Nov 2007 22:32:30 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Behcet Sarikaya Subject: Re: [MEXT] Next steps on prefix delegation References: <18771.36792.qm@web84110.mail.mud.yahoo.com> In-Reply-To: <18771.36792.qm@web84110.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071124-0, 24/11/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Behcet Sarikaya wrote: > Hi Ryuji, DHCP PD does not require DHCP functionality at the MR. On a certain axis one would trade among these: -if MR and HA are DHCP entities then run DHCP-PD unmodified over that tunnel. -if MR is DHCP entity but HA must not run DHCP then some MIP6 extensions and some implementation are necessary. -if MR and HA can not be DHCP entities then do some more MIP6 extensions and some more implementation and rely entirely on MIP6. If the HA can not be a Relay nor a Server then it's complicated IMHO: assuming the MR already has a Home Address and knows the address of the DHCP Server in the home network then it's sufficient for it to run a MRHA-encapsulated unicast DHCP Request/Ack exchange with it. If it doesn't know the address of the DHCP Server (but does have a HoA) then it has to go through the multicast Solicit/Advertise exchange before the Req/Ack unicast exchange. Or, multicast behaviour and scope between the MR-HA tunnel and the home link is currently undefined. > HA can get a prefix for MR even if MR boots up in foreign network. Huh? You mean HA to get a prefix for MR as if the HA were a DHCP Client? And then act as a DHCP Server and the MR as a DHCP Client? "Get"? Alex _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 16:44: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 1Iwll2-0005hj-9f; Mon, 26 Nov 2007 16:44:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwll1-0005he-4c for mext@ietf.org; Mon, 26 Nov 2007 16:44:47 -0500 Received: from deimos.multihop.net ([74.0.36.190] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwlky-0007mg-Gq for mext@ietf.org; Mon, 26 Nov 2007 16:44:47 -0500 Received: by deimos.multihop.net (Postfix, from userid 1013) id A6D34A064A8; Mon, 26 Nov 2007 13:44:43 -0800 (PST) X-Spam-Score: -2.6 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on deimos.multihop.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.3 Received: from [192.103.16.145] (tj-desktop.nokia.net [192.103.16.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 0578EA06225; Mon, 26 Nov 2007 13:44:41 -0800 (PST) Message-ID: <474B3E3F.4080004@kniveton.com> Date: Mon, 26 Nov 2007 13:44:31 -0800 From: "T.J. Kniveton" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Julien Laganier Subject: Re: [MEXT] Next steps on prefix delegation References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <200711261428.27978.julien.IETF@laposte.net> In-Reply-To: <200711261428.27978.julien.IETF@laposte.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Since Julien brought up RFC 1958, let's talk a little bit more about Internet engineering philosophy: IPv6 was designed so that a node can obtain an address by: 1. Stateless configuration. The node receives a router advertisement and constructs an address by appending its own suffix, using neighbor discovery to ensure it's unique. 2. Stateful configuration. An authoritative DHCP infrastructure is in place, and the end node queries the DHCP server(s), and it receives an address, and other associated configuration data. (Note: these are two methods for accomplishing the same goal.) Now throughout the Mobile IP(v6) engineering effort, there has been a largely unspoken assumption that we should continue to use a stateless configuration paradigm. That is why we have things like Dynamic Home Agent Address Discovery, Mobile Prefix Solicitation/Advertisements, bootstrapping, etc. Otherwise, we would just rely on a big DHCP brain in the sky to tell the end node all of its configuration information. The way I see it, using option #1 means that we are furthering the Internet protocol capabilities while remaining consistent with the long-standing ideal that the intelligence lies in end nodes, not in the network. In writing the prefix delegation draft, it was my intention to continue the above-mentioned ideal, and allow nodes to request a prefix directly from whence they are being managed in some cases (such as where Vijay pointed out), in the HA. [Note: I do not agree with your supposition that receiving a prefix is tantamount to stateful address configuration: when I bind a home address to a care-of address, or assign myself a care-of address using stateless address autoconfiguration, neither one involves the use of DHCP.] So, the question is this: do we want to continue the evolution of the protocol suite that includes IPv6, Mobile IPv6, and NEMO, and have a mechanism for requesting use of a prefix, or do we want to say, well, this is too complicated; if you want to do this, you are going to need to install a DHCP infrastructure.? So far, it seemed logical to describe both methods and allow people to decide how they want to implement a system. However, if we are restricted to standardizing one method, more study is needed of realistically deployable systems to determine which direction is better to go in, and to understand the implications. I have been waiting a couple years and have not seen these prefix delegation schemes be implemented yet, so further study, IMHO, is necessary before declaring that "DHCP makes sense" or "most IPv6 networks will have DHCPv6 services deployed" and we should just go that direction. TJ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 16:58: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 1IwlyT-0001iq-Rz; Mon, 26 Nov 2007 16:58:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwlyS-0001ig-Nn for mext@ietf.org; Mon, 26 Nov 2007 16:58:40 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IwlyS-0003Mo-BI for mext@ietf.org; Mon, 26 Nov 2007 16:58:40 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1196114319!34679828!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 12548 invoked from network); 26 Nov 2007 21:58:39 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-4.tower-119.messagelabs.com with SMTP; 26 Nov 2007 21:58:39 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lAQLwdGI004900; Mon, 26 Nov 2007 14:58:39 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id lAQLwcdu022442; Mon, 26 Nov 2007 15:58:38 -0600 (CST) Received: from [127.0.0.1] (mvp-10-169-5-44.corp.mot.com [10.169.5.44]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id lAQLwYpJ022404; Mon, 26 Nov 2007 15:58:35 -0600 (CST) Message-ID: <474B4189.3040008@gmail.com> Date: Mon, 26 Nov 2007 22:58:33 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [MEXT] Prefix delegation & Diameter Interaction References: <0MKp8S-1IwdRx2OQq-0008Gc@mrelay.perfora.net> <474B12F7.8000700@azairenet.com> <474B2270.8080405@gmx.net> <474B2FAF.4030709@gmail.com> <474B30C3.7060508@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071124-0, 24/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Hannes Tschofenig , 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 Sri Gundavelli wrote: > > > On Mon, 26 Nov 2007, Hannes Tschofenig wrote: > >> Quick comment: >> >> Alexandru Petrescu wrote: >>> Hannes Tschofenig wrote: >>> > Hi Vijay, >>> > > maybe you can provide some pointers to past discussions and >>> conclusions. > You cannot expect that everyone follows all mailing >>> lists and now this > work is being proposed for DIME. >>> >>> Sorry for intruding... it's difficult for someone to dig archives, >>> as much >>> as it is for you. >> Are you saying that it is as difficult for me to find the pointer to >> the discussion as it is for Vijay? >> When I participated in discussions then I typically remember the >> context and roughly the time when they happened. This makes it easier >> to find it. >> > > But, if the discussion took place so long ages ago. May be its > worth revisiting that and to ensure the assumptions that were > used for arriving at that conclusion are still valid. Or, some > one can atleast state one or two arguments from that discussion, > if at all, if they remember those. For example, some thing I remember vaguely. But there are surely many other people here with more rememberings. If MIP6 doesn't rely on a mechanism to auto-configure an address, and works independently of it - then some people could plug AAA with MIP6, others could plug SLAAC with it. Or similar. So, if one would go along same lines, one wouldn't build AAA into MIP6 for delivering the home prefix to the MR. A related question: when a PDA router connects to a IPv6 infrastructure, and obtains a prefix with Diameter, or ppp, from the AAA infrastructure - would it _have_ to run NEMO-extended-MIP6? Maybe not. Alex > > > Sri > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 17:40:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwmd5-00020Z-R5; Mon, 26 Nov 2007 17:40:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwmd0-0001zz-Vb for mext@ietf.org; Mon, 26 Nov 2007 17:40:35 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iwmd0-00030T-4Y for mext@ietf.org; Mon, 26 Nov 2007 17:40:34 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1196116832!10714778!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 23492 invoked from network); 26 Nov 2007 22:40:32 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-10.tower-128.messagelabs.com with SMTP; 26 Nov 2007 22:40:32 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id lAQMeIjN003634; Mon, 26 Nov 2007 15:40:23 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lAQMeHIT019311; Mon, 26 Nov 2007 16:40:18 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.217]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lAQMeEqG019285; Mon, 26 Nov 2007 16:40:15 -0600 (CST) Message-ID: <474B4B4E.2050307@gmail.com> Date: Mon, 26 Nov 2007 23:40:14 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "T.J. Kniveton" Subject: Re: [MEXT] Next steps on prefix delegation References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <200711261428.27978.julien.IETF@laposte.net> <474B3E3F.4080004@kniveton.com> In-Reply-To: <474B3E3F.4080004@kniveton.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071125-0, 25/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: mext@ietf.org, Julien Laganier 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 T.J. Kniveton wrote: > Since Julien brought up RFC 1958, let's talk a little bit more about > Internet engineering philosophy: > > IPv6 was designed so that a node can obtain an address by: > > 1. Stateless configuration. The node receives a router advertisement > and constructs an address by appending its own suffix, using > neighbor discovery to ensure it's unique. > > 2. Stateful configuration. An authoritative DHCP infrastructure is in > place, and the end node queries the DHCP server(s), and it receives > an address, and other associated configuration data. > > (Note: these are two methods for accomplishing the same goal.) > > Now throughout the Mobile IP(v6) engineering effort, there has been a > largely unspoken assumption that we should continue to use a > stateless configuration paradigm. That is why we have things like > Dynamic Home Agent Address Discovery, Mobile Prefix > Solicitation/Advertisements, bootstrapping, etc. I agree with these and I support both of them. > Otherwise, we would just rely on a big DHCP brain in the sky to tell > the end node all of its configuration information. Well I share your view of prefering distributed systems, and at the same time there must be somebody up there already telling the deployed routers what to put in their RAs and on their interfaces. > The way I see it, using option #1 means that we are furthering the > Internet protocol capabilities while remaining consistent with the > long-standing ideal that the intelligence lies in end nodes, not in > the network. > > In writing the prefix delegation draft, it was my intention to > continue the above-mentioned ideal, and allow nodes to request a > prefix directly from whence they are being managed in some cases > (such as where Vijay pointed out), in the HA. > > [Note: I do not agree with your supposition that receiving a prefix > is tantamount to stateful address configuration: when I bind a home > address to a care-of address, or assign myself a care-of address > using stateless address autoconfiguration, neither one involves the > use of DHCP.] HA another stateful Server? I suppose yes: It simply must maintain states about that allocated prefix so not to allocate it to somebody else. Would HA run extended-DAD to make sure nobody on the home link uses the prefix it's about to allocate? For a start I don't know how to relate two prefixes one to another: are they equal? are they aggregated? > So, the question is this: do we want to continue the evolution of the > protocol suite that includes IPv6, Mobile IPv6, and NEMO, and have a > mechanism for requesting use of a prefix, or do we want to say, > well, this is too complicated; Hehe > if you want to do this, you are going to need to install a DHCP > infrastructure.? > > So far, it seemed logical to describe both methods and allow people > to decide how they want to implement a system. However, if we are > restricted to standardizing one method, more study is needed of > realistically deployable systems to determine which direction is > better to go in, and to understand the implications. I have been > waiting a couple years and have not seen these prefix delegation > schemes be implemented yet, Not sure what you mean... but Dibbler seems to be doing DHCPv6-PD. I do share many of the opinions you expressed above. Alex > so further study, IMHO, is necessary > before declaring that "DHCP makes sense" or "most IPv6 networks will > have DHCPv6 services deployed" and we should just go that direction. > > > TJ > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 17:44:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwmgh-00047B-3l; Mon, 26 Nov 2007 17:44:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwmgf-00043j-Gn for mext@ietf.org; Mon, 26 Nov 2007 17:44:22 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iwmge-0003po-Om for mext@ietf.org; Mon, 26 Nov 2007 17:44:21 -0500 Received: (qmail 6671 invoked for bounce); 26 Nov 2007 22:44:19 -0000 Received: from unknown (HELO ?192.168.0.10?) (kuntz@unknown) by unknown with RC4-SHA encrypted SMTP; 26 Nov 2007 22:44:19 -0000 Message-Id: <690A0CEE-BA3C-4465-851B-0CBCF564B19B@clarinet.u-strasbg.fr> From: Romain KUNTZ To: Julien Laganier In-Reply-To: <200711261922.42067.julien.IETF@laposte.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [MEXT] Next steps on prefix delegation Date: Mon, 26 Nov 2007 23:44:18 +0100 References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <200711261428.27978.julien.IETF@laposte.net> <200711261922.42067.julien.IETF@laposte.net> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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 Julien, Ryuji, On 2007/11/26, at 19:22, Julien Laganier wrote: >> Another question is that shall we have a mechanism to assign HoA and >> prefix at the same time? > > I don't think so, this looks like an optimization on something that > isn't time critical anyway. What would be the point of coupling these > two, maybe I'm missing something. Modularity is a feature IMHO. > > >> We should update both documents or write another document how NEMO >> bootstrap work with MIP6 bootstrap mechanisms. Yes that point was raised in one of the original mail that started this discussion. The MIP6 bootstrapping work defined 2 scenarios: split and integrated. In the split case, the Mobility Service Authorizer is separated from the Mobility Service Provider. It relies on a backend AAA architecture where the HA contacts the MSA to authenticate the MN and authorize the mobility service. When delegating prefixes in the split scenario, the HA would also need to rely on that architecture, e.g. to authorize a prefix that the MR claims. It would thus make sense to build a delegation mechanism partly based on the MIP6 work. Different point: I'd also like to add that draft-ietf-nemo-prefix- delegation raises some issue when the MR boots in the home network : how does the MR gets a prefix as long as it does not send BU? Cheers, romain >> On 2007/11/26, at 22:28, Julien Laganier wrote: >>> Folks, >>> >>> Please see below: >>> >>> On Sunday 25 November 2007, marcelo bagnulo braun wrote: >>>> Hi all, >>>> >>>> With respect to the NEMO prefix delegation issue, it is my opinion >>>> that it would be preferred to have a single prefix delegation >>>> solution rather than two. Moreover, that we should have strong >>>> technical reasons to do more than one solution since this variety >>>> of mechanisms without strong reasons adds needless complexity. >>>> >>>> So, my first question to the working group is: do you think there >>>> are strong technical reasons to have more than one solution for >>>> prefix delegation? >>>> >>>> If no, then which would be the preferred approach for prefix >>>> delegation and why? >>>> >>>> Out goal is to try to wrap up this discussion in the next meting >>> >>> I would like to complement Marcelo's question with some more >>> questions from my side. I am quoting below one of the Architectural >>> Principles of >>> the Internet [RFC1958]: >>> >>> 3.2 If there are several ways of doing the same thing, choose >>> one. If a previous design, in the Internet context or elsewhere, >>> has successfully solved the same problem, choose the same solution >>> unless >>> there is a good technical reason not to. Duplication of the >>> same protocol functionality should be avoided as far as possible, >>> without >>> of course using this argument to reject improvements. >>> >>> In light of this, it seems to me that we should select one >>> mechanism only for prefix delegation in the context of NEMO. If >>> DHCPv6-PD would work, it seems that it should be the only solution >>> adopted. Things are not that simple however and it is possible that >>> very good reasons justify the specification of a new mechanism for >>> prefix delegation in the context of NEMO. >>> >>> To help the WG understand the tradeoffs involved and make an >>> educated choice, I'd like to ask the following questions: >>> >>> o What could possibly make the existing DHCPv6 PD unsuitable to >>> be used for NEMO PD? >>> >>> o In case DHCPv6 is suitable but introduces limitations in the >>> context of NEMO that makes it desirable to standardize another >>> prefix delegation mechanism for NEMO, what would be the >>> limitations? >>> >>> Once we have answered these questions I believe the WG will be in >>> the best position to make the best choice. >>> >>> Cheers, >>> >>> --julien >>> >>> _______________________________________________ >>> 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 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 18:44:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwncu-0003da-2B; Mon, 26 Nov 2007 18:44:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwncs-0003a2-LU for mext@ietf.org; Mon, 26 Nov 2007 18:44:30 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwncp-00067n-3U for mext@ietf.org; Mon, 26 Nov 2007 18:44:30 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 26 Nov 2007 15:44:26 -0800 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 lAQNiQhQ026068; Mon, 26 Nov 2007 15:44:26 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAQNiQb5022040; Mon, 26 Nov 2007 23:44:26 GMT Date: Mon, 26 Nov 2007 15:44:25 -0800 (PST) From: Sri Gundavelli To: Alexandru Petrescu Subject: Re: [MEXT] Prefix delegation & Diameter Interaction In-Reply-To: <474B4189.3040008@gmail.com> Message-ID: References: <0MKp8S-1IwdRx2OQq-0008Gc@mrelay.perfora.net> <474B12F7.8000700@azairenet.com> <474B2270.8080405@gmx.net> <474B2FAF.4030709@gmail.com> <474B30C3.7060508@gmx.net> <474B4189.3040008@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1744; t=1196120666; x=1196984666; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20Prefix=20delegation=20&=20Diameter=20Interac tion |Sender:=20; bh=zjSGZe5TdxbPI+No2kw0JXWdzezSt41VwbkLRTTyS18=; b=GdmLZyy3RpXvKw6WSvjGxJ+ba3ty9JnUDBCo1hii3gU54/SnHsaNDRfMnaCKn575KH2iGKlL rffcAr0V69eOfl7vTZo2xONvy+2ORKXqf/uhPc8OdPV5xzulWUmwe3dv; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Hannes Tschofenig , 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 On Mon, 26 Nov 2007, Alexandru Petrescu wrote: >> But, if the discussion took place so long ages ago. May be its >> worth revisiting that and to ensure the assumptions that were >> used for arriving at that conclusion are still valid. Or, some >> one can atleast state one or two arguments from that discussion, >> if at all, if they remember those. > > For example, some thing I remember vaguely. But there are surely many other > people here with more rememberings. > > If MIP6 doesn't rely on a mechanism to auto-configure an address, and works > independently of it - then some people could plug AAA with MIP6, others could > plug SLAAC with it. Or similar. > > So, if one would go along same lines, one wouldn't build AAA into MIP6 for > delivering the home prefix to the MR. > Thanks Alex for the info. In such configurations of physical home link and when the MN can use SLAAC to configure an address and with little involvement of MIP6, keeping an external entity out of this, would probably make sense. Would that be the same when the links are virtual and when the address is a prefix, the assignment is always from the HA and how it obtains that info, can be through multiple ways, including DHCP-PD and AAA for cases of static HNP in a user profile. All though, DHCP-PD makes lot of sense for prefix/address mgmt, but the ability to bootstrap just from a profile with static address might be required. > A related question: when a PDA router connects to a IPv6 infrastructure, and > obtains a prefix with Diameter, or ppp, from the AAA infrastructure - would > it _have_ to run NEMO-extended-MIP6? Maybe not. > No, in such case the prefix is anchored on that PDA. Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 26 19: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 1Iwns8-0001kI-Pm; Mon, 26 Nov 2007 19:00:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwns6-0001iE-Ui for mext@ietf.org; Mon, 26 Nov 2007 19:00:15 -0500 Received: from web84107.mail.mud.yahoo.com ([68.142.206.194]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iwns6-0000JB-9h for mext@ietf.org; Mon, 26 Nov 2007 19:00:14 -0500 Received: (qmail 11074 invoked by uid 60001); 27 Nov 2007 00:00:13 -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=k/sWOFeMr5NZT3KTxJbjOZKlda3juIlNIkFds8wQ5Mr00bl/MSH7ngHme+ILeZLv2NVNWNwkq9dzOVUGCTiaHpQxAnpNN/pgdpt7nWVeqFHpPG7v57QPf5pQQq+pyV6qit11cepnlmETYCIQv3ycPvrjBT6vYNvakU1hyNRkwuw=; X-YMail-OSG: gEB.HH0VM1nSZvlG71FTe0Rh6Q43RWBjR_XzQYsW2tN6JGGA5AbRbvNnUzZcwsqYxjUDlZo9iucBTSR0L3TMMV4q5ADzM5n1TpwA75sYjE2DyIw- Received: from [206.16.17.212] by web84107.mail.mud.yahoo.com via HTTP; Mon, 26 Nov 2007 16:00:13 PST X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.152 Date: Mon, 26 Nov 2007 16:00:13 -0800 (PST) From: Behcet Sarikaya Subject: Re: [MEXT] Next steps on prefix delegation To: Alexandru Petrescu MIME-Version: 1.0 Message-ID: <688913.11071.qm@web84107.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1277225620==" Errors-To: mext-bounces@ietf.org --===============1277225620== Content-Type: multipart/alternative; boundary="0-1360639337-1196121613=:11071" --0-1360639337-1196121613=:11071 Content-Type: text/plain; charset=us-ascii Alex, I think you are right. As it is described in draft-ietf-nemo-dhcpv6-pd-02 MR is RR and HA is DR. Because of this Ryuji's concerns hold. My apologies, I misunderstood this draft. Regards, Behcet ----- Original Message ---- From: Alexandru Petrescu To: Behcet Sarikaya Cc: mext@ietf.org Sent: Monday, November 26, 2007 3:32:30 PM Subject: Re: [MEXT] Next steps on prefix delegation Behcet Sarikaya wrote: > Hi Ryuji, DHCP PD does not require DHCP functionality at the MR. On a certain axis one would trade among these: -if MR and HA are DHCP entities then run DHCP-PD unmodified over that tunnel. -if MR is DHCP entity but HA must not run DHCP then some MIP6 extensions and some implementation are necessary. -if MR and HA can not be DHCP entities then do some more MIP6 extensions and some more implementation and rely entirely on MIP6. If the HA can not be a Relay nor a Server then it's complicated IMHO: assuming the MR already has a Home Address and knows the address of the DHCP Server in the home network then it's sufficient for it to run a MRHA-encapsulated unicast DHCP Request/Ack exchange with it. If it doesn't know the address of the DHCP Server (but does have a HoA) then it has to go through the multicast Solicit/Advertise exchange before the Req/Ack unicast exchange. Or, multicast behaviour and scope between the MR-HA tunnel and the home link is currently undefined. > HA can get a prefix for MR even if MR boots up in foreign network. Huh? You mean HA to get a prefix for MR as if the HA were a DHCP Client? And then act as a DHCP Server and the MR as a DHCP Client? "Get"? Alex _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --0-1360639337-1196121613=:11071 Content-Type: text/html; charset=us-ascii
Alex, I think you are right. As it is described in draft-ietf-nemo-dhcpv6-pd-02 MR is RR and HA is DR. Because of this Ryuji's concerns hold.
My apologies, I misunderstood this draft.

Regards,

Behcet

----- Original Message ----
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: mext@ietf.org
Sent: Monday, November 26, 2007 3:32:30 PM
Subject: Re: [MEXT] Next steps on prefix delegation

Behcet Sarikaya wrote:
> Hi Ryuji, DHCP PD does not require DHCP functionality at the MR.

On a certain axis one would trade among these:
-if MR and HA are DHCP entities then run DHCP-PD unmodified over that
  tunnel.
-if MR is DHCP entity but HA must not run DHCP then some MIP6
  extensions  and some implementation are necessary.
-if MR and HA can not be DHCP entities then do some more MIP6 extensions
  and some more implementation and rely entirely on MIP6.

If the HA can not be a Relay nor a Server then it's complicated IMHO:
assuming the MR already has a Home Address and knows the address of the
DHCP Server in the home network then it's sufficient for it to run a
MRHA-encapsulated unicast DHCP Request/Ack exchange with it.  If it
doesn't know the address of the DHCP Server (but does have a HoA) then
it has to go through the multicast Solicit/Advertise exchange before the
Req/Ack unicast exchange.  Or, multicast behaviour and scope between the
MR-HA tunnel and the home link is currently undefined.

> HA can get a prefix for MR even if MR boots up in foreign network.

Huh?  You mean HA to get a prefix for MR as if the HA were a DHCP
Client?  And then act as a DHCP Server and the MR as a DHCP Client?   "Get"?

Alex


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

--0-1360639337-1196121613=:11071-- --===============1277225620== 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 --===============1277225620==-- From mext-bounces@ietf.org Mon Nov 26 19:17:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwo96-0002TA-Ki; Mon, 26 Nov 2007 19:17:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwo95-0002T4-7a for mext@ietf.org; Mon, 26 Nov 2007 19:17:47 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwo94-0000u4-DK for mext@ietf.org; Mon, 26 Nov 2007 19:17:46 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Nov 2007 16:17:45 -0800 Message-ID: <474B6228.4050302@azairenet.com> Date: Mon, 26 Nov 2007 16:17:44 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Romain KUNTZ Subject: Re: [MEXT] Next steps on prefix delegation References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <200711261428.27978.julien.IETF@laposte.net> <200711261922.42067.julien.IETF@laposte.net> <690A0CEE-BA3C-4465-851B-0CBCF564B19B@clarinet.u-strasbg.fr> In-Reply-To: <690A0CEE-BA3C-4465-851B-0CBCF564B19B@clarinet.u-strasbg.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2007 00:17:45.0367 (UTC) FILETIME=[EF039A70:01C8308A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: mext@ietf.org, Julien Laganier 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 Romain KUNTZ wrote: > Hi Julien, Ryuji, > > On 2007/11/26, at 19:22, Julien Laganier wrote: >>> Another question is that shall we have a mechanism to assign HoA and >>> prefix at the same time? >> >> I don't think so, this looks like an optimization on something that >> isn't time critical anyway. What would be the point of coupling these >> two, maybe I'm missing something. Modularity is a feature IMHO. >> >> >>> We should update both documents or write another document how NEMO >>> bootstrap work with MIP6 bootstrap mechanisms. > > Yes that point was raised in one of the original mail that started this > discussion. > The MIP6 bootstrapping work defined 2 scenarios: split and integrated. > In the split case, the Mobility Service Authorizer is separated from the > Mobility Service Provider. It relies on a backend AAA architecture where > the HA contacts the MSA to authenticate the MN and authorize the > mobility service. When delegating prefixes in the split scenario, the HA > would also need to rely on that architecture, e.g. to authorize a prefix > that the MR claims. It would thus make sense to build a delegation > mechanism partly based on the MIP6 work. > > Different point: I'd also like to add that > draft-ietf-nemo-prefix-delegation raises some issue when the MR boots in > the home network : how does the MR gets a prefix as long as it does not > send BU? It cannot. We need to take a closer look at booting up in the home link. There are other issues as well. Vijay > > Cheers, > romain > > > >>> On 2007/11/26, at 22:28, Julien Laganier wrote: >>>> Folks, >>>> >>>> Please see below: >>>> >>>> On Sunday 25 November 2007, marcelo bagnulo braun wrote: >>>>> Hi all, >>>>> >>>>> With respect to the NEMO prefix delegation issue, it is my opinion >>>>> that it would be preferred to have a single prefix delegation >>>>> solution rather than two. Moreover, that we should have strong >>>>> technical reasons to do more than one solution since this variety >>>>> of mechanisms without strong reasons adds needless complexity. >>>>> >>>>> So, my first question to the working group is: do you think there >>>>> are strong technical reasons to have more than one solution for >>>>> prefix delegation? >>>>> >>>>> If no, then which would be the preferred approach for prefix >>>>> delegation and why? >>>>> >>>>> Out goal is to try to wrap up this discussion in the next meting >>>> >>>> I would like to complement Marcelo's question with some more >>>> questions from my side. I am quoting below one of the Architectural >>>> Principles of >>>> the Internet [RFC1958]: >>>> >>>> 3.2 If there are several ways of doing the same thing, choose >>>> one. If a previous design, in the Internet context or elsewhere, >>>> has successfully solved the same problem, choose the same solution >>>> unless >>>> there is a good technical reason not to. Duplication of the >>>> same protocol functionality should be avoided as far as possible, >>>> without >>>> of course using this argument to reject improvements. >>>> >>>> In light of this, it seems to me that we should select one >>>> mechanism only for prefix delegation in the context of NEMO. If >>>> DHCPv6-PD would work, it seems that it should be the only solution >>>> adopted. Things are not that simple however and it is possible that >>>> very good reasons justify the specification of a new mechanism for >>>> prefix delegation in the context of NEMO. >>>> >>>> To help the WG understand the tradeoffs involved and make an >>>> educated choice, I'd like to ask the following questions: >>>> >>>> o What could possibly make the existing DHCPv6 PD unsuitable to >>>> be used for NEMO PD? >>>> >>>> o In case DHCPv6 is suitable but introduces limitations in the >>>> context of NEMO that makes it desirable to standardize another >>>> prefix delegation mechanism for NEMO, what would be the >>>> limitations? >>>> >>>> Once we have answered these questions I believe the WG will be in >>>> the best position to make the best choice. >>>> >>>> Cheers, >>>> >>>> --julien >>>> >>>> _______________________________________________ >>>> 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 > > > _______________________________________________ > 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 Mon Nov 26 22:06: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 1IwqmC-0005ds-2l; Mon, 26 Nov 2007 22:06:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwqm1-0005Ul-EU for mext@ietf.org; Mon, 26 Nov 2007 22:06:09 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwqly-00017F-Ld for mext@ietf.org; Mon, 26 Nov 2007 22:06:09 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id lAR363XL019860; Tue, 27 Nov 2007 12:06:03 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id lAR364s08657; Tue, 27 Nov 2007 12:06:04 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with ESMTP id lAR364M02369; Tue, 27 Nov 2007 12:06:04 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 11:05:52 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Tue, 27 Nov 2007 11:05:49 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Tue, 27 Nov 2007 11:05:49 +0800 From: "Benjamin Lim" To: "'RYUJI WAKIKAWA'" Subject: RE: [MEXT] Comments on draft-ietf-monami6-multiplecoa-04.txt Date: Tue, 27 Nov 2007 11:05:48 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcgwSZQxmDxcsvhHQWe/sRqQhfuyXgAUVJ2w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Message-ID: X-OriginalArrivalTime: 27 Nov 2007 03:05:52.0487 (UTC) FILETIME=[6B67F770:01C830A2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 Ryuji, My response to one of your comment inline. =8==8<=8== > > Also, I feel that other considerations on what impact would > MN trigger > > when using bulk registration. For instance, in my recently > submitted > > ID > > > (http://www.ietf.org/internet-drafts/draft-lim-mext-multiple-coa-verif > > y-00.t xt), I mention MN using bulk registration might be > able to bind > > CoAs of victims at HA and thereby leading to a flooding attack to > > those victims. I believe it is worth taking such issue into > > consideration. > > Thanks for writing that document. > We discussed this issue on Monami6 ML before. > > I am still not sure how serious this attack is. > When the MN sends bulk-BU to HA, the MN has to create IPsec > SA with the HA. [Ben] Yes IPsec protects the BU from any form of man-in-the middle modification to the contents of the BU. But how can HA be sure that MN is not the one being malicious. This is the problem we highlight in our draft (that MN could be the malicious node). If you say, the identity of MN is known to HA, we re-iterated in our draft providing an example that having the identity known does not deter such attacks from being launched. > The scenario looks very limited because not all the nodes can > launch the attack. [Ben] True, but you do not need all nodes to launch the attack. Just a Monami6 node launching the attack is at most equivalent to all nodes launching the attack. > Even RFC3775 does not verify CoA for home registration. [Ben] RFC3775 assumes trust for home registration. More than likely, the CoA is specified in the source address field of the packet hence ingress filtering can be assumed to be performed. Even if AltCoA option used, in RFC3775, at most MN can only specify one AltCoA binding. But in bulk registration, MN can specify more than one CoA to be bound at HA. Furthermore, only one of these CoAs is specified in the source address field of the BU. The rest are specified in the BU itself. Hence, this increases the risk of not knowing if they are actually valid routing address to MN that HA has to take when binding these CoAs. Thus, it might be worth considering in this case for HA to perform some procedure in order to lessen such risk. I believe that most of the question/answer is as per what we have discussed on the Monami6 ML. Hopefully, this mail will clarify your doubts on such issue. Regards, Benjamin Lim > > regards, > ryuji _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From AddiesprigBrunson@willieruff.com Tue Nov 27 01:40:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwu7P-0005tJ-Jl; Tue, 27 Nov 2007 01:40:27 -0500 Received: from p5b2a4c7b.dip.t-dialin.net ([91.42.76.123] helo=nassermn35fp0x) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iwu7O-0003gQ-R6; Tue, 27 Nov 2007 01:40:27 -0500 Message-ID: <2980301c830c1$3da983c0$7700a8c0@nassermn35fp0x> From: "Ronda Prater" To: Subject: Hi Date: Tue, 27 Nov 2007 07:46:08 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_297FF_01C830C1.3DA983C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_297FF_01C830C1.3DA983C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_297FF_01C830C1.3DA983C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_297FF_01C830C1.3DA983C0-- From mext-bounces@ietf.org Tue Nov 27 03:38: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 1Iwvxh-0003Na-10; Tue, 27 Nov 2007 03:38:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwvxf-0003IY-Kt for mext@ietf.org; Tue, 27 Nov 2007 03:38:31 -0500 Received: from hpsmtp-eml17.kpnxchange.com ([213.75.38.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwvxa-0002vf-LD for mext@ietf.org; Tue, 27 Nov 2007 03:38:31 -0500 Received: from hpsmtp-eml01.kpnxchange.com ([213.75.38.101]) by hpsmtp-eml17.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 09:38:26 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml01.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 09:38:25 +0100 From: "Teco Boot" To: References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <200711261428.27978.julien.IETF@laposte.net> <474B3E3F.4080004@kniveton.com> In-Reply-To: <474B3E3F.4080004@kniveton.com> Subject: RE: [MEXT] Next steps on prefix delegation Date: Tue, 27 Nov 2007 09:38:23 +0100 Message-ID: <001c01c830d0$e079d230$a16d7690$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgwddOiIlObo50mSqSIV+HmhrBDnQAWReOA Content-Language: nl X-OriginalArrivalTime: 27 Nov 2007 08:38:26.0020 (UTC) FILETIME=[E0A37A40:01C830D0] X-Spam-Score: -1.0 (-) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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, I want to better understand this discussion. I think we want to define a protocol for getting a prefix to be used for MNP, correct? This cannot be provided by stateless configuration, correct? Prefixes are always managed. ULA are somewhat the exception, I prefer keeping this is out-of-scope. So we need some kind of authority, providing prefixes. And MRs request prefixes. In all configuration databases, state of all leases is maintained. Now we need a protocol for requesting and delegation prefixes. Maybe we want some nesting, e.g. a MR may delegate prefixes downwards. For a protocol point of view, this is not important. Currently, we have some mechanisms, like DHCP-PD and some AAA protocols for the same functionality. All protocols shall manage prefixes consistent, e.g. uniqueness, expiration timers etc. Now the question is, do current protocols fit requirements for Mobile Routers requesting prefixes. If not, we can design new protocols or extent current protocols. I think there should not be any limitation on running multiple protocols, e.g. a Prefix Delegation Server runs DHCP, DHCP-PD, some AAA-PD and new PD protocols. Same for MR. I wanted to make clear there is no separation between DHCP server and other servers managing prefixes. It is about the protocols being used. Teco. > -----Oorspronkelijk bericht----- > Van: T.J. Kniveton [mailto:tj@kniveton.com] > Verzonden: maandag 26 november 2007 22:45 > Aan: Julien Laganier > CC: mext@ietf.org > Onderwerp: Re: [MEXT] Next steps on prefix delegation > > Since Julien brought up RFC 1958, let's talk a little bit more about > Internet engineering philosophy: > > IPv6 was designed so that a node can obtain an address by: > > 1. Stateless configuration. The node receives a router advertisement > and > constructs an address by appending its own suffix, using neighbor > discovery to ensure it's unique. > > 2. Stateful configuration. An authoritative DHCP infrastructure is in > place, and the end node queries the DHCP server(s), and it receives an > address, and other associated configuration data. > > (Note: these are two methods for accomplishing the same goal.) > > Now throughout the Mobile IP(v6) engineering effort, there has been a > largely unspoken assumption that we should continue to use a stateless > configuration paradigm. That is why we have things like Dynamic Home > Agent Address Discovery, Mobile Prefix Solicitation/Advertisements, > bootstrapping, etc. Otherwise, we would just rely on a big DHCP brain > in > the sky to tell the end node all of its configuration information. The > way I see it, using option #1 means that we are furthering the Internet > protocol capabilities while remaining consistent with the long-standing > ideal that the intelligence lies in end nodes, not in the network. > > In writing the prefix delegation draft, it was my intention to continue > the above-mentioned ideal, and allow nodes to request a prefix directly > from whence they are being managed in some cases (such as where Vijay > pointed out), in the HA. > > [Note: I do not agree with your supposition that receiving a prefix is > tantamount to stateful address configuration: when I bind a home > address > to a care-of address, or assign myself a care-of address using > stateless > address autoconfiguration, neither one involves the use of DHCP.] > > So, the question is this: do we want to continue the evolution of the > protocol suite that includes IPv6, Mobile IPv6, and NEMO, and have a > mechanism for requesting use of a prefix, or do we want to say, well, > this is too complicated; if you want to do this, you are going to need > to install a DHCP infrastructure.? > > So far, it seemed logical to describe both methods and allow people to > decide how they want to implement a system. However, if we are > restricted to standardizing one method, more study is needed of > realistically deployable systems to determine which direction is better > to go in, and to understand the implications. I have been waiting a > couple years and have not seen these prefix delegation schemes be > implemented yet, so further study, IMHO, is necessary before declaring > that "DHCP makes sense" or "most IPv6 networks will have DHCPv6 > services > deployed" and we should just go that direction. > > TJ > > _______________________________________________ > 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 Nov 27 03:42: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 1Iww1N-0007Cw-JK; Tue, 27 Nov 2007 03:42:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iww1M-00079j-ET for mext@ietf.org; Tue, 27 Nov 2007 03:42:20 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iww1L-0006Db-L1 for mext@ietf.org; Tue, 27 Nov 2007 03:42:20 -0500 Received: (qmail invoked by alias); 27 Nov 2007 08:42:18 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp047) with SMTP; 27 Nov 2007 09:42:18 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19U7nQz0QJUbmbp7hezV28XU/CbIummOSo6wr4V1p eZz76vuouWy2jI Message-ID: <474BD865.7000701@gmx.net> Date: Tue, 27 Nov 2007 09:42:13 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> In-Reply-To: <008601c83032$4e95b030$ebc11090$@nl> 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: 34d35111647d654d033d58d318c0d21a 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 Teco, Teco Boot wrote: > Hi Hannes, > I suggest reusing what we already have. > Maybe RSVP is already in place, in that case RSVP packets are sent over the > tunnel. > Two observations from my limited RSVP experience: * Deployment of RSVP does not really exist (for this type of environment). Please note that I talk about RSVP and not RSVP-TE. * RSVP for packet filter installation does not exist either as an IETF document. There was only some work in the 3GPP2. The 3GPP2 has also specified the NSIS NATFW NSLP to perform packet filter installation. Unlike RSVP for packet filter installation the NSIS NATFW NSLP is actually an IETF document. > In the MONAMI6 context; I think we need a protocol for signaling traffic > flow policy. This is related to MIP. > Within this protocol, we need some kind of traffic specification, here we > could reuse RSVP TSPEC. > Cheers, Teco. > Ciao Hannes > >> -----Oorspronkelijk bericht----- >> Van: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Verzonden: maandag 26 november 2007 10:12 >> Aan: Teco Boot >> CC: mext@ietf.org >> Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules >> >> Hi Teco, >> >> Teco Boot wrote: >> >>>>> Finally, what happened to >>>>> draft-mitsuya-monami6-flow-distribution-policy-04.txt. I >>>>> thought this was also going to be adopted as a MONAMI6 WG >>>>> document. I might have missed some emails. >>>>> >>>>> >>>> There are two documents about flow distribution languages documents. >>>> - draft-mitsuya-monami6-flow-distribution-policy-04.txt >>>> - draft-larsson-monami6-filter-rules-02.txt >>>> >>>> We agreed to merge the two documents and >>>> published draft-larsson-mext-flow-distribution-rules-00.txt >>>> >>>> >>>> >>> I suggested to check using RSVP TSPEC for flow-distribution-rules >>> >> before. >> >>> This has similar functionality and integration with upper layers >>> >> could be >> >>> more straightforward. >>> I'm afraid I don't have time to work out this idea. I would >>> >> appreciate >> >>> someone picks up. >>> >>> >> Are you suggesting to use RSVP for signaling the packet filters? >> Or: Are you suggesting to look at the packet formats for describing the >> traffic filters? >> >> >> Ciao >> Hannes >> >> >>> Teco. >>> >>> >>> >>> _______________________________________________ >>> 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 Nov 27 04:26:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwwhn-0002SF-3d; Tue, 27 Nov 2007 04:26:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwwhl-0002S7-U3 for mext@ietf.org; Tue, 27 Nov 2007 04:26:09 -0500 Received: from hpsmtp-eml12.kpnxchange.com ([213.75.38.112]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwwhk-0001yv-SM for mext@ietf.org; Tue, 27 Nov 2007 04:26:09 -0500 Received: from hpsmtp-eml10.kpnxchange.com ([213.75.38.110]) by hpsmtp-eml12.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 10:26:07 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 10:26:07 +0100 From: "Teco Boot" To: "'Hannes Tschofenig'" References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> In-Reply-To: <474BD865.7000701@gmx.net> Subject: RE: [MEXT] RSVP TSPEC for flow-distribution-rules Date: Tue, 27 Nov 2007 10:26:04 +0100 Message-ID: <002101c830d7$89fbc6a0$9df353e0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgw0X1jWHdytY3DRIesH5h0HGIy5gAA9DXg Content-Language: nl X-OriginalArrivalTime: 27 Nov 2007 09:26:07.0126 (UTC) FILETIME=[89FD9B60:01C830D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 Hannes, Thanks for the hint checking NSIS. What I found is: RFC4080 (NSIS Framework): 4.6.1. Flow Identification draft-ietf-nsis-qos-nslp-15 (QoS NSLP): 5.1.3.5. Packet Classifier (PACKET_CLASSIFIER) I think NSIS produced specifications on packet classification should be verified for using for MIP flow distribution / handover also. Maybe RSVP TSPEC is past and NSIS FlowID is future. Teco. > -----Oorspronkelijk bericht----- > Van: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Verzonden: dinsdag 27 november 2007 9:42 > Aan: Teco Boot > CC: mext@ietf.org > Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules > > Hi Teco, > > Teco Boot wrote: > > Hi Hannes, > > I suggest reusing what we already have. > > Maybe RSVP is already in place, in that case RSVP packets are sent > over the > > tunnel. > > > > Two observations from my limited RSVP experience: > > * Deployment of RSVP does not really exist (for this type of > environment). Please note that I talk about RSVP and not RSVP-TE. > > * RSVP for packet filter installation does not exist either as an IETF > document. There was only some work in the 3GPP2. > > The 3GPP2 has also specified the NSIS NATFW NSLP to perform packet > filter installation. Unlike RSVP for packet filter installation the > NSIS > NATFW NSLP is actually an IETF document. > > > In the MONAMI6 context; I think we need a protocol for signaling > traffic > > flow policy. This is related to MIP. > > Within this protocol, we need some kind of traffic specification, > here we > > could reuse RSVP TSPEC. > > Cheers, Teco. > > > > > Ciao > Hannes > > > > >> -----Oorspronkelijk bericht----- > >> Van: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Verzonden: maandag 26 november 2007 10:12 > >> Aan: Teco Boot > >> CC: mext@ietf.org > >> Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules > >> > >> Hi Teco, > >> > >> Teco Boot wrote: > >> > >>>>> Finally, what happened to > >>>>> draft-mitsuya-monami6-flow-distribution-policy-04.txt. I > >>>>> thought this was also going to be adopted as a MONAMI6 WG > >>>>> document. I might have missed some emails. > >>>>> > >>>>> > >>>> There are two documents about flow distribution languages > documents. > >>>> - draft-mitsuya-monami6-flow-distribution-policy-04.txt > >>>> - draft-larsson-monami6-filter-rules-02.txt > >>>> > >>>> We agreed to merge the two documents and > >>>> published draft-larsson-mext-flow-distribution-rules-00.txt > >>>> > >>>> > >>>> > >>> I suggested to check using RSVP TSPEC for flow-distribution-rules > >>> > >> before. > >> > >>> This has similar functionality and integration with upper layers > >>> > >> could be > >> > >>> more straightforward. > >>> I'm afraid I don't have time to work out this idea. I would > >>> > >> appreciate > >> > >>> someone picks up. > >>> > >>> > >> Are you suggesting to use RSVP for signaling the packet filters? > >> Or: Are you suggesting to look at the packet formats for describing > the > >> traffic filters? > >> > >> > >> Ciao > >> Hannes > >> > >> > >>> Teco. > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 Nov 27 04:36:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwwrY-0007Bh-Ih; Tue, 27 Nov 2007 04:36:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwwrX-0007Ba-RA for mext@ietf.org; Tue, 27 Nov 2007 04:36:15 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IwwrT-0008QA-Vn for mext@ietf.org; Tue, 27 Nov 2007 04:36:15 -0500 Received: (qmail invoked by alias); 27 Nov 2007 09:36:10 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp038) with SMTP; 27 Nov 2007 10:36:10 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/CZVgt8W/CoS0GHqPyw1SHNMr/Wng9mnWOSovk9e HCHatRg9uRUnbY Message-ID: <474BE50A.9050100@gmx.net> Date: Tue, 27 Nov 2007 10:36:10 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> In-Reply-To: <002101c830d7$89fbc6a0$9df353e0$@nl> 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: 156eddb66af16eef49a76ae923b15b92 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 Teco, here is the respective NSIS document: http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-16.txt It is currently in WGLC. Ciao Hannes PS: The requirements from the 3GPP2 have been documented here and will be published as informational RFC (at least that's the latest status I have): http://tools.ietf.org/wg/nsis/draft-bajko-nsis-fw-reqs-08.txt Teco Boot wrote: > Hi Hannes, > > Thanks for the hint checking NSIS. > > What I found is: > RFC4080 (NSIS Framework): 4.6.1. Flow Identification > draft-ietf-nsis-qos-nslp-15 (QoS NSLP): 5.1.3.5. Packet Classifier > (PACKET_CLASSIFIER) > > I think NSIS produced specifications on packet classification should be > verified for using for MIP flow distribution / handover also. > Maybe RSVP TSPEC is past and NSIS FlowID is future. > > Teco. > > >> -----Oorspronkelijk bericht----- >> Van: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Verzonden: dinsdag 27 november 2007 9:42 >> Aan: Teco Boot >> CC: mext@ietf.org >> Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules >> >> Hi Teco, >> >> Teco Boot wrote: >> >>> Hi Hannes, >>> I suggest reusing what we already have. >>> Maybe RSVP is already in place, in that case RSVP packets are sent >>> >> over the >> >>> tunnel. >>> >>> >> Two observations from my limited RSVP experience: >> >> * Deployment of RSVP does not really exist (for this type of >> environment). Please note that I talk about RSVP and not RSVP-TE. >> >> * RSVP for packet filter installation does not exist either as an IETF >> document. There was only some work in the 3GPP2. >> >> The 3GPP2 has also specified the NSIS NATFW NSLP to perform packet >> filter installation. Unlike RSVP for packet filter installation the >> NSIS >> NATFW NSLP is actually an IETF document. >> >> >>> In the MONAMI6 context; I think we need a protocol for signaling >>> >> traffic >> >>> flow policy. This is related to MIP. >>> Within this protocol, we need some kind of traffic specification, >>> >> here we >> >>> could reuse RSVP TSPEC. >>> Cheers, Teco. >>> >>> >> Ciao >> Hannes >> >> >>>> -----Oorspronkelijk bericht----- >>>> Van: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Verzonden: maandag 26 november 2007 10:12 >>>> Aan: Teco Boot >>>> CC: mext@ietf.org >>>> Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules >>>> >>>> Hi Teco, >>>> >>>> Teco Boot wrote: >>>> >>>> >>>>>>> Finally, what happened to >>>>>>> draft-mitsuya-monami6-flow-distribution-policy-04.txt. I >>>>>>> thought this was also going to be adopted as a MONAMI6 WG >>>>>>> document. I might have missed some emails. >>>>>>> >>>>>>> >>>>>>> >>>>>> There are two documents about flow distribution languages >>>>>> >> documents. >> >>>>>> - draft-mitsuya-monami6-flow-distribution-policy-04.txt >>>>>> - draft-larsson-monami6-filter-rules-02.txt >>>>>> >>>>>> We agreed to merge the two documents and >>>>>> published draft-larsson-mext-flow-distribution-rules-00.txt >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I suggested to check using RSVP TSPEC for flow-distribution-rules >>>>> >>>>> >>>> before. >>>> >>>> >>>>> This has similar functionality and integration with upper layers >>>>> >>>>> >>>> could be >>>> >>>> >>>>> more straightforward. >>>>> I'm afraid I don't have time to work out this idea. I would >>>>> >>>>> >>>> appreciate >>>> >>>> >>>>> someone picks up. >>>>> >>>>> >>>>> >>>> Are you suggesting to use RSVP for signaling the packet filters? >>>> Or: Are you suggesting to look at the packet formats for describing >>>> >> the >> >>>> traffic filters? >>>> >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> >>>>> Teco. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 27 04:42:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwwx9-000570-P6; Tue, 27 Nov 2007 04:42:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwwx8-00056Z-92 for mext@ietf.org; Tue, 27 Nov 2007 04:42:02 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iwwx7-0003We-9a for mext@ietf.org; Tue, 27 Nov 2007 04:42:01 -0500 Received: (qmail invoked by alias); 27 Nov 2007 09:42:00 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp024) with SMTP; 27 Nov 2007 10:42:00 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+qoUF/Z2+qTbRpbDbp3PqU/qS+lZRQjsjJjHoxOc vXDQ/AHjTsAN3Q Message-ID: <474BE667.8030103@gmx.net> Date: Tue, 27 Nov 2007 10:41:59 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> <474BE50A.9050100@gmx.net> In-Reply-To: <474BE50A.9050100@gmx.net> 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: 43317e64100dd4d87214c51822b582d1 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 Btw, there are a couple of NSIS implementations and you can play around with the NATFW NSLP. I suggest to look at the following page: http://user.informatik.uni-goettingen.de/~nsis/ In an EU funded project, called ENABLE, the NATFW NSLP has been used for firewall signaling in Mobile IP environments. Papers are available, see http://user.informatik.uni-goettingen.de/~fu/#publication and a separate draft for dealing with the firewall traversal problems outlined in RFC 4487 can be found here: http://tools.ietf.org/id/draft-thiruvengadam-nsis-mip6-fw-08.txt Ciao Hannes Hannes Tschofenig wrote: > Hi Teco, > > here is the respective NSIS document: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-16.txt > > It is currently in WGLC. > > Ciao > Hannes > > PS: The requirements from the 3GPP2 have been documented here and will > be published as informational RFC (at least that's the latest status I > have): > http://tools.ietf.org/wg/nsis/draft-bajko-nsis-fw-reqs-08.txt > > Teco Boot wrote: >> Hi Hannes, >> >> Thanks for the hint checking NSIS. >> >> What I found is: >> RFC4080 (NSIS Framework): 4.6.1. Flow Identification >> draft-ietf-nsis-qos-nslp-15 (QoS NSLP): 5.1.3.5. Packet Classifier >> (PACKET_CLASSIFIER) >> >> I think NSIS produced specifications on packet classification should be >> verified for using for MIP flow distribution / handover also. >> Maybe RSVP TSPEC is past and NSIS FlowID is future. >> >> Teco. >> >> >>> -----Oorspronkelijk bericht----- >>> Van: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Verzonden: dinsdag 27 november 2007 9:42 >>> Aan: Teco Boot >>> CC: mext@ietf.org >>> Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules >>> >>> Hi Teco, >>> >>> Teco Boot wrote: >>> >>>> Hi Hannes, >>>> I suggest reusing what we already have. >>>> Maybe RSVP is already in place, in that case RSVP packets are sent >>>> >>> over the >>> >>>> tunnel. >>>> >>>> >>> Two observations from my limited RSVP experience: >>> >>> * Deployment of RSVP does not really exist (for this type of >>> environment). Please note that I talk about RSVP and not RSVP-TE. >>> >>> * RSVP for packet filter installation does not exist either as an IETF >>> document. There was only some work in the 3GPP2. >>> >>> The 3GPP2 has also specified the NSIS NATFW NSLP to perform packet >>> filter installation. Unlike RSVP for packet filter installation the >>> NSIS >>> NATFW NSLP is actually an IETF document. >>> >>> >>>> In the MONAMI6 context; I think we need a protocol for signaling >>>> >>> traffic >>> >>>> flow policy. This is related to MIP. >>>> Within this protocol, we need some kind of traffic specification, >>>> >>> here we >>> >>>> could reuse RSVP TSPEC. >>>> Cheers, Teco. >>>> >>>> >>> Ciao >>> Hannes >>> >>> >>>>> -----Oorspronkelijk bericht----- >>>>> Van: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Verzonden: maandag 26 november 2007 10:12 >>>>> Aan: Teco Boot >>>>> CC: mext@ietf.org >>>>> Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules >>>>> >>>>> Hi Teco, >>>>> >>>>> Teco Boot wrote: >>>>> >>>>> >>>>>>>> Finally, what happened to >>>>>>>> draft-mitsuya-monami6-flow-distribution-policy-04.txt. I >>>>>>>> thought this was also going to be adopted as a MONAMI6 WG >>>>>>>> document. I might have missed some emails. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> There are two documents about flow distribution languages >>>>>>> >>> documents. >>> >>>>>>> - draft-mitsuya-monami6-flow-distribution-policy-04.txt >>>>>>> - draft-larsson-monami6-filter-rules-02.txt >>>>>>> >>>>>>> We agreed to merge the two documents and >>>>>>> published draft-larsson-mext-flow-distribution-rules-00.txt >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> I suggested to check using RSVP TSPEC for flow-distribution-rules >>>>>> >>>>>> >>>>> before. >>>>> >>>>> >>>>>> This has similar functionality and integration with upper layers >>>>>> >>>>>> >>>>> could be >>>>> >>>>> >>>>>> more straightforward. >>>>>> I'm afraid I don't have time to work out this idea. I would >>>>>> >>>>>> >>>>> appreciate >>>>> >>>>> >>>>>> someone picks up. >>>>>> >>>>>> >>>>>> >>>>> Are you suggesting to use RSVP for signaling the packet filters? >>>>> Or: Are you suggesting to look at the packet formats for describing >>>>> >>> the >>> >>>>> traffic filters? >>>>> >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> >>>>> >>>>>> Teco. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> > > > _______________________________________________ > 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 Nov 27 05:20:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwxYf-0005o7-Th; Tue, 27 Nov 2007 05:20:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwxYe-0005nt-Lp for mext@ietf.org; Tue, 27 Nov 2007 05:20:48 -0500 Received: from rv-out-0910.google.com ([209.85.198.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwxYc-0004JF-Vk for mext@ietf.org; Tue, 27 Nov 2007 05:20:48 -0500 Received: by rv-out-0910.google.com with SMTP id l15so803845rvb for ; Tue, 27 Nov 2007 02:20:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; 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; bh=HCwoa4BlcUNnRBLQwJHtzPgC3SKiMLIuBNOiMig1xuU=; b=EB5VRKFU5NWyfa1fO+gtpu6eoCyUHoJvNLXHFspbQzPE0yZCwf+ljlHqftxQao1hABhHlR9/yoA30f4e7VzJWlI5NtEsA08UOs/tiU7FNcPDSOKcBuewk5Q/NnlEkbV7GrVNfm4hIhaPLcYRd18GedCZuTbyR4VGBjprFNNJcSE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QykDPuY/RKuWRuORFtwd1t/5g4r50Yq2ltpzGjWJ56r0OPkBnNWg6UBjs8NPOgUbepGBEg3hk+N3f2lCoTxQzy3mKN2V6Tl605pNu3rVejLkrkqsBkshNfN4bCkv6LNZ+BqJFZwWRvTkrxRa3kfrXfqNMhLD9hwN3eQgYfCy808= Received: by 10.140.251.1 with SMTP id y1mr1765450rvh.1196158846363; Tue, 27 Nov 2007 02:20:46 -0800 (PST) Received: by 10.140.135.15 with HTTP; Tue, 27 Nov 2007 02:20:46 -0800 (PST) Message-ID: Date: Tue, 27 Nov 2007 10:20:46 +0000 From: "George Tsirtsis" To: "Sri Gundavelli" Subject: Re: [MEXT] Prefix delegation & Diameter Interaction In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0MKp8S-1IwdRx2OQq-0008Gc@mrelay.perfora.net> <474B12F7.8000700@azairenet.com> <474B2270.8080405@gmx.net> <474B2FAF.4030709@gmail.com> <474B30C3.7060508@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Hannes Tschofenig , 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 I agree with Sri here, If someone thinks that this issue is done and dusted then he can summarize the strong technical points against use of AAA for address allocation. >From my side, I feel that the whole discussion is a bit pointless and slightly on the wrong track. I say that because AAA servers have been able to return IPv4/IPv6 addresses and prefixes since forever. Whether these addresses are then statically part of someones subscription profile or are dynamically allocated by some pool available to the AAA server is implementation specific. Obviously this AAA capability can be linked in the AR/HA/LMA with MIPv6/NEMO/PMIPv6 or whatever other protocol one requires....this is nothing new either. So, reading draft-sarikaya-dime-prefix-delegation, I do not really learn anything I do not already know how to do. So the question for this group is whether documenting the exact (albeit obvious) interactions e.g., between AAA and MIPv6/NEMO/PMIP for PD, is useful or not. If it is useful then, is it also something the IETF recommends or not? I generally find such documents only semi-useful and at best IMHO they can be informational or BCP if we think we really have a specific recommendation about how multiple protocols should be linked. My 2 (Canadian) cents George On 11/26/07, Sri Gundavelli wrote: > > > On Mon, 26 Nov 2007, Hannes Tschofenig wrote: > > > Quick comment: > > > > Alexandru Petrescu wrote: > >> Hannes Tschofenig wrote: > >> > Hi Vijay, > >> > > >> > maybe you can provide some pointers to past discussions and conclusions. > >> > You cannot expect that everyone follows all mailing lists and now this > >> > work is being proposed for DIME. > >> > >> Sorry for intruding... it's difficult for someone to dig archives, as much > >> as it is for you. > > Are you saying that it is as difficult for me to find the pointer to the > > discussion as it is for Vijay? > > When I participated in discussions then I typically remember the context and > > roughly the time when they happened. This makes it easier to find it. > > > > But, if the discussion took place so long ages ago. May be its > worth revisiting that and to ensure the assumptions that were > used for arriving at that conclusion are still valid. Or, some > one can atleast state one or two arguments from that discussion, > if at all, if they remember those. > > > Sri > > _______________________________________________ > 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 Nov 27 05:44:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwxvS-0001W6-Kw; Tue, 27 Nov 2007 05:44:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwxvQ-0001Qy-Jo for mext@ietf.org; Tue, 27 Nov 2007 05:44:20 -0500 Received: from rv-out-0910.google.com ([209.85.198.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwxvO-0006b0-4Q for mext@ietf.org; Tue, 27 Nov 2007 05:44:20 -0500 Received: by rv-out-0910.google.com with SMTP id l15so808782rvb for ; Tue, 27 Nov 2007 02:44:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; 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; bh=SwyetuOfZstp1JOYSixHs1WczFVqyocByYBGnKRwC7E=; b=EAZF/p+1QzQ9+zQ+7XWnC/f+ebtNqkMeBc2vuxbUnIxyv4r8RMyZQRKn6UF/j2G9x8p91RDor29MJRoSrtvUNcxMFiWvjcuQuF2qSontAfT/TDbzFTyeQENNm6etrFc/QabzOKa75FJ3iJNxGcAJdPv129SxEsTiioL/vSlAJFk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bGcSIaAzX+JPIkdKyy2Na1I4Xhl56I2iGeHNgdIG+6pSKgJAdpyvTbPQZQShBLTn3Qq+3Q0TVGUkapFY6SGj/tXCUcAbjG7sM44K75kPmjYBgfi4YknTwOcLI0yFqpMbQK5+8wlc5YxOVqcrdgK/dFI02svuLDz+CXpGsvfE/1k= Received: by 10.141.171.6 with SMTP id y6mr1772625rvo.1196160257524; Tue, 27 Nov 2007 02:44:17 -0800 (PST) Received: by 10.140.135.15 with HTTP; Tue, 27 Nov 2007 02:44:17 -0800 (PST) Message-ID: Date: Tue, 27 Nov 2007 10:44:17 +0000 From: "George Tsirtsis" To: "Teco Boot" Subject: Re: [MEXT] Next steps on prefix delegation In-Reply-To: <001c01c830d0$e079d230$a16d7690$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <200711261428.27978.julien.IETF@laposte.net> <474B3E3F.4080004@kniveton.com> <001c01c830d0$e079d230$a16d7690$@nl> 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 All, We may want to remember that Mobile IP and Address allocation has always been a "chicken and egg" issue. Ideally, we would keep these two processes entirely separated so that one mechanism is chosen for address allocation and then another mechanism is used to redirect traffic to the mobile's current location. In practice, however, this can only be done if the MN always powers up at home link, in which case either stateless autoconf or DHCP can be used *before* MIP needs to be bootstrapped and used. This breaks down when the MN boots up on a foreign link since our basic address allocation mechanism only provide local addresses. Now because mobility in the Internet is an afterthought >sigh< we ended up with a bunch of different mechanisms with allocating HoAs on foreign links. These include at least DHCP, IKE and MIP as well as combinations of them for primary HoA and subsequent/additional address and prefix allocation. So DSMIPv6 for example, has the capability to allocate an IPv4 address or prefix as part of the protocol. I do not see how it makes sense to prevent the same DSMIPv6 HA to allocate an IPv6 address/prefix as well. IKEv2 is also being extended to be able to do the same thing. DHCP-PD can of course also be used on top of either of these, or even in series with these. Maybe we can then resign to the fact that multiple mechanisms for this are a reality and let the market figure out what is useful and when. Lets just remember not to create yet another way of doing this any time soon ;-) Regards George On 11/27/07, Teco Boot wrote: > Hi, > > I want to better understand this discussion. > > I think we want to define a protocol for getting a prefix to be used for > MNP, correct? > This cannot be provided by stateless configuration, correct? Prefixes are > always managed. ULA are somewhat the exception, I prefer keeping this is > out-of-scope. > > So we need some kind of authority, providing prefixes. And MRs request > prefixes. In all configuration databases, state of all leases is maintained. > > Now we need a protocol for requesting and delegation prefixes. Maybe we want > some nesting, e.g. a MR may delegate prefixes downwards. For a protocol > point of view, this is not important. > > Currently, we have some mechanisms, like DHCP-PD and some AAA protocols for > the same functionality. All protocols shall manage prefixes consistent, e.g. > uniqueness, expiration timers etc. > > Now the question is, do current protocols fit requirements for Mobile > Routers requesting prefixes. If not, we can design new protocols or extent > current protocols. I think there should not be any limitation on running > multiple protocols, e.g. a Prefix Delegation Server runs DHCP, DHCP-PD, some > AAA-PD and new PD protocols. Same for MR. > > I wanted to make clear there is no separation between DHCP server and other > servers managing prefixes. It is about the protocols being used. > > Teco. > > > > -----Oorspronkelijk bericht----- > > Van: T.J. Kniveton [mailto:tj@kniveton.com] > > Verzonden: maandag 26 november 2007 22:45 > > Aan: Julien Laganier > > CC: mext@ietf.org > > Onderwerp: Re: [MEXT] Next steps on prefix delegation > > > > Since Julien brought up RFC 1958, let's talk a little bit more about > > Internet engineering philosophy: > > > > IPv6 was designed so that a node can obtain an address by: > > > > 1. Stateless configuration. The node receives a router advertisement > > and > > constructs an address by appending its own suffix, using neighbor > > discovery to ensure it's unique. > > > > 2. Stateful configuration. An authoritative DHCP infrastructure is in > > place, and the end node queries the DHCP server(s), and it receives an > > address, and other associated configuration data. > > > > (Note: these are two methods for accomplishing the same goal.) > > > > Now throughout the Mobile IP(v6) engineering effort, there has been a > > largely unspoken assumption that we should continue to use a stateless > > configuration paradigm. That is why we have things like Dynamic Home > > Agent Address Discovery, Mobile Prefix Solicitation/Advertisements, > > bootstrapping, etc. Otherwise, we would just rely on a big DHCP brain > > in > > the sky to tell the end node all of its configuration information. The > > way I see it, using option #1 means that we are furthering the Internet > > protocol capabilities while remaining consistent with the long-standing > > ideal that the intelligence lies in end nodes, not in the network. > > > > In writing the prefix delegation draft, it was my intention to continue > > the above-mentioned ideal, and allow nodes to request a prefix directly > > from whence they are being managed in some cases (such as where Vijay > > pointed out), in the HA. > > > > [Note: I do not agree with your supposition that receiving a prefix is > > tantamount to stateful address configuration: when I bind a home > > address > > to a care-of address, or assign myself a care-of address using > > stateless > > address autoconfiguration, neither one involves the use of DHCP.] > > > > So, the question is this: do we want to continue the evolution of the > > protocol suite that includes IPv6, Mobile IPv6, and NEMO, and have a > > mechanism for requesting use of a prefix, or do we want to say, well, > > this is too complicated; if you want to do this, you are going to need > > to install a DHCP infrastructure.? > > > > So far, it seemed logical to describe both methods and allow people to > > decide how they want to implement a system. However, if we are > > restricted to standardizing one method, more study is needed of > > realistically deployable systems to determine which direction is better > > to go in, and to understand the implications. I have been waiting a > > couple years and have not seen these prefix delegation schemes be > > implemented yet, so further study, IMHO, is necessary before declaring > > that "DHCP makes sense" or "most IPv6 networks will have DHCPv6 > > services > > deployed" and we should just go that direction. > > > > TJ > > > > _______________________________________________ > > 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 > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From LesliebonifaceWilliamson@harpers.org Tue Nov 27 07:35:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwzeg-0005b7-8q; Tue, 27 Nov 2007 07:35:10 -0500 Received: from 175.pool85-49-21.dynamic.orange.es ([85.49.21.175] helo=casaee3222f5c5) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iwzef-00052n-MP; Tue, 27 Nov 2007 07:35:10 -0500 Message-ID: <31257501c830f1$ec968c40$0200a8c0@casaee3222f5c5> From: "Andre Banks" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_312571_01C830F1.EC968C40-- From mext-bounces@ietf.org Tue Nov 27 07:40:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwzjG-0003CQ-47; Tue, 27 Nov 2007 07:39:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwzjE-0003C5-Um for mext@ietf.org; Tue, 27 Nov 2007 07:39:52 -0500 Received: from rv-out-0910.google.com ([209.85.198.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwzjE-0002zI-6p for mext@ietf.org; Tue, 27 Nov 2007 07:39:52 -0500 Received: by rv-out-0910.google.com with SMTP id l15so832347rvb for ; Tue, 27 Nov 2007 04:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; 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; bh=wNMdQbbzXe2cYf8fydDbSIiNFcakTHcktU9HfhXyR44=; b=BvJ5fuPmFW767LUgn+VlJFEN+p6aN3u2kmnF44cgOy6w2sTGQacLKCkPAHDNnmEe+kT31luS6lQYGgzF6otRXDgv/np3RzLNdzCNT1D3yRRqpXujMOIPs3fJT8ZK6N5fFKyAlj2n2lXZ5YMJOgQ0lbh2ZOQ1tSuzb4dOTyzH8Ug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MKJrCEHtLBfvcBbej9/CxaujhVNOEd+OEfejMCbv+INpH42Z0wuN7BvE2k0dnAfte1prsZWt81GDK/Folh5H2NcOYUCo1o13yCNi1n9F2a7qWQTu8B3FzY1cbmF6ORFuZAqQxKqduRgb9hyxdwRUT2z72GX/KpDowE0rka9xxIs= Received: by 10.140.88.20 with SMTP id l20mr1841078rvb.1196167191513; Tue, 27 Nov 2007 04:39:51 -0800 (PST) Received: by 10.140.135.15 with HTTP; Tue, 27 Nov 2007 04:39:51 -0800 (PST) Message-ID: Date: Tue, 27 Nov 2007 12:39:51 +0000 From: "George Tsirtsis" To: "Benjamin Lim" Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-04.txt In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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 The draft describes how one can cause a CN to send downlink traffic and then redirect that traffic to the target using MCoA+flow. One observation is that this is also possible (although in a more limited way) with plain MIPv6 e.g., triger a large UDP streaming download and then handoff to the target's CoA to cause flooding. I am not sure this is a really good attack though, given the fact that the attacker's identity is known to the HA i.e., the attacker can get caught. It may, however, have some value as an attack if the attacker actually owns the HA, and thus can not be traced as such. In such a case, however, it might be easier for the attacker to run a random traffic generator and flood whatever address it wants from the HA directly. Am I missing something? George On 11/27/07, Benjamin Lim wrote: > Hi Ryuji, > > My response to one of your comment inline. > > =8==8<=8== > > > Also, I feel that other considerations on what impact would > > MN trigger > > > when using bulk registration. For instance, in my recently > > submitted > > > ID > > > > > (http://www.ietf.org/internet-drafts/draft-lim-mext-multiple-coa-verif > > > y-00.t xt), I mention MN using bulk registration might be > > able to bind > > > CoAs of victims at HA and thereby leading to a flooding attack to > > > those victims. I believe it is worth taking such issue into > > > consideration. > > > > Thanks for writing that document. > > We discussed this issue on Monami6 ML before. > > > > I am still not sure how serious this attack is. > > When the MN sends bulk-BU to HA, the MN has to create IPsec > > SA with the HA. > [Ben] Yes IPsec protects the BU from any form of man-in-the middle > modification to the contents of the BU. But how can HA be sure that MN is > not the one being malicious. This is the problem we highlight in our draft > (that MN could be the malicious node). If you say, the identity of MN is > known to HA, we re-iterated in our draft providing an example that having > the identity known does not deter such attacks from being launched. > > > The scenario looks very limited because not all the nodes can > > launch the attack. > [Ben] True, but you do not need all nodes to launch the attack. Just a > Monami6 node launching the attack is at most equivalent to all nodes > launching the attack. > > > Even RFC3775 does not verify CoA for home registration. > [Ben] RFC3775 assumes trust for home registration. More than likely, the CoA > is specified in the source address field of the packet hence ingress > filtering can be assumed to be performed. Even if AltCoA option used, in > RFC3775, at most MN can only specify one AltCoA binding. But in bulk > registration, MN can specify more than one CoA to be bound at HA. > Furthermore, only one of these CoAs is specified in the source address field > of the BU. The rest are specified in the BU itself. Hence, this increases > the risk of not knowing if they are actually valid routing address to MN > that HA has to take when binding these CoAs. Thus, it might be worth > considering in this case for HA to perform some procedure in order to lessen > such risk. > > I believe that most of the question/answer is as per what we have discussed > on the Monami6 ML. Hopefully, this mail will clarify your doubts on such > issue. > > Regards, > Benjamin Lim > > > > > regards, > > ryuji > > > > _______________________________________________ > 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 Nov 27 09:27:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix1PO-0007CN-0C; Tue, 27 Nov 2007 09:27:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix1PN-0007CB-1E for mext@ietf.org; Tue, 27 Nov 2007 09:27:29 -0500 Received: from hu-out-0506.google.com ([72.14.214.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix1PL-000377-5j for mext@ietf.org; Tue, 27 Nov 2007 09:27:29 -0500 Received: by hu-out-0506.google.com with SMTP id 31so982540huc for ; Tue, 27 Nov 2007 06:27:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=aEu6cPjOB95wl1pbwaHzctpNl9BuQSzP3lLFpO5Tnm4=; b=IpJPZMt87SdZx6eHjsGB2uGdZLVqiA7G3ALaff0LtRYE+KZjS0BBBD8OrK6heeFBrvfGOy4XFZSE08eXVQ7RqO2mBKd/AW30SWgvjdZcmrqX+4ZbAaVMMLKTwZY13cOeEQSsEaKFPYq5H5J4KOLxNxH69cWSNFlE3ETQof2+TZc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=WIKjQkKhc4+8h54ShJRgiw3rSphEI07//5s/vVyjrsojTTjM/2qW447/quJaT7Ns8ym2tjAvbwxNVtZlKBpb2yGlFy6NFhX+hBUdrhNVgOhQS30lcUIbWlVZ1iHF3NGnqJAzeI0Hj2KfqncvSKFf+ZeR8qlShnJ/gmdPTNy9KqY= Received: by 10.66.240.12 with SMTP id n12mr1135112ugh.1196173645713; Tue, 27 Nov 2007 06:27:25 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id o24sm6488367ugd.2007.11.27.06.27.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Nov 2007 06:27:24 -0800 (PST) From: Julien Laganier To: mext@ietf.org Subject: Re: [MEXT] Next steps on prefix delegation Date: Tue, 27 Nov 2007 15:27:40 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <200711261428.27978.julien.IETF@laposte.net> <474B3E3F.4080004@kniveton.com> In-Reply-To: <474B3E3F.4080004@kniveton.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711271527.40797.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: 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 Hello TJ, On Monday 26 November 2007, T.J. Kniveton wrote: > Since Julien brought up RFC 1958, let's talk a little bit more about > Internet engineering philosophy: > > IPv6 was designed so that a node can obtain an address by: > > 1. Stateless configuration. The node receives a router advertisement > and constructs an address by appending its own suffix, using neighbor > discovery to ensure it's unique. > > 2. Stateful configuration. An authoritative DHCP infrastructure is in > place, and the end node queries the DHCP server(s), and it receives > an address, and other associated configuration data. > > (Note: these are two methods for accomplishing the same goal.) While I agree that the high level goal is the same: assigning an address to an interface, there are in facts two distinct goals that fundamentally differ in terms of the characteristics of the assigned address. With stateless configuration the address is assigned by the node, while in stateful configuration the address is assigned by the network. This fundamental difference makes it necessary to have two different methods, to achieve two different goals. > Now throughout the Mobile IP(v6) engineering effort, there has been a > largely unspoken assumption that we should continue to use a > stateless configuration paradigm. That is why we have things like > Dynamic Home Agent Address Discovery, Mobile Prefix > Solicitation/Advertisements, bootstrapping, etc. Otherwise, we would > just rely on a big DHCP brain in the sky to tell the end node all of > its configuration information. The way I see it, using option #1 > means that we are furthering the Internet protocol capabilities while > remaining consistent with the long-standing ideal that the > intelligence lies in end nodes, not in the network. I am not sure about the assumptions made during development of Mobile IP but given the existence of two mode of operations for address assignment it seems natural that Mobile IP does not disallow any of them. I am not sure either that one mode is kind of better than the other. I also think this is somewhat orthogonal to the discussion of prefix delegation for NEMO, see more below. > In writing the prefix delegation draft, it was my intention to > continue the above-mentioned ideal, and allow nodes to request a > prefix directly from whence they are being managed in some cases > (such as where Vijay pointed out), in the HA. I do not think the comparison between address assignment and prefix delegation is pertinent. While we agree that there are two ways to assign addresses: stateless and stateful, that is not true for delegating prefixes, see below: > [Note: I do not agree with your supposition that receiving a prefix > is tantamount to stateful address configuration: when I bind a home > address to a care-of address, or assign myself a care-of address > using stateless address autoconfiguration, neither one involves the > use of DHCP.] I do not understand the comparison. Delegating prefixes requires the delegating entity to keep state about which prefix were delegated to whom. Therefore it is stateful. > So, the question is this: do we want to continue the evolution of the > protocol suite that includes IPv6, Mobile IPv6, and NEMO, and have a > mechanism for requesting use of a prefix, or do we want to say, well, > this is too complicated; if you want to do this, you are going to > need to install a DHCP infrastructure.? I do not see the antagonism between the two choices -- the mechanism to request use of a prefix in NEMO could well be DHCPv6 PD, in which case the two choices coincide. > So far, it seemed logical to describe both methods and allow people > to decide how they want to implement a system. However, if we are > restricted to standardizing one method, more study is needed of > realistically deployable systems to determine which direction is > better to go in, and to understand the implications. I have been > waiting a couple years and have not seen these prefix delegation > schemes be implemented yet, so further study, IMHO, is necessary > before declaring that "DHCP makes sense" or "most IPv6 networks will > have DHCPv6 services deployed" and we should just go that direction. I agree with you that this WG need to study the question to make a good decision. Note however that in making a decision the WG is certainly not going to state anything w.r.t. to deployment of DHCPv6 on "most IPv6 networks". Rather, it can decide to base NEMO prefix delegation on DHCPv6 PD, or not. That is the only question related to DHCP that we have to answer in this WG, AFAICS. Cheers, --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 27 09:37: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 1Ix1Z7-0000Ky-62; Tue, 27 Nov 2007 09:37:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix1Z6-0000Jt-JX for mext@ietf.org; Tue, 27 Nov 2007 09:37:32 -0500 Received: from hu-out-0506.google.com ([72.14.214.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix1Z5-0004ia-IY for mext@ietf.org; Tue, 27 Nov 2007 09:37:32 -0500 Received: by hu-out-0506.google.com with SMTP id 31so983872huc for ; Tue, 27 Nov 2007 06:37:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=HKSgzSBJpl9N8xDjYzjAe68oxhUkLRZH99ku9KHPE88=; b=aKkT0mXZgzIbwJp5Yy3Bi9uWHZ08cDlRaC/phF+hVXJ7sFiQ03idD9tEcrZH0gAeEouW3FyX41M2WyMmaArgAF6Ghc8H3Q4zqsmOHaGet2s4HpJ7qh8zIKEZI7BVQ1oRWtCyhxqsg94IWipr9WMZ8ZPUiujKcGSWCCQxVtskU6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=CbKOFmrtybwSLATRhd+6Y2HihbIh6BCwzjB3sncPznQDMLq514D0KSp6d+B5lrU1T3SsdcBp3CgomGEbLOwhlhYDmIkO1f6Bm5TuNbFdUDoIw2YxIHiSoCVxcZ9pfhqqlKy77GMKv9PY1/rOVAqy4qPb37myyS5qgM1h64oAR2I= Received: by 10.66.249.16 with SMTP id w16mr883574ugh.1196174250331; Tue, 27 Nov 2007 06:37:30 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id b35sm899791ugd.2007.11.27.06.37.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Nov 2007 06:37:28 -0800 (PST) From: Julien Laganier To: mext@ietf.org Subject: Re: [MEXT] Next steps on prefix delegation Date: Tue, 27 Nov 2007 15:32:16 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <9182F3FB-821D-4122-92C6-D4284DFB727A@it.uc3m.es> <474B37E8.7000200@kniveton.com> In-Reply-To: <474B37E8.7000200@kniveton.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200711271532.16775.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: 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 Hello TJ, On Monday 26 November 2007, T.J. Kniveton wrote: > I think that Ryuji's message shows that: > > If you want to select one prefix delegation mechanism for NEMO, and > have it fit a situation where a mobile network is away from the home > infrastructure, and have the number of messages passed be reasonably > low, with low complexity... > > then, more engineering work is needed. I am not really sure about what Ryuji message shows ;) At any rate it=20 doesn't answer the two questions I've put forth to try to understand=20 if/why a single solution isn't doable (What could possibly make the=20 existing DHCPv6 PD unsuitable to be=A0used for NEMO PD?=A0In case DHCPv6 is= =20 suitable but introduces limitations in the=A0context of NEMO that makes=20 it desirable to standardize another prefix delegation mechanism for=20 NEMO, what would be the=A0limitations?). Please note that these questions=20 were not intended to take side with one proposal or the other but=20 rather try to gain understanding so that we have a consensus on what is=20 the best choice. Our charter only calls for a single prefix delegation mechanism to be=20 published as proposed standard, and I also think that it is a=20 reasonable goal. I'd like the WG to agree on specification on a single=20 mechanism. Thus, this note includes a number of questions. Before we start to discuss about the number of messages incurred by=20 prefix delegation maybe it is worth to asnwer the following question: =20 o Does the WG thinks that keeping the number of messages exchanged for prefix delegation when a MR boots in foreign network low is a=20 requirement? > As I said before, there is a reason that there are two drafts instead > of one. If you consider this "several ways of doing the same thing" > as per RFC 1958, then more work will be necessary to create one way > of doing it that works well. I think it is fine for the WG to spend more time if it allows=20 specification of a single, unified mechanism. W.r.t. the work needed to make a single mechanism work well, is there's=20 an understanding of the missing parts of either of the proposals: o What is missing in the nemo-dhcpv6-pd draft to make it work well? o What is missing in the nemo-prefix-delegation draft to make it work well? > If, on the other hand, you want to make the assumption that any > network with NEMO will have DHCP deployed, and you are not concerned > about bootstrapping a tunnel to the home network to exchange DHCP > messages, then DHCP is the way to go.=20 That would not only be making an assumption, but in fact making DHCPv6=20 PD part of the specification for prefix delegation in NEMO. The second=20 part of your sentence also bring one question: o What are the issues related to bootstrapping a tunnel to the home network to exhange DHCP messages? > But in this case, the minimum effort needed would be to lay out the > assumptions and have some consensus in the group that this is a > reasonable engineering compromise. Seems like a reasonable way to go. =2D-julien > RYUJI WAKIKAWA wrote: > > Hi Julien and all, > > > > Agree that solo solution is always better, but I support both > > solutions for MNP delegation. > > > > DHCP PD is simple solution, but it requires DHCP functionalities at > > HA and MR. > > DHDP PD seems practical when MR boots up in home network. > > However, when MR boots up in foreign network, MR must creates a > > tunnel to send any DHCP messages. > > It means it takes several message exchanges between MR and HA to > > get MNP in bootstrap. > > > > PMIP uses similar way of NEMO PD to assign prefix to MN during > > binding registration. > > If MR uses IKE for HoA assignment, it can setup a tunnel and obtain > > its MNP simultaneously by initial BU. > > > > We have to remember that MR is also MIP6-MN. MIP6 WG standardized > > several ways to assign HoA to MN. > > > > Another question is that shall we have a mechanism to assign HoA > > and prefix at the same time? > > We should update both documents or write another document how NEMO > > bootstrap work > > with MIP6 bootstrap mechanisms. > > > > There are certainly pros & cons. Operator should select one. > > > > regards > > ryuji > > > > On 2007/11/26, at 22:28, Julien Laganier wrote: > >> Folks, > >> > >> Please see below: > >> > >> On Sunday 25 November 2007, marcelo bagnulo braun wrote: > >>> Hi all, > >>> > >>> With respect to the NEMO prefix delegation issue, it is my > >>> opinion that it would be preferred to have a single prefix > >>> delegation solution rather than two. Moreover, that we should > >>> have strong technical reasons to do more than one solution since > >>> this variety of mechanisms without strong reasons adds needless > >>> complexity. > >>> > >>> So, my first question to the working group is: do you think there > >>> are strong technical reasons to have more than one solution for > >>> prefix delegation? > >>> > >>> If no, then which would be the preferred approach for prefix > >>> delegation and why? > >>> > >>> Out goal is to try to wrap up this discussion in the next meting > >> > >> I would like to complement Marcelo's question with some more > >> questions from my side. I am quoting below one of the > >> Architectural Principles of the Internet [RFC1958]: > >> > >> 3.2 If there are several ways of doing the same thing, choose > >> one. If a previous design, in the Internet context or elsewhere, > >> has successfully solved the same problem, choose the same solution > >> unless there is a good technical reason not to. Duplication of > >> the same protocol functionality should be avoided as far as > >> possible, without of course using this argument to reject > >> improvements. > >> > >> In light of this, it seems to me that we should select one > >> mechanism only for prefix delegation in the context of NEMO. If > >> DHCPv6-PD would work, it seems that it should be the only solution > >> adopted. Things are not that simple however and it is possible > >> that very good reasons justify the specification of a new > >> mechanism for prefix delegation in the context of NEMO. > >> > >> To help the WG understand the tradeoffs involved and make an > >> educated choice, I'd like to ask the following questions: > >> > >> o What could possibly make the existing DHCPv6 PD unsuitable to > >> be used for NEMO PD? > >> > >> o In case DHCPv6 is suitable but introduces limitations in the > >> context of NEMO that makes it desirable to standardize > >> another prefix delegation mechanism for NEMO, what would be the > >> limitations? > >> > >> Once we have answered these questions I believe the WG will be in > >> the best position to make the best choice. > >> > >> Cheers, > >> > >> --julien > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > 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 Nov 27 12:54:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix4d9-0000SA-K5; Tue, 27 Nov 2007 12:53:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix4d8-0000Is-CK for mext@ietf.org; Tue, 27 Nov 2007 12:53:54 -0500 Received: from web84112.mail.mud.yahoo.com ([68.142.206.199]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ix4d6-0005xI-DX for mext@ietf.org; Tue, 27 Nov 2007 12:53:54 -0500 Received: (qmail 56266 invoked by uid 60001); 27 Nov 2007 17:53:51 -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=4fGXL8cmA5M/IK6S43p7SVz0+cYtCcCG+3Ar8fVmWbb1LjrC4mpH35HVwWGSlc8L+egvf1xWU2jtUCtbhaUivyhVNza8c0hd2AO8mobcJ4wDqUkzk/2VjTPjUj+oV8/OAeGfFMzuNsnlMcyO2J+sGKZsxZZcDqHPzirhtFezL+M=; X-YMail-OSG: mWDhfKQVM1lFTtUz5vRC0Jp4yC0BseJAzwgTskqu0HtliRYww1NSCg7htAVSIaxTNtDI7.JlrjWwW4m3WBxSXhc_om5mjSQGaWgqo8iIPvZScc4- Received: from [206.16.17.212] by web84112.mail.mud.yahoo.com via HTTP; Tue, 27 Nov 2007 09:53:51 PST X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.152 Date: Tue, 27 Nov 2007 09:53:51 -0800 (PST) From: Behcet Sarikaya Subject: Re: [MEXT] Next steps on prefix delegation To: Julien Laganier MIME-Version: 1.0 Message-ID: <77057.55804.qm@web84112.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0244512893==" Errors-To: mext-bounces@ietf.org --===============0244512893== Content-Type: multipart/alternative; boundary="0-1424675070-1196186031=:55804" --0-1424675070-1196186031=:55804 Content-Type: text/plain; charset=us-ascii Hello Julien, Currently there are two WG drafts draft-ietf-nemo-prefix-delegation-02 and draft-ietf-nemo-dhcpv6-pd-02 which is expired and the main author (Ralph) has not been actively participating in the discussions. Here is my evaluation: draft-ietf-nemo-prefix-delegation-02 is written to close a gap in RFC 3963. I believe what it proposes (MR requesting prefix and HA sending prefix) should have been part of the base protocol. Also the draft is misnamed I think, what the draft proposes is not PD. It leads the way to use PD and maybe that's why the authors called it nemo PD. The other draft, draft-ietf-nemo-dhcpv6-pd-02 is about dhcp PD, it has already expired, there are problems (some indicated in draft-ietf-nemo-prefix-delegation-02 ) in this draft. Overall my suggestion is to go with draft-ietf-nemo-prefix-delegation-02 but ask the authors to give a better name to it. There are also several other typos that need to be cleaned. As for draft-ietf-nemo-dhcpv6-pd-02 , it could be considered if the authors revise it in view of the comments. I hope this helps. Regards, Behcet ----- Original Message ---- From: Julien Laganier To: mext@ietf.org Sent: Tuesday, November 27, 2007 8:32:16 AM Subject: Re: [MEXT] Next steps on prefix delegation Hello TJ, On Monday 26 November 2007, T.J. Kniveton wrote: > I think that Ryuji's message shows that: > > If you want to select one prefix delegation mechanism for NEMO, and > have it fit a situation where a mobile network is away from the home > infrastructure, and have the number of messages passed be reasonably > low, with low complexity... > > then, more engineering work is needed. I am not really sure about what Ryuji message shows ;) At any rate it doesn't answer the two questions I've put forth to try to understand if/why a single solution isn't doable (What could possibly make the existing DHCPv6 PD unsuitable to be used for NEMO PD? In case DHCPv6 is suitable but introduces limitations in the context of NEMO that makes it desirable to standardize another prefix delegation mechanism for NEMO, what would be the limitations?). Please note that these questions were not intended to take side with one proposal or the other but rather try to gain understanding so that we have a consensus on what is the best choice. Our charter only calls for a single prefix delegation mechanism to be published as proposed standard, and I also think that it is a reasonable goal. I'd like the WG to agree on specification on a single mechanism. Thus, this note includes a number of questions. Before we start to discuss about the number of messages incurred by prefix delegation maybe it is worth to asnwer the following question: o Does the WG thinks that keeping the number of messages exchanged for prefix delegation when a MR boots in foreign network low is a requirement? > As I said before, there is a reason that there are two drafts instead > of one. If you consider this "several ways of doing the same thing" > as per RFC 1958, then more work will be necessary to create one way > of doing it that works well. I think it is fine for the WG to spend more time if it allows specification of a single, unified mechanism. W.r.t. the work needed to make a single mechanism work well, is there's an understanding of the missing parts of either of the proposals: o What is missing in the nemo-dhcpv6-pd draft to make it work well? o What is missing in the nemo-prefix-delegation draft to make it work well? > If, on the other hand, you want to make the assumption that any > network with NEMO will have DHCP deployed, and you are not concerned > about bootstrapping a tunnel to the home network to exchange DHCP > messages, then DHCP is the way to go. That would not only be making an assumption, but in fact making DHCPv6 PD part of the specification for prefix delegation in NEMO. The second part of your sentence also bring one question: o What are the issues related to bootstrapping a tunnel to the home network to exhange DHCP messages? > But in this case, the minimum effort needed would be to lay out the > assumptions and have some consensus in the group that this is a > reasonable engineering compromise. Seems like a reasonable way to go. --julien > RYUJI WAKIKAWA wrote: > > Hi Julien and all, > > > > Agree that solo solution is always better, but I support both > > solutions for MNP delegation. > > > > DHCP PD is simple solution, but it requires DHCP functionalities at > > HA and MR. > > DHDP PD seems practical when MR boots up in home network. > > However, when MR boots up in foreign network, MR must creates a > > tunnel to send any DHCP messages. > > It means it takes several message exchanges between MR and HA to > > get MNP in bootstrap. > > > > PMIP uses similar way of NEMO PD to assign prefix to MN during > > binding registration. > > If MR uses IKE for HoA assignment, it can setup a tunnel and obtain > > its MNP simultaneously by initial BU. > > > > We have to remember that MR is also MIP6-MN. MIP6 WG standardized > > several ways to assign HoA to MN. > > > > Another question is that shall we have a mechanism to assign HoA > > and prefix at the same time? > > We should update both documents or write another document how NEMO > > bootstrap work > > with MIP6 bootstrap mechanisms. > > > > There are certainly pros & cons. Operator should select one. > > > > regards > > ryuji > > > > On 2007/11/26, at 22:28, Julien Laganier wrote: > >> Folks, > >> > >> Please see below: > >> > >> On Sunday 25 November 2007, marcelo bagnulo braun wrote: > >>> Hi all, > >>> > >>> With respect to the NEMO prefix delegation issue, it is my > >>> opinion that it would be preferred to have a single prefix > >>> delegation solution rather than two. Moreover, that we should > >>> have strong technical reasons to do more than one solution since > >>> this variety of mechanisms without strong reasons adds needless > >>> complexity. > >>> > >>> So, my first question to the working group is: do you think there > >>> are strong technical reasons to have more than one solution for > >>> prefix delegation? > >>> > >>> If no, then which would be the preferred approach for prefix > >>> delegation and why? > >>> > >>> Out goal is to try to wrap up this discussion in the next meting > >> > >> I would like to complement Marcelo's question with some more > >> questions from my side. I am quoting below one of the > >> Architectural Principles of the Internet [RFC1958]: > >> > >> 3.2 If there are several ways of doing the same thing, choose > >> one. If a previous design, in the Internet context or elsewhere, > >> has successfully solved the same problem, choose the same solution > >> unless there is a good technical reason not to. Duplication of > >> the same protocol functionality should be avoided as far as > >> possible, without of course using this argument to reject > >> improvements. > >> > >> In light of this, it seems to me that we should select one > >> mechanism only for prefix delegation in the context of NEMO. If > >> DHCPv6-PD would work, it seems that it should be the only solution > >> adopted. Things are not that simple however and it is possible > >> that very good reasons justify the specification of a new > >> mechanism for prefix delegation in the context of NEMO. > >> > >> To help the WG understand the tradeoffs involved and make an > >> educated choice, I'd like to ask the following questions: > >> > >> o What could possibly make the existing DHCPv6 PD unsuitable to > >> be used for NEMO PD? > >> > >> o In case DHCPv6 is suitable but introduces limitations in the > >> context of NEMO that makes it desirable to standardize > >> another prefix delegation mechanism for NEMO, what would be the > >> limitations? > >> > >> Once we have answered these questions I believe the WG will be in > >> the best position to make the best choice. > >> > >> Cheers, > >> > >> --julien > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --0-1424675070-1196186031=:55804 Content-Type: text/html; charset=us-ascii
Hello Julien,
  Currently there are two WG drafts draft-ietf-nemo-prefix-delegation-02 and 
draft-ietf-nemo-dhcpv6-pd-02 which is expired and the main author (Ralph) 
has not been actively participating in the discussions.

Here is my evaluation: draft-ietf-nemo-prefix-delegation-02 is written
to close a gap in RFC 3963. I believe what it proposes (MR requesting
prefix and HA sending prefix) should have been part of 
the base protocol. Also the draft is misnamed I think, 
what the draft proposes is not PD. It leads the way to use PD and maybe that's
why the authors called it nemo PD.
The other draft,
 draft-ietf-nemo-dhcpv6-pd-02 is about
dhcp PD, it has already expired, there are problems
(some indicated in draft-ietf-nemo-prefix-delegation-02
) in this draft.

Overall my suggestion is to go with draft-ietf-nemo-prefix-delegation-02

but ask the authors to give a better name to it. There are
also several other typos that need to be cleaned.

As for draft-ietf-nemo-dhcpv6-pd-02
, it could be considered if the authors revise it in view of the 
comments.

I hope this helps.

Regards,

Behcet

----- Original Message ----
From: Julien Laganier <julien.IETF@laposte.net>
To: mext@ietf.org
Sent: Tuesday, November 27, 2007 8:32:16 AM
Subject: Re: [MEXT] Next steps on prefix delegation

Hello TJ,

On Monday 26 November 2007, T.J. Kniveton wrote:
> I think that Ryuji's message shows that:
>
> If you want to select one prefix delegation mechanism for NEMO, and
> have it fit a situation where a mobile network is away from the home
> infrastructure, and have the number of messages passed be reasonably
> low, with low complexity...
>
> then, more engineering work is needed.

I am not really sure about what Ryuji message shows ;) At any rate it
doesn't answer the two questions I've put forth to try to understand
if/why a single solution isn't doable (What could possibly make the
existing DHCPv6 PD unsuitable to be used for NEMO PD? In case DHCPv6 is
suitable but introduces limitations in the context of NEMO that makes
it desirable to standardize another prefix delegation mechanism for
NEMO, what would be the limitations?). Please note that these questions
were not intended to take side with one proposal or the other but
rather try to gain understanding so that we have a consensus on what is
the best choice.

Our charter only calls for a single prefix delegation mechanism to be
published as proposed standard, and I also think that it is a
reasonable goal. I'd like the WG to agree on specification  on a single
mechanism. Thus, this note includes a number of questions.

Before we start to discuss about the number of messages incurred by
prefix delegation maybe it is worth to asnwer the following question:
 
  o Does the WG thinks that keeping the number of messages exchanged
    for prefix delegation when a MR boots in foreign network low is a
    requirement?

> As I said before, there is a reason that there are two drafts instead
> of one. If you consider this "several ways of doing the same thing"
> as per RFC 1958, then more work will be necessary to create one way
> of doing it that works well.

I think it is fine for the WG to spend more time if it allows
specification of a single, unified mechanism.

W.r.t. the work needed to make a single mechanism work well, is there's
an understanding of the missing parts of either of the proposals:

  o What is missing in the nemo-dhcpv6-pd draft to make it work well?

  o What is missing in the nemo-prefix-delegation draft to make it work
    well?

> If, on the other hand, you want to make the assumption that any
> network with NEMO will have DHCP deployed, and you are not concerned
> about bootstrapping a tunnel to the home network to exchange DHCP
> messages, then DHCP is the way to go.

That would not only be making an assumption, but in fact making DHCPv6
PD part of the specification for prefix delegation in NEMO. The second
part of your sentence also bring one question:

    o What are the issues related to bootstrapping a tunnel to the
      home network to exhange DHCP messages?

> But in this case, the minimum effort needed would be to lay out the
> assumptions and have some consensus in the group that this is a
> reasonable engineering compromise.

Seems like a reasonable way to go.

--julien

> RYUJI WAKIKAWA wrote:
> > Hi Julien and all,
> >
> > Agree that solo solution is always better, but I support both
> > solutions for MNP delegation.
> >
> > DHCP PD is simple solution, but it requires DHCP functionalities at
> > HA and MR.
> > DHDP PD seems practical when MR boots up in home network.
> > However, when MR boots up in foreign network, MR must creates a
> > tunnel to send any DHCP messages.
> > It means it takes several message exchanges between MR and HA to
> > get MNP in bootstrap.
> >
> > PMIP uses similar way of NEMO PD to assign prefix to MN during
> > binding registration.
> > If MR uses IKE for HoA assignment, it can setup a tunnel and obtain
> > its MNP simultaneously by initial BU.
> >
> > We have to remember that MR is also MIP6-MN.  MIP6 WG standardized
> > several ways to assign HoA to  MN.
> >
> > Another question is that shall we have a mechanism to assign HoA
> > and prefix at the same time?
> > We should update both documents or write another document how NEMO
> > bootstrap work
> > with MIP6 bootstrap mechanisms.
> >
> > There are certainly pros & cons. Operator should select one.
> >
> > regards
> > ryuji
> >
> > On 2007/11/26, at 22:28, Julien Laganier wrote:
> >> Folks,
> >>
> >> Please see below:
> >>
> >> On Sunday 25 November 2007, marcelo bagnulo braun wrote:
> >>> Hi all,
> >>>
> >>> With respect to the NEMO prefix delegation issue, it is my
> >>> opinion that it would be preferred to have a single prefix
> >>> delegation solution rather than two. Moreover, that we should
> >>> have strong technical reasons to do more than one solution since
> >>> this variety of mechanisms without strong reasons adds needless
> >>> complexity.
> >>>
> >>> So, my first question to the working group is: do you think there
> >>> are strong technical reasons to have more than one solution for
> >>> prefix delegation?
> >>>
> >>> If no, then which would be the preferred approach for prefix
> >>> delegation and why?
> >>>
> >>> Out goal is to try to wrap up this discussion in the next meting
> >>
> >> I would like to complement Marcelo's question with some more
> >> questions from my side. I am quoting below one of the
> >> Architectural Principles of the Internet [RFC1958]:
> >>
> >>    3.2 If there are several ways of doing the same thing, choose
> >> one. If a previous design, in the Internet context or elsewhere,
> >> has successfully solved the same problem, choose the same solution
> >> unless there is a good technical reason not to.  Duplication of
> >> the same protocol functionality should be avoided as far as
> >> possible, without of course using this argument to reject
> >> improvements.
> >>
> >> In light of this, it seems to me that we should select one
> >> mechanism only for prefix delegation in the context of NEMO. If
> >> DHCPv6-PD would work, it seems that it should be the only solution
> >> adopted. Things are not that simple however and it is possible
> >> that very good reasons justify the specification of a new
> >> mechanism for prefix delegation in the context of NEMO.
> >>
> >> To help the WG understand the tradeoffs involved and make an
> >> educated choice, I'd like to ask the following questions:
> >>
> >>    o What could possibly make the existing DHCPv6 PD unsuitable to
> >> be used for NEMO PD?
> >>
> >>    o In case DHCPv6 is suitable but introduces limitations in the
> >>      context of NEMO that makes it desirable to standardize
> >> another prefix delegation mechanism for NEMO, what would be the
> >> limitations?
> >>
> >> Once we have answered these questions I believe the WG will be in
> >> the best position to make the best choice.
> >>
> >> Cheers,
> >>
> >> --julien
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www1.ietf.org/mailman/listinfo/mext



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

--0-1424675070-1196186031=:55804-- --===============0244512893== 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 --===============0244512893==-- From RosariowhirligigGuidry@calculator.com Tue Nov 27 15:15:32 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix6qB-0001mm-KE; Tue, 27 Nov 2007 15:15:31 -0500 Received: from [220.157.64.80] (helo=brady) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ix6q9-0001Ve-Br; Tue, 27 Nov 2007 15:15:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host31053307.calculator.com (8.13.1/8.13.1) with SMTP id ecsdQqgp69.958673.XAR.kj3.9257817261557 for ; Wed, 28 Nov 2007 06:13:35 -1000 Message-ID: From: "Polly Guidry" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_CD71_01C83132.39160790-- From mext-bounces@ietf.org Tue Nov 27 18:27: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 1Ix9pS-000474-B2; Tue, 27 Nov 2007 18:26:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix9pQ-00046Y-Eu for mext@ietf.org; Tue, 27 Nov 2007 18:26:56 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix9pN-0006Yb-V3 for mext@ietf.org; Tue, 27 Nov 2007 18:26:56 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Nov 2007 15:26:53 -0800 Message-ID: <474CA7BB.9000007@azairenet.com> Date: Tue, 27 Nov 2007 15:26:51 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hannes Tschofenig , Alper Yegin , George Tsirtsis , Sri Gundavelli Subject: Re: [MEXT] Prefix delegation & Diameter Interaction References: <0MKp8S-1IwdRx2OQq-0008Gc@mrelay.perfora.net> <474B12F7.8000700@azairenet.com> <474B2270.8080405@gmx.net> In-Reply-To: <474B2270.8080405@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2007 23:26:53.0235 (UTC) FILETIME=[FE36F830:01C8314C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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 Hannes, Here are some pointers to previous discussions. Took me some time to find this. IETF archives are not designed for searching. - http://www1.ietf.org/mail-archive/web/mip6/current/msg06023.html This thread was about DHCP should be used to assign home address from the NAS (access router). RADIUS/Diameter is used to deliver the home address from the AAA to the NAS. - http://www1.ietf.org/mail-archive/web/mip6/current/msg06554.html This thread talks about AAA or the HA assigning a home address. - http://www1.ietf.org/mail-archive/web/netlmm/current/msg02515.html This thread was on the NETLMM mailing list. It was about AAA managing prefixes for PMIPv6 instead of the LMA and the AAA delivering the prefixes to the MAG. There was quite bit of discussion on this during the Prague meeting. Mostly hallway discussions. Don't have pointers to that. This was just after the WG last call for draft-ietf-mip6-hiopt. There might have been more, but can't spend any more time on this. Sorry. Anyway, AFAIK, we have always concluded that the home agent or some other entity on the home link (DHCP server) manages the home addresses and the home prefixes. George, Sri, you guys had also sent emails asking for pointers. Patience please. It takes quite a bit of time to search through the archives. Vijay Hannes Tschofenig wrote: > Hi Vijay, > > maybe you can provide some pointers to past discussions and conclusions. > You cannot expect that everyone follows all mailing lists and now this > work is being proposed for DIME. > > Ciao > Hannes > > PS: I once had comments for a QoS document and I got the following > response "I don't have time to give you a tutorial on this QoS issue. We > discussed this at length in face-to-face meeting at the IETF XYZ meeting." > > The document got delayed for more than a year when the same questions > showed up later again.... > > Vijay Devarapalli wrote: >> Alper Yegin wrote: >>> Vijay, >>> >>> Can you explain why you do not recommend AAA-assignment of prefixes? >> >> We have been through this many times on the MIP6 mailing list. >> The earlier discussions were based on AAA assigning the home >> address. We have always concluded otherwise. I don't see much >> different between AAA managing home prefixes and home addresses. >> I am not planning to rehash those discussions. >> >> Vijay >> >> >>> >>> Alper >>> >>>> -----Original Message----- >>>> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >>>> Sent: Sunday, November 25, 2007 7:17 PM >>>> To: Hannes Tschofenig >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Prefix delegation & Diameter Interaction >>>> >>>> Well, this document seems to assume (or make a case) that the AAA >>>> manages the prefixes. We *do not* recommend that model. It is >>>> typically either the home agent or a DHCP server co-located with >>>> the home agent that manages the prefixes. >>>> >>>> Vijay >>>> >>>> Hannes Tschofenig wrote: >>>>> Hi all, >>>>> >>>>> in the DIME working group we have a document that provides the >>>>> Diameter >>>>> interworking for prefix delegation. >>>>> Here is the document: >>>>> http://tools.ietf.org/wg/dime/draft-sarikaya-dime-prefix-delegation-ps- >>>>> >>>> 00.txt >>>>> >>>>> It would help us in DIME if members of this group could give us some >>>>> feedback. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 27 19:37:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxAvg-0008Rw-6H; Tue, 27 Nov 2007 19:37:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxAve-0008QY-Cw for mext@ietf.org; Tue, 27 Nov 2007 19:37:26 -0500 Received: from deimos.multihop.net ([74.0.36.190] helo=multihop.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxAvZ-0001t5-Fw for mext@ietf.org; Tue, 27 Nov 2007 19:37:22 -0500 Received: by deimos.multihop.net (Postfix, from userid 1013) id 9BA40A05F26; Tue, 27 Nov 2007 16:37:20 -0800 (PST) X-Spam-Score: -4.4 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on deimos.multihop.net X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Received: from [192.168.4.25] (ibmx31.tehama.multihop.net [192.168.4.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 8039DA05086; Tue, 27 Nov 2007 16:37:15 -0800 (PST) Message-ID: <474CB83B.1020802@kniveton.com> Date: Tue, 27 Nov 2007 16:37:15 -0800 From: "T.J. Kniveton" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [MEXT] Prefix delegation & Diameter Interaction References: <0MKp8S-1IwdRx2OQq-0008Gc@mrelay.perfora.net> <474B12F7.8000700@azairenet.com> <474B2270.8080405@gmx.net> <474CA7BB.9000007@azairenet.com> In-Reply-To: <474CA7BB.9000007@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: Hannes Tschofenig , 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 FYI, if it helps in your search.. I have all of the MIP, MIP6, MIP4, NEMO, MIPSHOP,.. working group messages archived on my email server for a number of years. It also has anonymous IMAP and a webmail interface so you can search using your mail client (IMAP/POP) or the web. If you want to use that just let me know and I'll give you instructions. It can make searching significantly faster. TJ Vijay Devarapalli wrote: > Hi Hannes, > > Here are some pointers to previous discussions. Took me some time > to find this. IETF archives are not designed for searching. > > - http://www1.ietf.org/mail-archive/web/mip6/current/msg06023.html > > This thread was about DHCP should be used to assign home address > from the NAS (access router). RADIUS/Diameter is used to deliver > the home address from the AAA to the NAS. > > - http://www1.ietf.org/mail-archive/web/mip6/current/msg06554.html > > This thread talks about AAA or the HA assigning a home address. > > - http://www1.ietf.org/mail-archive/web/netlmm/current/msg02515.html > > This thread was on the NETLMM mailing list. It was about AAA managing > prefixes for PMIPv6 instead of the LMA and the AAA delivering the > prefixes to the MAG. > > There was quite bit of discussion on this during the Prague meeting. > Mostly hallway discussions. Don't have pointers to that. This was > just after the WG last call for draft-ietf-mip6-hiopt. > > There might have been more, but can't spend any more time on this. > Sorry. Anyway, AFAIK, we have always concluded that the home agent > or some other entity on the home link (DHCP server) manages the > home addresses and the home prefixes. > > George, Sri, you guys had also sent emails asking for pointers. > Patience please. It takes quite a bit of time to search through > the archives. > > Vijay > > Hannes Tschofenig wrote: >> Hi Vijay, >> >> maybe you can provide some pointers to past discussions and >> conclusions. You cannot expect that everyone follows all mailing >> lists and now this work is being proposed for DIME. >> >> Ciao >> Hannes >> >> PS: I once had comments for a QoS document and I got the following >> response "I don't have time to give you a tutorial on this QoS issue. >> We discussed this at length in face-to-face meeting at the IETF XYZ >> meeting." >> >> The document got delayed for more than a year when the same questions >> showed up later again.... >> >> Vijay Devarapalli wrote: >>> Alper Yegin wrote: >>>> Vijay, >>>> >>>> Can you explain why you do not recommend AAA-assignment of prefixes? >>> >>> We have been through this many times on the MIP6 mailing list. >>> The earlier discussions were based on AAA assigning the home >>> address. We have always concluded otherwise. I don't see much >>> different between AAA managing home prefixes and home addresses. >>> I am not planning to rehash those discussions. >>> >>> Vijay >>> >>> >>>> >>>> Alper >>>> >>>>> -----Original Message----- >>>>> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >>>>> Sent: Sunday, November 25, 2007 7:17 PM >>>>> To: Hannes Tschofenig >>>>> Cc: mext@ietf.org >>>>> Subject: Re: [MEXT] Prefix delegation & Diameter Interaction >>>>> >>>>> Well, this document seems to assume (or make a case) that the AAA >>>>> manages the prefixes. We *do not* recommend that model. It is >>>>> typically either the home agent or a DHCP server co-located with >>>>> the home agent that manages the prefixes. >>>>> >>>>> Vijay >>>>> >>>>> Hannes Tschofenig wrote: >>>>>> Hi all, >>>>>> >>>>>> in the DIME working group we have a document that provides the >>>>>> Diameter >>>>>> interworking for prefix delegation. >>>>>> Here is the document: >>>>>> http://tools.ietf.org/wg/dime/draft-sarikaya-dime-prefix-delegation-ps- >>>>>> >>>>> 00.txt >>>>>> >>>>>> It would help us in DIME if members of this group could give us some >>>>>> feedback. >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >> > > > _______________________________________________ > 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 Nov 27 19:39:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxAxF-0001E5-Bt; Tue, 27 Nov 2007 19:39:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxAxD-0001Dc-PT for mext@ietf.org; Tue, 27 Nov 2007 19:39:03 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxAxD-0007aw-2P for mext@ietf.org; Tue, 27 Nov 2007 19:39:03 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Nov 2007 16:39:02 -0800 Message-ID: <474CB8A6.10502@azairenet.com> Date: Tue, 27 Nov 2007 16:39:02 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "T.J. Kniveton" Subject: Re: [MEXT] Prefix delegation & Diameter Interaction References: <0MKp8S-1IwdRx2OQq-0008Gc@mrelay.perfora.net> <474B12F7.8000700@azairenet.com> <474B2270.8080405@gmx.net> <474CA7BB.9000007@azairenet.com> <474CB83B.1020802@kniveton.com> In-Reply-To: <474CB83B.1020802@kniveton.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2007 00:39:02.0379 (UTC) FILETIME=[1295EBB0:01C83157] X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: Hannes Tschofenig , 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 T.J. Kniveton wrote: > FYI, if it helps in your search.. I have all of the MIP, MIP6, MIP4, > NEMO, MIPSHOP,.. working group messages archived on my email server for > a number of years. It also has anonymous IMAP and a webmail interface so > you can search using your mail client (IMAP/POP) or the web. > > If you want to use that just let me know and I'll give you instructions. > It can make searching significantly faster. That would be awesome. Thanks Vijay > > TJ > > Vijay Devarapalli wrote: >> Hi Hannes, >> >> Here are some pointers to previous discussions. Took me some time >> to find this. IETF archives are not designed for searching. >> >> - http://www1.ietf.org/mail-archive/web/mip6/current/msg06023.html >> >> This thread was about DHCP should be used to assign home address >> from the NAS (access router). RADIUS/Diameter is used to deliver >> the home address from the AAA to the NAS. >> >> - http://www1.ietf.org/mail-archive/web/mip6/current/msg06554.html >> >> This thread talks about AAA or the HA assigning a home address. >> >> - http://www1.ietf.org/mail-archive/web/netlmm/current/msg02515.html >> >> This thread was on the NETLMM mailing list. It was about AAA managing >> prefixes for PMIPv6 instead of the LMA and the AAA delivering the >> prefixes to the MAG. >> >> There was quite bit of discussion on this during the Prague meeting. >> Mostly hallway discussions. Don't have pointers to that. This was >> just after the WG last call for draft-ietf-mip6-hiopt. >> >> There might have been more, but can't spend any more time on this. >> Sorry. Anyway, AFAIK, we have always concluded that the home agent >> or some other entity on the home link (DHCP server) manages the >> home addresses and the home prefixes. >> >> George, Sri, you guys had also sent emails asking for pointers. >> Patience please. It takes quite a bit of time to search through >> the archives. >> >> Vijay >> >> Hannes Tschofenig wrote: >>> Hi Vijay, >>> >>> maybe you can provide some pointers to past discussions and >>> conclusions. You cannot expect that everyone follows all mailing >>> lists and now this work is being proposed for DIME. >>> >>> Ciao >>> Hannes >>> >>> PS: I once had comments for a QoS document and I got the following >>> response "I don't have time to give you a tutorial on this QoS issue. >>> We discussed this at length in face-to-face meeting at the IETF XYZ >>> meeting." >>> >>> The document got delayed for more than a year when the same questions >>> showed up later again.... >>> >>> Vijay Devarapalli wrote: >>>> Alper Yegin wrote: >>>>> Vijay, >>>>> >>>>> Can you explain why you do not recommend AAA-assignment of prefixes? >>>> >>>> We have been through this many times on the MIP6 mailing list. >>>> The earlier discussions were based on AAA assigning the home >>>> address. We have always concluded otherwise. I don't see much >>>> different between AAA managing home prefixes and home addresses. >>>> I am not planning to rehash those discussions. >>>> >>>> Vijay >>>> >>>> >>>>> >>>>> Alper >>>>> >>>>>> -----Original Message----- >>>>>> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >>>>>> Sent: Sunday, November 25, 2007 7:17 PM >>>>>> To: Hannes Tschofenig >>>>>> Cc: mext@ietf.org >>>>>> Subject: Re: [MEXT] Prefix delegation & Diameter Interaction >>>>>> >>>>>> Well, this document seems to assume (or make a case) that the AAA >>>>>> manages the prefixes. We *do not* recommend that model. It is >>>>>> typically either the home agent or a DHCP server co-located with >>>>>> the home agent that manages the prefixes. >>>>>> >>>>>> Vijay >>>>>> >>>>>> Hannes Tschofenig wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> in the DIME working group we have a document that provides the >>>>>>> Diameter >>>>>>> interworking for prefix delegation. >>>>>>> Here is the document: >>>>>>> http://tools.ietf.org/wg/dime/draft-sarikaya-dime-prefix-delegation-ps- >>>>>>> >>>>>> 00.txt >>>>>>> >>>>>>> It would help us in DIME if members of this group could give us some >>>>>>> feedback. >>>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>> >> >> >> _______________________________________________ >> 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 Nov 27 22:34:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxDhG-0003Dp-17; Tue, 27 Nov 2007 22:34:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxDhD-0003DU-PR for mext@ietf.org; Tue, 27 Nov 2007 22:34:43 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxDhB-0001Ft-LV for mext@ietf.org; Tue, 27 Nov 2007 22:34:43 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id lAS3YQnK021467; Wed, 28 Nov 2007 12:34:26 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id lAS3YRC03614; Wed, 28 Nov 2007 12:34:27 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id lAS3YPZ27255; Wed, 28 Nov 2007 12:34:25 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 11:34:14 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Wed, 28 Nov 2007 11:34:11 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Wed, 28 Nov 2007 11:34:11 +0800 From: "Benjamin Lim" To: "'George Tsirtsis'" Subject: RE: [MEXT] Comments on draft-ietf-monami6-multiplecoa-04.txt Date: Wed, 28 Nov 2007 11:34:11 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acgw8pbIfoBNWq+6QP2ntjzirNz18QAdhReg In-Reply-To: Message-ID: X-OriginalArrivalTime: 28 Nov 2007 03:34:14.0845 (UTC) FILETIME=[8C80EED0:01C8316F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 George, Thanks for having a look at the draft. My reply inline. > -----Original Message----- > From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > Sent: Tuesday, November 27, 2007 8:40 PM > To: Benjamin Lim > Cc: RYUJI WAKIKAWA; mext@ietf.org > Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-04.txt > > The draft describes how one can cause a CN to send downlink > traffic and then redirect that traffic to the target using > MCoA+flow. One observation is that this is also possible > (although in a more limited > way) with plain MIPv6 e.g., triger a large UDP streaming > download and then handoff to the target's CoA to cause flooding. > > I am not sure this is a really good attack though, given the > fact that the attacker's identity is known to the HA i.e., > the attacker can get caught. [Ben] Let me clarify one thing. I understand most of us view most hackers as someone hiding his/her identity when causing havoc in the system to prevent being caught. However, there are those hackers that hack into nodes to try and control them (e.g. spyware, bots). When this type of hacker controls a node with Monami6 function, it can cause the node to unwitting bind victims' CoA at the HA and redirect large traffic to them, thereby flooding those CoAs. So, inevitably, the attacker has created a 'scapegoat' for his/her action. Fine, the HA knows the identity of the node, but that is not the 'real' attacker's identity. In the draft, it also provided another example saying that the attacker has create multiple 'fake' IDs to deter from being identified. To sum up, what I am trying to say is having 'HA know identity' does not mean that nodes will not bind 'fake' CoA at HA. There are work-around to the identity factor. In one sense, if the attacker is really motivated enough, such attack can still be performed even if he/she knows that HA has the identity. Its like playing 'cat & mouse' with the attacker screaming "Catch me if you can!" Hence, it might be worth considering providing some function at HA to further reduce the chances of such issue of 'fake' CoA binding from occurring. Regards, Benjamin Lim > It may, however, have some value as an attack if the attacker > actually owns the HA, and thus can not be traced as such. In > such a case, however, it might be easier for the attacker to > run a random traffic generator and flood whatever address it > wants from the HA directly. > > Am I missing something? > George _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Nov 28 02:44: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 1IxHar-0002lH-Bh; Wed, 28 Nov 2007 02:44:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxHam-0002Ql-TG for mext@ietf.org; Wed, 28 Nov 2007 02:44:21 -0500 Received: from ug-out-1314.google.com ([66.249.92.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxHam-0007jl-8z for mext@ietf.org; Wed, 28 Nov 2007 02:44:20 -0500 Received: by ug-out-1314.google.com with SMTP id u2so1510795uge for ; Tue, 27 Nov 2007 23:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=rUwN1Zt1wCaQLqbTUOexsLxnVnl1yGSy+jNJTFVAxak=; b=LH002bFd9G7/YL2bhv6r/HXp1ZNjT8/N6+D2BWS6P+6S8PYQM1vSTJMlp6bBGp4pzug137+Xc1UHSC2YFfp+BlxmmZoQaEULabm0V2YAV/3IeCfWdyaVrMyODhUiK7BNHLKOMLZDwH/R+3n0Nltsj9voh4OaoenDDfq8KD+oBj0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=teyYmGL5UBTiwgFW6mH5Z/mkVq3Itl9AXWPo6NZ2UWgo3PTCyJyCkehJr+SOotX3KYjVTdYQS512ZsduJ4mlFOHZH5GtVhFaPZUfd0lVGSGOQ6MSo9zc/Cs6I2EXmBPPG6Zjx4YMKmPWyZaIiDbxSxev/pdono4y0wQ6Wmmv9Vc= Received: by 10.66.243.4 with SMTP id q4mr265855ugh.1196235859067; Tue, 27 Nov 2007 23:44:19 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id e34sm2934644ugd.2007.11.27.23.44.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Nov 2007 23:44:18 -0800 (PST) From: Julien Laganier To: mext@ietf.org Date: Wed, 28 Nov 2007 08:44:38 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711280844.39184.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [MEXT] MEXT - Requested sessions have been scheduled for IETF 70 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, MEXT has been schedule as follows: ---------------------------------------------- MEXT Session 1 (2.5 hours) Tuesday, Morning Session I 0900-1130 Room Name: Salon A ---------------------------------------------- MEXT Session 2 (2.5 hours) Friday, Morning Session I 0900-1130 Room Name: Salon 3 ---------------------------------------------- --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Nov 28 03:49: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 1IxIbL-0000mF-FH; Wed, 28 Nov 2007 03:48:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxIbJ-0000lv-BO for mext@ietf.org; Wed, 28 Nov 2007 03:48:57 -0500 Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxIbH-0007PZ-AL for mext@ietf.org; Wed, 28 Nov 2007 03:48:57 -0500 Received: from etriabcb8a0047 ([129.254.112.107]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 17:55:22 +0900 Message-ID: <001001c8319b$82d66640$6b70fe81@etriabcb8a0047> From: "Junghoon Jee" To: "Julien Laganier" , References: <200711280844.39184.julien.IETF@laposte.net> Subject: Re: [MEXT] MEXT - Requested sessions have been scheduled for IETF 70 Date: Wed, 28 Nov 2007 17:48:56 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 28 Nov 2007 08:55:22.0238 (UTC) FILETIME=[68C3C9E0:01C8319C] X-Spam-Score: 2.8 (++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: 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="===============0513088837==" Errors-To: mext-bounces@ietf.org --===============0513088837== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgSnVsaWVuLA0KDQpTbyB0aGUgdHJpYWwgd2hpY2ggUmFqIG1lbnRpb25lZCB0byBtb3ZlIHRo ZSBGcmlkYXkgbW9ybmluZyBzZXNzaW9uIHRvIFR1ZXNkYXkgbmlnaHQgc2Vzc2lvbiB3YXMgbm90 IHN1Y2Nlc3NmdWw/DQpJcyB0aGlzIHRoZSBmaW5hbCBhZ2VuZGE/IA0KDQpCUiwNCkp1bmdob29u DQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSnVsaWVuIExhZ2FuaWVy IiA8anVsaWVuLklFVEZAbGFwb3N0ZS5uZXQ+DQpUbzogPG1leHRAaWV0Zi5vcmc+DQpTZW50OiBX ZWRuZXNkYXksIE5vdmVtYmVyIDI4LCAyMDA3IDQ6NDQgUE0NClN1YmplY3Q6IFtNRVhUXSBNRVhU IC0gUmVxdWVzdGVkIHNlc3Npb25zIGhhdmUgYmVlbiBzY2hlZHVsZWQgZm9yIElFVEYgNzANCg0K DQo+IA0KPiBGb2xrcywNCj4gDQo+IE1FWFQgaGFzIGJlZW4gc2NoZWR1bGUgYXMgZm9sbG93czoN Cj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g TUVYVCBTZXNzaW9uIDEgKDIuNSBob3VycykNCj4gVHVlc2RheSwgTW9ybmluZyBTZXNzaW9uIEkg MDkwMC0xMTMwDQo+IFJvb20gTmFtZTogU2Fsb24gQQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IE1FWFQgU2Vzc2lvbiAyICgyLjUgaG91cnMpDQo+ IEZyaWRheSwgTW9ybmluZyBTZXNzaW9uIEkgMDkwMC0xMTMwDQo+IFJvb20gTmFtZTogU2Fsb24g Mw0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0K PiAtLWp1bGllbg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gTUVYVCBtYWlsaW5nIGxpc3QNCj4gTUVYVEBpZXRmLm9yZw0KPiBodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZXh0 --===============0513088837== 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 --===============0513088837==-- From mext-bounces@ietf.org Wed Nov 28 05:27:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxK8R-0006XV-35; Wed, 28 Nov 2007 05:27:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxK8P-0006XN-F7 for mext@ietf.org; Wed, 28 Nov 2007 05:27:13 -0500 Received: from rv-out-0910.google.com ([209.85.198.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxK8O-0004mV-SE for mext@ietf.org; Wed, 28 Nov 2007 05:27:13 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1100625rvb for ; Wed, 28 Nov 2007 02:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; 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; bh=tglTA9pj4E20JqdbGVvkI27pWwhLdmeoPLQVso1feAw=; b=gCeOp7Ljr4MTMEsMUFbex/PpoGrW5hzbNDhg6BAZ0qyCVwV/2AQQG4jqVk/4g0DUFGytxS7HA0Wr/vEVRI0vn1trUXBh/UpTg6Vynuky43fWZcs87g0PoDcLqk53e2t9jjd/pEDn+gzitbZUXMVJwgDoB0MvRhzDcFKe1HsSBY0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ly/QN0HIQTbimeWpKXUSePY7P+udKv/w+iSScuCGX0gJ/5O4vFiF4QJMut8xMNdhs0DWbg+ZRvpuTUrSMXMd8RIC7/99vnX/mGtQnJY0FveW197z7o9PyQtuv+cP6nsIzzDOIsRGpgpk8gIRBXv3wPG1ahc/EaiS7RlGnyzujLc= Received: by 10.141.195.18 with SMTP id x18mr2464048rvp.1196245632158; Wed, 28 Nov 2007 02:27:12 -0800 (PST) Received: by 10.140.135.15 with HTTP; Wed, 28 Nov 2007 02:27:12 -0800 (PST) Message-ID: Date: Wed, 28 Nov 2007 10:27:12 +0000 From: "George Tsirtsis" To: "Benjamin Lim" Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-04.txt In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 OK, you have a point. Thanks for the clarification. George On Nov 28, 2007 3:34 AM, Benjamin Lim wrote: > Hi George, > > Thanks for having a look at the draft. My reply inline. > > > -----Original Message----- > > From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > > Sent: Tuesday, November 27, 2007 8:40 PM > > To: Benjamin Lim > > Cc: RYUJI WAKIKAWA; mext@ietf.org > > Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-04.txt > > > > The draft describes how one can cause a CN to send downlink > > traffic and then redirect that traffic to the target using > > MCoA+flow. One observation is that this is also possible > > (although in a more limited > > way) with plain MIPv6 e.g., triger a large UDP streaming > > download and then handoff to the target's CoA to cause flooding. > > > > I am not sure this is a really good attack though, given the > > fact that the attacker's identity is known to the HA i.e., > > the attacker can get caught. > [Ben] Let me clarify one thing. I understand most of us view most hackers as > someone hiding his/her identity when causing havoc in the system to prevent > being caught. However, there are those hackers that hack into nodes to try > and control them (e.g. spyware, bots). When this type of hacker controls a > node with Monami6 function, it can cause the node to unwitting bind victims' > CoA at the HA and redirect large traffic to them, thereby flooding those > CoAs. So, inevitably, the attacker has created a 'scapegoat' for his/her > action. Fine, the HA knows the identity of the node, but that is not the > 'real' attacker's identity. In the draft, it also provided another example > saying that the attacker has create multiple 'fake' IDs to deter from being > identified. > > To sum up, what I am trying to say is having 'HA know identity' does not > mean that nodes will not bind 'fake' CoA at HA. There are work-around to the > identity factor. In one sense, if the attacker is really motivated enough, > such attack can still be performed even if he/she knows that HA has the > identity. Its like playing 'cat & mouse' with the attacker screaming "Catch > me if you can!" > > Hence, it might be worth considering providing some function at HA to > further reduce the chances of such issue of 'fake' CoA binding from > occurring. > > Regards, > Benjamin Lim > > > > It may, however, have some value as an attack if the attacker > > actually owns the HA, and thus can not be traced as such. In > > such a case, however, it might be easier for the attacker to > > run a random traffic generator and flood whatever address it > > wants from the HA directly. > > > > Am I missing something? > > George > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Nov 28 07:49: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 1IxMLQ-0007WM-3x; Wed, 28 Nov 2007 07:48:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMLO-0007QO-A4 for mext@ietf.org; Wed, 28 Nov 2007 07:48:46 -0500 Received: from ug-out-1314.google.com ([66.249.92.169]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxMLN-0001lB-Rm for mext@ietf.org; Wed, 28 Nov 2007 07:48:46 -0500 Received: by ug-out-1314.google.com with SMTP id u2so1620473uge for ; Wed, 28 Nov 2007 04:48:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=nEtiLlO6QiApy21dXdYUq4zITJf+BU8TfTXV7VkJVJk=; b=MYfs5wauORsUr3QijzjJ6XjXit63OUcoYQvilrSA9XEX627j/CMAL/RKR5MQe1pJRSHgVT/3udwnbKzJgv4m8bQO1XNEIguupzD8IubEziWaPE2JgvxyFs6fpMZcVldEA1qrB/uwaPFu63Ua9hpSzIZUxTk4QoGIbAyFk5VuQeI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=vBrWoeX2gOS+9x2vXrMsVVmVV4I4DM2McPoCERMteEvg7rzyP7OSUhYdtPVJnRXT0k/Up7EL4RyMfT/j4G0fB4skvViBQbf5YbwvRAO2SX+6rJh3ByEAl5Ha+JWWhEXr02jljBtCX9Hj2aeiTv/qukgipLK3UqMeIwTTHaE8Tug= Received: by 10.67.196.2 with SMTP id y2mr487008ugp.1196254124555; Wed, 28 Nov 2007 04:48:44 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id q40sm3368045ugc.2007.11.28.04.48.42 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Nov 2007 04:48:43 -0800 (PST) From: Julien Laganier To: mext@ietf.org Subject: Re: [MEXT] MEXT - Requested sessions have been scheduled for IETF 70 Date: Wed, 28 Nov 2007 13:49:06 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200711280844.39184.julien.IETF@laposte.net> <001001c8319b$82d66640$6b70fe81@etriabcb8a0047> In-Reply-To: <001001c8319b$82d66640$6b70fe81@etriabcb8a0047> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711281349.07062.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: 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 Hello Junghoon, Moving Friday morning session to earlier in the week (possibly Tuesday) is still ongoing. We'll keep you informed as soon as the secretariat replies to us. Cheers, --julien On Wednesday 28 November 2007, Junghoon Jee wrote: > Hi Julien, > > So the trial which Raj mentioned to move the Friday morning session > to Tuesday night session was not successful? Is this the final > agenda? > > BR, > Junghoon > > ----- Original Message ----- > From: "Julien Laganier" > To: > Sent: Wednesday, November 28, 2007 4:44 PM > Subject: [MEXT] MEXT - Requested sessions have been scheduled for > IETF 70 > > > Folks, > > > > MEXT has been schedule as follows: > > > > ---------------------------------------------- > > MEXT Session 1 (2.5 hours) > > Tuesday, Morning Session I 0900-1130 > > Room Name: Salon A > > ---------------------------------------------- > > MEXT Session 2 (2.5 hours) > > Friday, Morning Session I 0900-1130 > > Room Name: Salon 3 > > ---------------------------------------------- > > > > --julien > > > > _______________________________________________ > > 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 WyattglaucomaCrane@shutterstock.com Wed Nov 28 22:09:22 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxZmE-0008Kq-NJ; Wed, 28 Nov 2007 22:09:22 -0500 Received: from static-71-250-254-98.nwrknj.east.verizon.net ([71.250.254.98] helo=gwnjp01) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxZmE-0004fT-C4; Wed, 28 Nov 2007 22:09:22 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host65082142.shutterstock.com (8.13.1/8.13.1) with SMTP id lSO2sjP289.482230.Kgp.79j.6362249547561 for ; Wed, 28 Nov 2007 22:08:55 +0500 Message-ID: <3fd801c83235$353f3750$35e211ac@GWNJP01> From: "Sydney Travis" To: Subject: Confirmation link Date: Wed, 28 Nov 2007 22:08:55 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_3FD4_01C83235.353F3750" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_3FD4_01C83235.353F3750 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_3FD4_01C83235.353F3750 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_3FD4_01C83235.353F3750-- From tello@alphaquad.com Wed Nov 28 23:17:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxaqU-0003jZ-1T; Wed, 28 Nov 2007 23:17:50 -0500 Received: from [189.135.55.103] (helo=gig-d6c844b9a08) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxaqS-00032w-66; Wed, 28 Nov 2007 23:17:50 -0500 Received: from [189.135.55.103] by mx73a.emailfiltering.com; Wed, 28 Nov 2007 22:17:42 -0600 From: "Major Vera" To: Subject: Magnet Album Man Printer Woman Computer Mist Date: Wed, 28 Nov 2007 22:17:42 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aca6QIGJJ365GC0BC41X90U3TWSR8M== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-ID: <01c8320c$7e73be10$673787bd@tello> X-Spam-Score: 2.1 (++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Holiday gifts are on sale http://ladonnahutchensxn.googlepages.com From mext-bounces@ietf.org Thu Nov 29 03:52:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixf7o-0003GG-B2; Thu, 29 Nov 2007 03:52:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixf7m-0003D6-PP for mext@ietf.org; Thu, 29 Nov 2007 03:51:58 -0500 Received: from mail1.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixf7l-0001nx-4O for mext@ietf.org; Thu, 29 Nov 2007 03:51:58 -0500 X-AuditID: c26e2f18-00000a64000018d4-8b-474e7d9a254c Received: from camaro.eu.tieto.com ([192.176.143.43]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 10:51:38 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 09:51:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 Nov 2007 09:51:54 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dsmip port Thread-Index: AcgyZRcFLdNirIJ+SQy4ML090mzUxg== From: To: X-OriginalArrivalTime: 29 Nov 2007 08:51:55.0212 (UTC) FILETIME=[17C7E0C0:01C83265] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [MEXT] dsmip port 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="===============1734138341==" Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1734138341== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83265.177AE139" This is a multi-part message in MIME format. ------_=_NextPart_001_01C83265.177AE139 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Is there a defacto DSMIP port in usage in experimental implementations ? BR, Karen ------_=_NextPart_001_01C83265.177AE139 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable dsmip port

Hi,

Is there a defacto DSMIP port in usage = in experimental implementations ?

BR, Karen


------_=_NextPart_001_01C83265.177AE139-- --===============1734138341== 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 --===============1734138341==-- From mext-bounces@ietf.org Thu Nov 29 04: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 1IxfUJ-0007bx-2Y; Thu, 29 Nov 2007 04:15:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxfUH-0007Xx-Hk for mext@ietf.org; Thu, 29 Nov 2007 04:15:13 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxfUH-00041o-7x for mext@ietf.org; Thu, 29 Nov 2007 04:15:13 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1196327711!29921837!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 8616 invoked from network); 29 Nov 2007 09:15:12 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-5.tower-119.messagelabs.com with SMTP; 29 Nov 2007 09:15:12 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id lAT9FBBI003659; Thu, 29 Nov 2007 02:15:11 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lAT9FAlA011940; Thu, 29 Nov 2007 03:15:11 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id lAT9F8Wc011912; Thu, 29 Nov 2007 03:15:09 -0600 (CST) Message-ID: <474E831C.80805@gmail.com> Date: Thu, 29 Nov 2007 10:15:08 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Karen.Nielsen@tietoenator.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071125-0, 25/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: mext@ietf.org Subject: [MEXT] Re: [Mip6] DSMIP port 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 Karen, please allow me to redirect you to the MEXT list, hoping that's ok, MEXT is a new WG continuing the MIP6 activities] Karen.Nielsen@tietoenator.com wrote: > > Hi, > > Is there a defacto DSMIP port value in usage in experimental > implementations ? DSMIP implementations may exist out there. I sometimes run a prototype implementation of MIP4+MIP6 (not DSMIP) and when IPv6 needs to traverse a certain NAT it uses UDP port number 1750, after having searched an open port. I think other people may be running prototypes of pre-DSMIP or similar and they may be using different port numbers. Alex > > BR, Karen > > > > > ------------------------------------------------------------------------ > > > _______________________________________________ Mip6 mailing list > Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 29 04: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 1Ixfg0-0005Vo-Hh; Thu, 29 Nov 2007 04:27:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixffz-0005Uk-Ay for mext@ietf.org; Thu, 29 Nov 2007 04:27:19 -0500 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixffx-0006OL-SW for mext@ietf.org; Thu, 29 Nov 2007 04:27:18 -0500 Received: from oaamta05sl.mx.bigpond.com ([124.190.106.219]) by omta01sl.mx.bigpond.com with ESMTP id <20071129092714.SKBE9168.omta01sl.mx.bigpond.com@oaamta05sl.mx.bigpond.com> for ; Thu, 29 Nov 2007 09:27:14 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta05sl.mx.bigpond.com with ESMTP id <20071129092713.JWFZ14529.oaamta05sl.mx.bigpond.com@PC20005>; Thu, 29 Nov 2007 09:27:13 +0000 From: "Hesham Soliman" To: , Subject: RE: [MEXT] dsmip port Date: Thu, 29 Nov 2007 20:27:00 +1000 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AcgyZRcFLdNirIJ+SQy4ML090mzUxgADUG4A X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: 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="===============0586914556==" Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0586914556== Content-Type: multipart/alternative; boundary="----=_NextPart_000_018E_01C832C6.323581E0" This is a multi-part message in MIME format. ------=_NextPart_000_018E_01C832C6.323581E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nothing that I'm aware of. Hesham _____ From: Karen.Nielsen@tietoenator.com [mailto:Karen.Nielsen@tietoenator.com] Sent: Thursday, November 29, 2007 6:52 PM To: mext@ietf.org Subject: [MEXT] dsmip port Hi, Is there a defacto DSMIP port in usage in experimental implementations ? BR, Karen ------=_NextPart_000_018E_01C832C6.323581E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable dsmip port
Nothing that I'm aware of.
 
Hesham

From: = Karen.Nielsen@tietoenator.com=20 [mailto:Karen.Nielsen@tietoenator.com]
Sent: Thursday, = November 29,=20 2007 6:52 PM
To: mext@ietf.org
Subject: [MEXT] = dsmip=20 port

Hi,

Is there a defacto DSMIP port in usage = in=20 experimental implementations ?

BR, Karen =


------=_NextPart_000_018E_01C832C6.323581E0-- --===============0586914556== 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 --===============0586914556==-- From mext-bounces@ietf.org Thu Nov 29 05:28:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixgd6-0000w4-3q; Thu, 29 Nov 2007 05:28:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixgd4-0000vm-Av for mext@ietf.org; Thu, 29 Nov 2007 05:28:22 -0500 Received: from hu-out-0506.google.com ([72.14.214.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixgd3-0003KU-Rw for mext@ietf.org; Thu, 29 Nov 2007 05:28:22 -0500 Received: by hu-out-0506.google.com with SMTP id 31so2017539huc for ; Thu, 29 Nov 2007 02:28:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=qesWaFiOUtRROMdOqnJp8pBD2a8E/LXeloEBMrpxqOI=; b=IGpWmD+5GKbnUr+ZYsTVZEi+HcnaL93GB0s7ajwAhWJqXOdJyyow7rFEvW9REjDkjoCS+XMfezdDCeWQcBZPVGtctFqdMeBMAhoujmmY6ITuHzfTDOszbbvoAc6y4N2UHANNNI9m+v2xpoSphS5HF9X7kcaC6XhVMG+W75plpGg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=n51OXooyp56vUhgCOMpYQ0RLppg0jASftqsYIGcVo2iSqazCLWolUGHM0GQVpFMZjAZoTzGXxXLqzls2a5pGv3HRQWCVXXDnDPNkAgkf46ndb5DAFt4HenZnzKqZtV20Tx8Uj3j8CAhRyi9kiKi8E1YBlf8gtUO0AS2LioWfyGk= Received: by 10.82.123.16 with SMTP id v16mr4759666buc.1196332098607; Thu, 29 Nov 2007 02:28:18 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id d26sm3551395nfh.2007.11.29.02.28.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Nov 2007 02:28:17 -0800 (PST) From: Julien Laganier To: mext@ietf.org Subject: Re: [MEXT] MEXT - Requested sessions have been scheduled for IETF 70 Date: Thu, 29 Nov 2007 11:28:36 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200711280844.39184.julien.IETF@laposte.net> <001001c8319b$82d66640$6b70fe81@etriabcb8a0047> In-Reply-To: <001001c8319b$82d66640$6b70fe81@etriabcb8a0047> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711291128.36773.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: 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, It hasn't been possible to reschedule the 2nd MEXT session; We will thus meet as orginally planned: ---------------------------------------------- MEXT Session 1 (2.5 hours) Tuesday, Morning Session I 0900-1130 Room Name: Salon A ---------------------------------------------- MEXT Session 2 (2.5 hours) Friday, Morning Session I 0900-1130 Room Name: Salon 3 ---------------------------------------------- --julien > On Wednesday 28 November 2007, Junghoon Jee wrote: > Hi Julien, > > So the trial which Raj mentioned to move the Friday morning session > to Tuesday night session was not successful? Is this the final > agenda? > > BR, > Junghoon > > ----- Original Message ----- > From: "Julien Laganier" > To: > Sent: Wednesday, November 28, 2007 4:44 PM > Subject: [MEXT] MEXT - Requested sessions have been scheduled for > IETF 70 > > > Folks, > > > > MEXT has been schedule as follows: > > > > ---------------------------------------------- > > MEXT Session 1 (2.5 hours) > > Tuesday, Morning Session I 0900-1130 > > Room Name: Salon A > > ---------------------------------------------- > > MEXT Session 2 (2.5 hours) > > Friday, Morning Session I 0900-1130 > > Room Name: Salon 3 > > ---------------------------------------------- > > > > --julien > > > > _______________________________________________ > > 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 Thu Nov 29 05:31: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 1Ixgfn-0005um-0D; Thu, 29 Nov 2007 05:31:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixgfk-0005sC-Ch for mext@ietf.org; Thu, 29 Nov 2007 05:31:08 -0500 Received: from nf-out-0910.google.com ([64.233.182.186]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixgfj-00027Q-Rb for mext@ietf.org; Thu, 29 Nov 2007 05:31:08 -0500 Received: by nf-out-0910.google.com with SMTP id d21so1538093nfb for ; Thu, 29 Nov 2007 02:31:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:mime-version:content-type:message-id:sender; bh=JJkSQQ0vk8bGTgpcYa/rLxUrK6a75z+1M4JcDB9Doog=; b=Yo4Ro50xgdtAQI6XmIvxsOwbQawYlexZLa9t9RLR7CouxFPmiAkLU/MaFwg+oZnxoz8HOPGbCPR2mtHBxBZkCguav8GaAK+BzFSTZc+acLg19wMhilgw0H3UUUFXGsGTlGJKhKq4AiiSQDrlRxheJmWFpC591Ai/XwknoP1pSHE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:subject:date:user-agent:mime-version:content-type:message-id:sender; b=KxQYQh7GkKhHJZnirFwVEXpy++zpJOkXmByr8p88EQo3hFVbdHKFGFABct32BWlhX6ZyMs/TsBUznja8pYaJ3IjXMhX5VnXJu+Uztpwka3uN1Jl6lTOO41DIjE71eyR5mOXwouSFkHlYsm+ADI26jKPn8WME7U2ME5tcjgouHDs= Received: by 10.82.183.19 with SMTP id g19mr3156353buf.1196332265975; Thu, 29 Nov 2007 02:31:05 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id k9sm2961895nfh.2007.11.29.02.31.04 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Nov 2007 02:31:05 -0800 (PST) From: Julien Laganier To: mext@ietf.org, mip6@ietf.org, monami6@ietf.org, nemo@ietf.org Date: Thu, 29 Nov 2007 11:31:31 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_EUpTHRdRBqpA5kW" Message-Id: <200711291131.32208.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Subject: [MEXT] Fwd: 70th IETF - Agenda Changes 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 --Boundary-00=_EUpTHRdRBqpA5kW Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline FYI. --julien --Boundary-00=_EUpTHRdRBqpA5kW Content-Type: message/rfc822; name="forwarded message" Content-Transfer-Encoding: 7bit Content-Description: IETF Agenda : 70th IETF - Agenda Changes Content-Disposition: inline Return-Path: Received: from mwinf8209.laposte.net (mwinf8209.laposte.net) by mwinb8204 (SMTP Server) with LMTP; Thu, 29 Nov 2007 00:04:25 +0100 X-Sieve: Server Sieve 2.2 Received: from meplus.info (localhost [127.0.0.1]) by mwinf8209.laposte.net (SMTP Server) with ESMTP id 01F781C0008E for ; Thu, 29 Nov 2007 00:04:25 +0100 (CET) Received: from megatron.ietf.org (odin.ietf.ORG [156.154.16.145]) by mwinf8209.laposte.net (SMTP Server) with ESMTP id B38CD1C00085; Thu, 29 Nov 2007 00:04:24 +0100 (CET) X-ME-UUID: 20071128230424735.B38CD1C00085@mwinf8209.laposte.net Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVsx-0006b4-Mc; Wed, 28 Nov 2007 18:00:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVsw-0006az-Py for ietf-announce@ietf.org; Wed, 28 Nov 2007 18:00:02 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxVsw-0004SD-Ja for ietf-announce@ietf.org; Wed, 28 Nov 2007 18:00:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 8AE6E2ACA7 for ; Wed, 28 Nov 2007 23:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IxVsw-00068s-8M for ietf-announce@ietf.org; Wed, 28 Nov 2007 18:00:02 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org Cc: From: IETF Agenda Message-Id: Date: Wed, 28 Nov 2007 18:00:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: 70th IETF - Agenda Changes X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org X-me-spamlevel: not-spam X-me-spamrating: 16.270054 X-UID: 12692 X-Length: 3006 The following changes have been made since. The web version of the agenda is up to date, the printed version won't have these updates. +++ CANCELLED: "MIP6" on Tuesday, December 4, at 0900-1130 & Friday, December 7, at 0900-1130 SCHEDULED: "MEXT" on Tuesday, December 4, at 0900-1130 & Friday, December 7, at 0900-1130 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --Boundary-00=_EUpTHRdRBqpA5kW 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 --Boundary-00=_EUpTHRdRBqpA5kW-- From mext-bounces@ietf.org Thu Nov 29 06:55: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 1Ixhzg-0000oz-O6; Thu, 29 Nov 2007 06:55:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixhzf-0000hg-CY for mext@ietf.org; Thu, 29 Nov 2007 06:55:47 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixhze-0004Xn-Dv for mext@ietf.org; Thu, 29 Nov 2007 06:55:47 -0500 Received: from [163.117.139.227] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.227])by smtp02.uc3m.es (Postfix) with ESMTP id 7A7F6280B3D;Thu, 29 Nov 2007 12:55:42 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9F74E08A-F873-4E31-8AD3-4BF82A670DF7@bagnulo.net> Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Date: Thu, 29 Nov 2007 12:55:41 +0100 To: mext@ietf.org X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-14.4560 TC:1F TRN:80 TV:5.0.1023(15574.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -1.9 (-) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Julien Laganier Subject: [MEXT] New items for the mext charter discussion 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, After the call for new work to be considered for mext, we have received a set of items to be considered, that we need to discuss. MEXT is likely to recharter and add new items to the charter, but our energy is limited so we need to prioritize and decide what items are the most relevant to be included in the charter, since it seems hard to have energy to deal with all of them So we would like to ask the WG to comment on the proposed items (or other items) and explain if they think that we should be investing effort on them. In order to evaluate these items, we should understand how important is to work on these items to foster the adoption and the deployment of MIPv6 and NEMO protocols. So at this point, the discussion is two-folded: on one hand we would like to foster high level discussion on what is needed to foster mobility protocols deployment and in particular to relate this discussion with the items that have been proposed so far, and if needed propose new items for the charter. It should be noted that at this point silence does not means acceptance of the proposed items and that a strong case for adopting new work is needed, since we need to focus our energy in critical items needed for protocol deployment. ------------------------------------------------------------------------ ------- New items proposed so far: - Binding Revocation Mechanism for IPv6 Mobility Define a generic binding revocation mechanism for Mobile IPv6 and its extensions (e.g. NEMO, Monami6, NETLMM). The mechanism can be used by any mobility entity that provides Mobile IP services to a MN (e.g. a MIPv6 HA, a NETLMM LMA) to inform the MN itself or another mobility entity that is involved in providing Mobile IP services to the MN (e.g. a NETLMM MAG) of the termination of either one, multiple or all bindings for a mobile node. The mechanism should also allow any mobility entity (e.g. NETLMM MAG or LMA) to signal the termination of bindings for multiple mobile nodes via use of a single revocation message. - MIPv6 home link operation in various SDOs Many SDOs are considering the use of point-to-point links between the mobile node and the home agent as a home link for Mobile IPv6 to avoid the tunneling overhead. Some of these point-to-point links do not support running neighbor discovery. Attaching to the home link and returning to the home procedures need to be analyzed for these point-to-point links, possible with the use of binding update and binding acknowledgment messages. - IP Tunneling Optimization in a Mobile Environment The widespread use of different forms of IP tunneling mechanisms in mobile environment, e.g., MIPv6, HMIPv6, PMIPv6, has a negative impact on the protocol efficiency which is translated in the data packet size, bandwidth usage and battery power consumption. Therefore, a mechanism which enables removing the extra header would benefit the mobile node and optimize the bandwidth usage. - Generic Notification Message for Mobile IPv6 A proposal for defining generic notification framework that can be used by the mobility entities for sending and receiving asynchronous notification messages was proposed and the same was adopted by the WG. - GRE requirements for IPv6 mobility A proposal has been made for the use of GRE tunneling mechanism in Mobile IPv6. The GRE tunneling support exists in Mobile IPv4 and the proposal is for extending that functional capability to Mobile IPv6. Noted uses cases include the ability to carry any type of protocol payload in a generic header, the rich GRE header semantics allowing the exposure of a service identifier, such as a key that can be used by the tunnel endpoints for differential treatment of the carried payload and additionally supported by other use cases. - 4283bis Revised RFC 4283 to extend the subtype field in the Mobile Node identifier option to include other identifiers like IEEE 802 MAC address. The only subtype currently reserved is NAI. This may not be sufficient for all scenarios. - Bootstrapping mechanisms for using RFC 4285 with Mobile IPv6 Existing bootstrapping mechanisms for Mobile IPv6 only address the use of IKEv2/IPsec for protecting Mobile IPv6 signaling messages. Bootstrapping a home address and security associations when RFC 4285 is used are not addressed. This draft describes bootstrapping mechanisms for using RFC 4285 with Mobile IPv6. - Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions Work on the solution of interface, by which IKEv2 could get the information from MIPv6 and negotiate or update right IPsec security associations for MIPv6 when MN bootstrap in foreign network or handover to new foreign network. - RFC 3775 update Revise RFC 3775 to fix minor issues and add clarifying test for issues identified since it was published. The update would be limited to minor changes and not include any major modifications to the protocol. - Additional NEMO global deployment tools _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 29 07:07: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 1IxiAv-0006DT-SO; Thu, 29 Nov 2007 07:07:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxiAu-0006CY-0L for mext@ietf.org; Thu, 29 Nov 2007 07:07:24 -0500 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxiAs-0005op-BP for mext@ietf.org; Thu, 29 Nov 2007 07:07:23 -0500 Received: from oaamta06sl.mx.bigpond.com ([124.190.106.219]) by omta01sl.mx.bigpond.com with ESMTP id <20071129120719.WGCD9168.omta01sl.mx.bigpond.com@oaamta06sl.mx.bigpond.com> for ; Thu, 29 Nov 2007 12:07:19 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta06sl.mx.bigpond.com with ESMTP id <20071129120718.LMDA16971.oaamta06sl.mx.bigpond.com@PC20005>; Thu, 29 Nov 2007 12:07:18 +0000 From: "Hesham Soliman" To: "'marcelo bagnulo braun'" , Subject: RE: [MEXT] New items for the mext charter discussion Date: Thu, 29 Nov 2007 23:07:05 +1000 Message-ID: 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.3198 In-Reply-To: <9F74E08A-F873-4E31-8AD3-4BF82A670DF7@bagnulo.net> Thread-Index: AcgyfvBd9VGA8vaqTfOJBuO3rpZypgACQWnw X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: 'Julien Laganier' 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 A few comments > - Binding Revocation Mechanism for IPv6 Mobility > > Define a generic binding revocation mechanism for Mobile IPv6 > and its extensions (e.g. NEMO, Monami6, NETLMM). The > mechanism can be used by any mobility entity that provides > Mobile IP services to a MN (e.g. a > MIPv6 HA, a NETLMM LMA) to inform the MN itself or another > mobility entity that is involved in providing Mobile IP > services to the MN (e.g. a NETLMM MAG) of the termination of > either one, multiple or all bindings for a mobile node. The > mechanism should also allow any mobility entity (e.g. NETLMM > MAG or LMA) to signal the termination of bindings for > multiple mobile nodes via use of a single revocation message. => I think this is quite simple and useful feature to have. > - IP Tunneling Optimization in a Mobile Environment > > The widespread use of different forms of IP tunneling mechanisms in > mobile environment, e.g., MIPv6, > HMIPv6, PMIPv6, has a negative impact on the protocol efficiency > which is translated in the data packet > size, bandwidth usage and battery power consumption. Therefore, a > mechanism which enables removing > the extra header would benefit the mobile node and optimize the > bandwidth usage. => I think this is an extremely useful optimisation for several aspects of MIPv6, not only HMIP and PMIP but it also reduces one of the nasty things about lack of nemo RO. I'm strongly in favour of this. The double header (sometimes triple) has been an obstacle with other SDOs as well when MIPv6 was considered. > > - Generic Notification Message for Mobile IPv6 > > A proposal for defining generic notification framework that can be > used by the mobility > entities for sending and receiving asynchronous notification > messages > was proposed and > the same was adopted by the WG. => Neutral. I don't think it's as important as the above. > > - GRE requirements for IPv6 mobility > > A proposal has been made for the use of GRE tunneling > mechanism in > Mobile IPv6. The GRE > tunneling support exists in Mobile IPv4 and the proposal is for > extending that functional > capability to Mobile IPv6. Noted uses cases include the > ability to > carry any type of > protocol payload in a generic header, the rich GRE header > semantics allowing the exposure > of a service identifier, such as a key that can be used by the > tunnel endpoints for differential > treatment of the carried payload and additionally supported by > other use cases. > => This is not important IMO and can easily have a lower priority. GRE and IPv6 in general is not a high priority issue AFAICS. > > - 4283bis > > Revised RFC 4283 to extend the subtype field in the Mobile Node > identifier option to include other identifiers like IEEE 802 MAC > address. The only subtype currently reserved is NAI. This may > not be sufficient for all scenarios. => Neutral. > > > - Bootstrapping mechanisms for using RFC 4285 with Mobile IPv6 > > Existing bootstrapping mechanisms for Mobile IPv6 only address > the use of IKEv2/IPsec for protecting Mobile IPv6 signaling > messages. Bootstrapping a home address and security associations > when RFC 4285 is used are not addressed. This draft describes > bootstrapping mechanisms for using RFC 4285 with Mobile IPv6. > > - Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions > > Work on the solution of interface, by which IKEv2 could get the > information from MIPv6 and negotiate or update right IPsec security > associations for MIPv6 when MN bootstrap in foreign network or > handover to new foreign network. => Not important IMO. We already have an IKE-based AAA solution. > > - RFC 3775 update > > Revise RFC 3775 to fix minor issues and add clarifying test for > issues identified since it was published. The update would be > limited to minor changes and not include any major modifications > to the protocol. => This is certainly important but I still think it's early. Since this is not something we'll do every year we should wait a bit more till there we receive significant changes that need to be made. Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 29 07:39:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxifR-00007K-7k; Thu, 29 Nov 2007 07:38:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxifQ-000079-Ib for mext@ietf.org; Thu, 29 Nov 2007 07:38:56 -0500 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 1IxifP-0007DQ-Uu for mext@ietf.org; Thu, 29 Nov 2007 07:38:56 -0500 Received: from [192.168.3.7] (softbank219198090087.bbtec.net [219.198.90.87]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 234EE4D965; Thu, 29 Nov 2007 21:38:54 +0900 (JST) Message-ID: <474EB2E3.7020405@sfc.wide.ad.jp> Date: Thu, 29 Nov 2007 21:38:59 +0900 From: Jean Lorchat User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Karen.Nielsen@tietoenator.com Subject: Re: [MEXT] dsmip port References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Karen, In the (not released yet) Linux implementation, we decided to use a specific port, but this is in fact customizable, so as to be tailored to needs (and waiting for the IANA assignement anyway). As for the number we use currently I do not remember it right away but it should not be very significant ;-) Regards, Jean Karen.Nielsen@tietoenator.com wrote: > Hi, > > Is there a defacto DSMIP port in usage in experimental implementations ? > > BR, Karen > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Thu Nov 29 07:50: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 1Ixiqx-0001Oy-79; Thu, 29 Nov 2007 07:50:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixiqv-0001KB-Lb for mext@ietf.org; Thu, 29 Nov 2007 07:50:49 -0500 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixiqt-00025I-NN for mext@ietf.org; Thu, 29 Nov 2007 07:50:49 -0500 Received: from oaamta04sl.mx.bigpond.com ([124.190.106.219]) by omta05sl.mx.bigpond.com with ESMTP id <20071129125044.NYCU14987.omta05sl.mx.bigpond.com@oaamta04sl.mx.bigpond.com> for ; Thu, 29 Nov 2007 12:50:44 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta04sl.mx.bigpond.com with ESMTP id <20071129125044.MDCQ21432.oaamta04sl.mx.bigpond.com@PC20005> for ; Thu, 29 Nov 2007 12:50:44 +0000 From: "Hesham Soliman" To: Date: Thu, 29 Nov 2007 23:50:31 +1000 Message-ID: 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.3198 Thread-Index: Acgyjs6GkWx3wePvRn6yz8kf9tSz9w== X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [MEXT] DSMIPv6 implementations ? 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, I'd be very interested (and I'm sure others on the list too) to know how many people here have implemented the current draft or are implementing it. Feel free to respond in private or on the list, it's only for information. Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 29 07:56: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 1IxiwQ-0001cy-T0; Thu, 29 Nov 2007 07:56:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxiwQ-0001ce-2D for mext@ietf.org; Thu, 29 Nov 2007 07:56:30 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxiwP-0003ms-4x for mext@ietf.org; Thu, 29 Nov 2007 07:56:30 -0500 Received: from [163.117.81.149] (wifi-81-149.uc3m.es [163.117.81.149])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp02.uc3m.es (Postfix) with ESMTP id 465DC280C58; Thu, 29 Nov 2007 13:56:28 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3A468644-B1D4-4096-AFC7-89192CBA410D@it.uc3m.es> Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Date: Thu, 29 Nov 2007 13:56:27 +0100 To: mext@ietf.org X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-10.4096 TC:1F TRN:41 TV:5.0.1023(15574.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -1.9 (-) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Julien Laganier Subject: [MEXT] MEXT Agenda So far 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, this is the agenda so far It is likely that a few changes will happen, but it seems pretty stable right now. Regards, marcelo --------------------------------------------------------------------- Mobility EXTensions for IPv6 (MEXT) Agenda at IETF-70 ==================================== Chairs: Julien Laganier Marcelo Bagnulo Braun Session: TUESDAY, December 4, 2007 0900-1130 Morning Session I Agenda: - Agenda, Bluesheets, Note-takers and Jabber scribes Chairs - 5 Min - Status of MEXT deliverables Chairs - 10 min o MEXT Deliverables - Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) Hesham Soliman - 15 min draft-ietf-mip6-nemo-v4traversal-06.txt - Guidelines for firewall administrators regarding MIPv6 traffic Suresh Krishnan - 10 min draft-krishnan-mip6-firewall-admin-02 - Guidelines for firewall vendors regarding MIPv6 traffic Suresh Krishnan - 10 min draft-krishnan-mip6-firewall-vendor-02 - Verification of Care-of Addresses in Multiple Bindings Registration Benjamin Lim - 10 min draft-lim-mext-multiple-coa-verify-00 - Multiple Care-of Addresses Registration Ryuji Wakikawa - 20 min draft-ietf-monami6-multiplecoa-04 - Consumer Electronics Requirements for Network Mobility Route Optimization Chan-Wah Ng - 10 min draft-ng-nemo-ce-req-01 - Analysis of commonalities in nemo RO requirements for aviation, car to car and consumer electronics cases 20 min o Additional Work Items to be considered for MEXT - Binding Revocation for IPv6 Mobility Ahmad Muhanna - 10 min draft-muhanna-mip6-binding-revocation-02.txt - Additional NEMO global deployment tools Thierry Ernst - 10 min no draft - RFC 3775 update Vijay Devarapalli - 10 min ------------------------------------------------------------------------ Session: FRIDAY, December 7, 2007 0900-1130 Morning Session I - RFC 4283 bis Chairs - 5 min Proposed by Vijay Devarapalli - draft-devarapalli-mip6-authprotocol-bootstrap Chairs - 5 min Vijay Devarapalli - MIPv6 home link operation in various SDOs Vijay Devarapalli - 15 min no draft yet - IP Tunneling Optimization in a Mobile Environment Wassim Haddad - 5 min draft-haddad-mip6-tunneling-optimization-01 - Generic Notification Message for Mobile IPv6 Sri Gundavelli - 10 min draft-ietf-mip6-generic-notification-message-00.txt - GRE requirements for IPv6 mobility Sri Gundavelli - 10 min no draft - Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions Hi Deng - 5 min draft-qi-mip6-ikev2-interfacing-01 - Discussion on new work for MEXT Chairs - 20 min o Other Discussions (depending on the time left from previous discussions) The goal is to obtain feedback from MEXT community - EAP-Based Keying for IP Mobility Protocols Gerardo Giarretta - 10 min draft-vidya-eap-usrk-ip-mobility-01 - Limitations exist in IP mobility support applications (NEMO + PMIP) John Zhao - 10 min draft-zhao-nemo-limitations-ps - Problem Statement: Diameter Prefix Delegation Application B. Sarikaya - 10 min draft-sarikaya-dime-prefix-delegation-ps-00.txt _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 29 09:48:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixkgv-0003mi-Jj; Thu, 29 Nov 2007 09:48:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixkgu-0003iJ-By for mext@ietf.org; Thu, 29 Nov 2007 09:48:36 -0500 Received: from an-out-0708.google.com ([209.85.132.241]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixkgu-0007kh-0R for mext@ietf.org; Thu, 29 Nov 2007 09:48:36 -0500 Received: by an-out-0708.google.com with SMTP id d11so433718and for ; Thu, 29 Nov 2007 06:48:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=tVhJmAn4Zu/5g8pglhCh/BDCJ0GARMcVrJZ+NnDz8mY=; b=XsOHqyI/HHxzjlobTnnmGzhd1V1+AIDO9cmK6Xje6HsbGOktOEkdS/YGwyKaaA5EsqvNGZcNG9DRM9bDOveyIiitpSYVx0Qsf9e1YvhWH5sUqXXnHN1H/55dNsc46DlJ6LQLNQM76GWYgLoJ0aco4Cu64xKDZhUz4oNj/noApYo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=JCFtvPTHyNZnP39VOHkGaV8y4QxbBnkWQNq7B3rPqMxl50INkPltWs9lR/jDwuozHfdBdEzjuY+sOyKypfqutRMxw2lG/TgjvZIU3LzDpAuLCBZnv+CwDGeiiKl1GZkeeM8EgM2FPknnvB3Bj8eK6YyiOwl5MI/8otL6aepqmmQ= Received: by 10.100.206.11 with SMTP id d11mr11718060ang.1196347715674; Thu, 29 Nov 2007 06:48:35 -0800 (PST) Received: from ?203.178.143.240? ( [203.178.143.240]) by mx.google.com with ESMTPS id 36sm165922aga.2007.11.29.06.48.31 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Nov 2007 06:48:34 -0800 (PST) From: RYUJI WAKIKAWA To: Hesham Soliman In-Reply-To: Subject: Re: [MEXT] DSMIPv6 implementations ? References: Message-Id: <2BE7C4DA-6479-4CBF-8E1D-6D6E70579DE3@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Thu, 29 Nov 2007 23:48:28 +0900 X-Mailer: Apple Mail (2.915) 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 List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hesham Koshiro implemented DSMIP on NetBSD as an extension of SHISA package. I think the spec he implemented is a bit older one. His implementation still uses mapped address. Please ask him further information. regards ryuji On 2007/11/29, at 22:50, Hesham Soliman wrote: > Folks, > > I'd be very interested (and I'm sure others on the list too) to know > how > many people here have implemented the current draft or are > implementing it. > Feel free to respond in private or on the list, it's only for > information. > > Hesham > > > > _______________________________________________ > 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 Thu Nov 29 11:10: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 1Ixly8-000591-8O; Thu, 29 Nov 2007 11:10:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxltU-0000lh-Rb for mext@ietf.org; Thu, 29 Nov 2007 11:05:40 -0500 Received: from mxs2.siemens.at ([194.138.12.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxltS-0006oq-Fy for mext@ietf.org; Thu, 29 Nov 2007 11:05:40 -0500 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs2.siemens.at with ESMTP id lATG4S2X017438; Thu, 29 Nov 2007 17:04:28 +0100 Received: from nets138a.ww300.siemens.net ([158.226.129.97]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id lATG4OjT009567; Thu, 29 Nov 2007 17:04:24 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Nov 2007 17:03:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [MEXT] v4 HoA allocation using IKEv2 in DSMIP6 Date: Thu, 29 Nov 2007 17:03:25 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD680304849D@zagh223a.ww300.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] v4 HoA allocation using IKEv2 in DSMIP6 Thread-Index: AcgyoV/OpjZvi1kWSBKlzcbtUl8YPw== From: "Premec, Domagoj" To: "Hesham Soliman" X-OriginalArrivalTime: 29 Nov 2007 16:03:27.0541 (UTC) FILETIME=[60CFBE50:01C832A1] 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::071129170428-519B8BB0-72BCFE6E/0-0/0-15 X-purgate-size: 2219/999999 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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="===============0442946044==" Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0442946044== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C832A1.609E14DA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C832A1.609E14DA Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi Hesham, =20 I was wondering if DSMIP6 host can request v4 HoA in IKEv2 CFG payload = and then use it as v4 HoA in the BU? It seems that this is possible as = it is not precluded by the spec, but on the other hand section 2.5 = "Dynamic v4 HoA allocation" mentiones only BU with 0.0.0.0 as a means to = dynamically get IPv4 HoA. Maybe a sentence could be added to the draft = to clarify this?=20 =20 thanks domagoj =20 ------_=_NextPart_001_01C832A1.609E14DA Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Hi=20 Hesham,
 
I was=20 wondering if DSMIP6 host can request v4 HoA in IKEv2 CFG = payload and=20 then use it as v4 HoA in the BU? It seems that this is = possible as it=20 is not precluded by the spec, but on the other hand section 2.5 "Dynamic = v4 HoA=20 allocation" mentiones only BU with 0.0.0.0 as a means to = dynamically get=20 IPv4 HoA. Maybe a sentence could be added to the draft to clarify this?=20
 
thanks
domagoj
 
------_=_NextPart_001_01C832A1.609E14DA-- --===============0442946044== 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 --===============0442946044==-- From mext-bounces@ietf.org Thu Nov 29 11:50: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 1Ixmah-00052a-JF; Thu, 29 Nov 2007 11:50:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixmag-00052R-Lx for mext@ietf.org; Thu, 29 Nov 2007 11:50:18 -0500 Received: from g5t0007.atlanta.hp.com ([15.192.0.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixmag-00063D-9j for mext@ietf.org; Thu, 29 Nov 2007 11:50:18 -0500 Received: from g5t0007.atlanta.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id A2936143E0; Thu, 29 Nov 2007 16:50:03 +0000 (UTC) Received: from smtp1.fc.hp.com (smtp.cnd.hp.com [15.15.136.127]) by g5t0007.atlanta.hp.com (Postfix) with ESMTP id 36C671436E; Thu, 29 Nov 2007 16:49:44 +0000 (UTC) Received: from [16.116.96.52] (wrx.zko.hp.com [16.116.96.52]) by smtp1.fc.hp.com (Postfix) with ESMTP id A96141DD736; Thu, 29 Nov 2007 16:49:38 +0000 (UTC) Message-ID: <474EED9D.4050308@hp.com> Date: Thu, 29 Nov 2007 11:49:33 -0500 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [MEXT] MEXT charter References: <47420EC7.80606@piuha.net> <022701c82d42$a85d5700$1220fea9@amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: mext@ietf.org, Julien Laganier 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 Sri and George, >> According to this draft the sender of the notification message can resend >> the notification if it sets the A flag and does not receive an ack. >> This is >> correctly defined as a MAY, but I think some language should also be >> added >> WRT the fact that lack of acknowledgement could also mean that the >> receiver >> does not support generic notifications as all; or is some other behavior >> expected in such a case? > > Thanks for the comment. > > I agree, we need to provide the hint to the sender that the > receiver may not support this option and the suggested action. If the target node doesn't support the Generic Notification message, it should have generated a Binding Error, from Section 4: If the packet is dropped due to the above tests, the receiving node MUST follow the processing rules as Section 9.2 of [2]. For example, it MUST send a Binding Error message with the Status field set to 2 (unrecognized MH Type value) if it does not support the message type. How about we add this to the retransmission section, just to make that clear: "If the sender of the Generic Notification Request message received a Binding Error with the Status field set to 2 (unrecognized MH Type value) in response to the original transmission, it MUST NOT retransmit the message since the receiver does not know how to process it." -Brian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 29 12:57:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixndu-0006gh-9N; Thu, 29 Nov 2007 12:57:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixndt-0006gY-QT for mext@ietf.org; Thu, 29 Nov 2007 12:57:41 -0500 Received: from rv-out-0910.google.com ([209.85.198.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixndr-0000kW-Ot for mext@ietf.org; Thu, 29 Nov 2007 12:57:41 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1520513rvb for ; Thu, 29 Nov 2007 09:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; 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; bh=ahj8MDlYF/Bhom8Hxqb/+nU9DikO7+NvGeQEvC/03iw=; b=MDitGZ+xJHCZ1I3R/mKowa1Wza6nYZ9Y/H0mFtQiGH9pQ9QKkCq52luJAyDThn5sNISdnscF0ojcwo4YCNenZFyCCm8GW+0WZb1e7ZqfRejucBM80m2F9mVlsPqwxFeT1AH3ABrtMu9nM7M2AO7BDEkZuBpq8jSUpg9h2OXtXTA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iOAJ1kuTGxcWaDA3lGVmnrxPAe1RJatvgvD0XNHmTlGcxDFnv7KQ0T7fSG1i57K0dw4WnapMxPE4PtKLCi8OHMoptUQqPvgkwErPA58II2+iEFCf/M8wat+QNJqH1TUzZU6kjXoO8OY2iLGQD4hwlwT7hsdXQPKFovPNvE3McrM= Received: by 10.140.139.3 with SMTP id m3mr3435802rvd.1196359059076; Thu, 29 Nov 2007 09:57:39 -0800 (PST) Received: by 10.140.135.15 with HTTP; Thu, 29 Nov 2007 09:57:39 -0800 (PST) Message-ID: Date: Thu, 29 Nov 2007 17:57:39 +0000 From: "George Tsirtsis" To: "Premec, Domagoj" Subject: Re: [MEXT] v4 HoA allocation using IKEv2 in DSMIP6 In-Reply-To: <3C31CDD06342EA4A8137716247B1CD680304849D@zagh223a.ww300.siemens.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3C31CDD06342EA4A8137716247B1CD680304849D@zagh223a.ww300.siemens.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: mext@ietf.org, Hesham Soliman 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 Domagoj, I think if the IPv4 address in the BU is not 0.0.0.0, then from the perspective of DSMIPv6, it is not dynamically allocated. I think that would be the case if the IPv4 address was allocated outside DSMIPv6, with whatever way, including via IKEv2. Regards George On Nov 29, 2007 4:03 PM, Premec, Domagoj wrote: > > > Hi Hesham, > > I was wondering if DSMIP6 host can request v4 HoA in IKEv2 CFG payload and > then use it as v4 HoA in the BU? It seems that this is possible as it is not > precluded by the spec, but on the other hand section 2.5 "Dynamic v4 HoA > allocation" mentiones only BU with 0.0.0.0 as a means to dynamically get > IPv4 HoA. Maybe a sentence could be added to the draft to clarify this? > > thanks > domagoj > > _______________________________________________ > 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 Thu Nov 29 13:34: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 1IxoDY-0007lC-2g; Thu, 29 Nov 2007 13:34:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxoDW-0007kp-Fj for mext@ietf.org; Thu, 29 Nov 2007 13:34:30 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxoDW-00070e-44 for mext@ietf.org; Thu, 29 Nov 2007 13:34:30 -0500 Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Nov 2007 10:34:29 -0800 Message-ID: <474F0632.2090306@azairenet.com> Date: Thu, 29 Nov 2007 10:34:26 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Premec, Domagoj" Subject: Re: [MEXT] v4 HoA allocation using IKEv2 in DSMIP6 References: <3C31CDD06342EA4A8137716247B1CD680304849D@zagh223a.ww300.siemens.net> In-Reply-To: <3C31CDD06342EA4A8137716247B1CD680304849D@zagh223a.ww300.siemens.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Nov 2007 18:34:29.0422 (UTC) FILETIME=[7A1D0CE0:01C832B6] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: mext@ietf.org, Hesham Soliman 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 Premec, Domagoj wrote: > Hi Hesham, > > I was wondering if DSMIP6 host can request v4 HoA in IKEv2 CFG > payload and then use it as v4 HoA in the BU? It seems that this is > possible as it is not precluded by the spec, but on the other hand > section 2.5 "Dynamic v4 HoA allocation" mentiones only BU with 0.0.0.0 > as a means to dynamically get IPv4 HoA. Maybe a sentence could be added > to the draft to clarify this? Why would you want the IPv4 HoA in the IKEv2 exchange? If the IKEv2 configuration payloads are used, the HA and the MN might not know that is an IPv4 HoA to be associated with the DS-MIPv6 binding cache entry. Vijay > > thanks > domagoj > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Maltchevvehl@nxtgeneration.net Thu Nov 29 14:05:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixohc-0005Nd-80 for nemo-archive@lists.ietf.org; Thu, 29 Nov 2007 14:05:36 -0500 Received: from p5b0fb9e1.dip0.t-ipconnect.de ([91.15.185.225] helo=p5B0FC362.dip0.t-ipconnect.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixohb-0004Es-GS for nemo-archive@lists.ietf.org; Thu, 29 Nov 2007 14:05:36 -0500 Received: from name-7c3db6b2cc ([197.198.40.69] helo=name-7c3db6b2cc) by p5B0FC362.dip0.t-ipconnect.de ( sendmail 8.13.3/8.13.1) with esmtpa id 1jjFUM-000EEB-DR for nemo-archive@lists.ietf.org; Thu, 29 Nov 2007 20:12:36 +0100 Message-ID: <000e01c832bb$be1c0680$62c30f5b@name7c3db6b2cc> From: "JE Maltchev" To: Subject: naisseh1 Date: Thu, 29 Nov 2007 20:12:10 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C832C4.1FE06E80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.0 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a ------=_NextPart_000_0009_01C832C4.1FE06E80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable no more limp dick, you'll be rock solid on virility pills = http://www.lasfrt.com/ ------=_NextPart_000_0009_01C832C4.1FE06E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
no more limp dick, you'll be rock solid on = virility=20 pills http://www.lasfrt.com/
------=_NextPart_000_0009_01C832C4.1FE06E80-- From mext-bounces@ietf.org Thu Nov 29 15:39: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 1Ixq9z-0000kV-95; Thu, 29 Nov 2007 15:38:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixq9x-0000ho-Cc for mext@ietf.org; Thu, 29 Nov 2007 15:38:57 -0500 Received: from rv-out-0910.google.com ([209.85.198.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixq9w-0008Ou-Vi for mext@ietf.org; Thu, 29 Nov 2007 15:38:57 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1573102rvb for ; Thu, 29 Nov 2007 12:38:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; 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; bh=l2YffV8J3WUHvi01/1yUpW15ilRYUQOxil02y8u8vfc=; b=BGLfsb0jXpBPe31dIG+aZhk4mrdGGQ8S6bh/xA1h6J0KllI7zwyr3PdCQJSz93EkiNfUGFBkro6vxr2r3H2UtvI/MlKyJFzOCqCc4hPmn+QI38FV+z4zw8F58t7P8sj6G78se8A3kARAVftfxBtMzny0D4FjwlK4DWAf94VgeQ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NGwfkWbawwxYp9EFrkUTQeBi4+HL+dRUrtERyJM/77aCWpw6l30yJgFI91e+1PPiDZPsvwA3bwvoSlETewXEZcicyCtT1t0tlhFHusgyoh2xPsLY65fhgzlSMdypmVktnWDqDafl1y5tVxAFDPdcWAy6Saf0QDHYHuvipehwbEY= Received: by 10.141.87.13 with SMTP id p13mr3556845rvl.1196368734779; Thu, 29 Nov 2007 12:38:54 -0800 (PST) Received: by 10.140.135.15 with HTTP; Thu, 29 Nov 2007 12:38:54 -0800 (PST) Message-ID: Date: Thu, 29 Nov 2007 20:38:54 +0000 From: "George Tsirtsis" To: "Vijay Devarapalli" Subject: Re: [MEXT] v4 HoA allocation using IKEv2 in DSMIP6 In-Reply-To: <474F0632.2090306@azairenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3C31CDD06342EA4A8137716247B1CD680304849D@zagh223a.ww300.siemens.net> <474F0632.2090306@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Hesham Soliman , 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 Vijay why do you say that? If this works for IPv6 address why does it not work for IPv4 address? In either case the MN will then have to include these addresses in the BU, so the HA will know. George On Nov 29, 2007 6:34 PM, Vijay Devarapalli wrote: > > Premec, Domagoj wrote: > > Hi Hesham, > > > > I was wondering if DSMIP6 host can request v4 HoA in IKEv2 CFG > > payload and then use it as v4 HoA in the BU? It seems that this is > > possible as it is not precluded by the spec, but on the other hand > > section 2.5 "Dynamic v4 HoA allocation" mentiones only BU with 0.0.0.0 > > as a means to dynamically get IPv4 HoA. Maybe a sentence could be added > > to the draft to clarify this? > > Why would you want the IPv4 HoA in the IKEv2 exchange? If the IKEv2 > configuration payloads are used, the HA and the MN might not know > that is an IPv4 HoA to be associated with the DS-MIPv6 binding cache > entry. > > Vijay > > > > > > thanks > > domagoj > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 29 15:45: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 1IxqG2-000596-3N; Thu, 29 Nov 2007 15:45:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxqG0-00058p-3d for mext@ietf.org; Thu, 29 Nov 2007 15:45:12 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxqFz-0007Bk-Mo for mext@ietf.org; Thu, 29 Nov 2007 15:45:12 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lATKhdEY018097; Thu, 29 Nov 2007 14:44:37 -0600 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 22:43:28 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 14:43:26 -0600 Received: from 172.19.244.165 ([172.19.244.165]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 29 Nov 2007 20:43:26 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 29 Nov 2007 14:43:39 -0600 Subject: Re: [MEXT] v4 HoA allocation using IKEv2 in DSMIP6 From: Basavaraj Patil To: ext George Tsirtsis , Vijay Devarapalli Message-ID: Thread-Topic: [MEXT] v4 HoA allocation using IKEv2 in DSMIP6 Thread-Index: AcgyyIU4w40nVJ67Edyj4wARJNUNiA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Nov 2007 20:43:26.0593 (UTC) FILETIME=[7DD3A710:01C832C8] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: mext@ietf.org, Hesham Soliman 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 It may be the case that a device may use DS-MIP6 but only require an IPv4 address. And hence it would make sense to get the IPv4 address for the MN via IKEv2 bootstrapping mechanism. -Raj On 11/29/07 2:38 PM, "ext George Tsirtsis" wrote: > Vijay why do you say that? If this works for IPv6 address why does it > not work for IPv4 address? In either case the MN will then have to > include these addresses in the BU, so the HA will know. > > George > > On Nov 29, 2007 6:34 PM, Vijay Devarapalli > wrote: >> >> Premec, Domagoj wrote: >>> Hi Hesham, >>> >>> I was wondering if DSMIP6 host can request v4 HoA in IKEv2 CFG >>> payload and then use it as v4 HoA in the BU? It seems that this is >>> possible as it is not precluded by the spec, but on the other hand >>> section 2.5 "Dynamic v4 HoA allocation" mentiones only BU with 0.0.0.0 >>> as a means to dynamically get IPv4 HoA. Maybe a sentence could be added >>> to the draft to clarify this? >> >> Why would you want the IPv4 HoA in the IKEv2 exchange? If the IKEv2 >> configuration payloads are used, the HA and the MN might not know >> that is an IPv4 HoA to be associated with the DS-MIPv6 binding cache >> entry. >> >> Vijay >> >> >>> >>> thanks >>> domagoj >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > 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 Thu Nov 29 16:18: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 1Ixqm3-0006c6-1R; Thu, 29 Nov 2007 16:18:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixqm1-0006bf-V2 for mext@ietf.org; Thu, 29 Nov 2007 16:18:17 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixqm0-00079J-B6 for mext@ietf.org; Thu, 29 Nov 2007 16:18:17 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lATLGPbh013104; Thu, 29 Nov 2007 15:18:17 -0600 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 23:17:26 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 15:17:22 -0600 Received: from 172.19.244.165 ([172.19.244.165]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 29 Nov 2007 21:17:22 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 29 Nov 2007 15:17:35 -0600 Subject: Re: [MEXT] New items for the mext charter discussion From: Basavaraj Patil To: ext marcelo bagnulo braun , Message-ID: Thread-Topic: [MEXT] New items for the mext charter discussion Thread-Index: AcgyzULFgUWlJJ7AEdyj4wARJNUNiA== In-Reply-To: <9F74E08A-F873-4E31-8AD3-4BF82A670DF7@bagnulo.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Nov 2007 21:17:23.0160 (UTC) FILETIME=[3BB71D80:01C832CD] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Julien Laganier 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 Marcelo, On 11/29/07 5:55 AM, "ext marcelo bagnulo braun" wrote: > > - Generic Notification Message for Mobile IPv6 > > A proposal for defining generic notification framework that can be > used by the mobility > entities for sending and receiving asynchronous notification messages > was proposed and > the same was adopted by the WG. > This was already adopted by the MIP6 WG via consensus call and published as a MIP6 WG document. Why revisit this discussion again? I thought the MEXT charter would include all the WG I-Ds from MIP6, NEMO and MONAMI6 to begin with. -Raj _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 29 16:44:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrBK-0005vS-Vc; Thu, 29 Nov 2007 16:44:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrBI-0005vE-T0 for mext@ietf.org; Thu, 29 Nov 2007 16:44:24 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxrBH-00066T-9k for mext@ietf.org; Thu, 29 Nov 2007 16:44:24 -0500 Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Nov 2007 13:44:22 -0800 Message-ID: <474F32B3.2080304@azairenet.com> Date: Thu, 29 Nov 2007 13:44:19 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: George Tsirtsis Subject: Re: [MEXT] v4 HoA allocation using IKEv2 in DSMIP6 References: <3C31CDD06342EA4A8137716247B1CD680304849D@zagh223a.ww300.siemens.net> <474F0632.2090306@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Nov 2007 21:44:22.0615 (UTC) FILETIME=[00FC5670:01C832D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Hesham Soliman , 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 George Tsirtsis wrote: > Vijay why do you say that? If this works for IPv6 address why does it > not work for IPv4 address? RFC 4877 and 5026 specify how the IPv6 address obtained in the IKEv2 configuration payloads is used as the the home address. In DS-MIPv6, the IPv4 home address is "associated" with the binding cache entry that is based on the IPv6 home address (or the MN identifier), when the IPv4 home address is allocated as part of the BU/BAck exchange. > In either case the MN will then have to > include these addresses in the BU, so the HA will know. If the MN includes the IPv4 home address in the BU, then you are right it would work. My original question still stands, why would you do all this instead of getting the IPv4 home address as part of the BU/BAck exchange. Vijay > > George > > On Nov 29, 2007 6:34 PM, Vijay Devarapalli > wrote: >> Premec, Domagoj wrote: >>> Hi Hesham, >>> >>> I was wondering if DSMIP6 host can request v4 HoA in IKEv2 CFG >>> payload and then use it as v4 HoA in the BU? It seems that this is >>> possible as it is not precluded by the spec, but on the other hand >>> section 2.5 "Dynamic v4 HoA allocation" mentiones only BU with 0.0.0.0 >>> as a means to dynamically get IPv4 HoA. Maybe a sentence could be added >>> to the draft to clarify this? >> Why would you want the IPv4 HoA in the IKEv2 exchange? If the IKEv2 >> configuration payloads are used, the HA and the MN might not know >> that is an IPv4 HoA to be associated with the DS-MIPv6 binding cache >> entry. >> >> Vijay >> >> >>> thanks >>> domagoj >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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 >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 29 16:46: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 1IxrDC-00077J-H0; Thu, 29 Nov 2007 16:46:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrDB-00076n-1j for mext@ietf.org; Thu, 29 Nov 2007 16:46:21 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxrDA-0004if-IP for mext@ietf.org; Thu, 29 Nov 2007 16:46:20 -0500 Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Nov 2007 13:46:19 -0800 Message-ID: <474F3327.7090104@azairenet.com> Date: Thu, 29 Nov 2007 13:46:15 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [MEXT] v4 HoA allocation using IKEv2 in DSMIP6 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Nov 2007 21:46:19.0426 (UTC) FILETIME=[469C4820:01C832D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: mext@ietf.org, Hesham Soliman 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 Raj, An IPv6 home address is always assigned to the mobile node. The IPsec security associations between the MN and the HA are based on the IPv6 home address. And the IPv6 home address is *the address* used for DS-MIPv6 signaling. Getting only an IPv4 home address without the IPv6 home address is not specified. Vijay Basavaraj Patil wrote: > It may be the case that a device may use DS-MIP6 but only require an IPv4 > address. And hence it would make sense to get the IPv4 address for the MN > via IKEv2 bootstrapping mechanism. > > -Raj > > > On 11/29/07 2:38 PM, "ext George Tsirtsis" wrote: > >> Vijay why do you say that? If this works for IPv6 address why does it >> not work for IPv4 address? In either case the MN will then have to >> include these addresses in the BU, so the HA will know. >> >> George >> >> On Nov 29, 2007 6:34 PM, Vijay Devarapalli >> wrote: >>> Premec, Domagoj wrote: >>>> Hi Hesham, >>>> >>>> I was wondering if DSMIP6 host can request v4 HoA in IKEv2 CFG >>>> payload and then use it as v4 HoA in the BU? It seems that this is >>>> possible as it is not precluded by the spec, but on the other hand >>>> section 2.5 "Dynamic v4 HoA allocation" mentiones only BU with 0.0.0.0 >>>> as a means to dynamically get IPv4 HoA. Maybe a sentence could be added >>>> to the draft to clarify this? >>> Why would you want the IPv4 HoA in the IKEv2 exchange? If the IKEv2 >>> configuration payloads are used, the HA and the MN might not know >>> that is an IPv4 HoA to be associated with the DS-MIPv6 binding cache >>> entry. >>> >>> Vijay >>> >>> >>>> thanks >>>> domagoj >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> 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 >>> >> _______________________________________________ >> 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 Thu Nov 29 16:53: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 1IxrJm-0000tE-5Y; Thu, 29 Nov 2007 16:53:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrJk-0000qu-Bb for mext@ietf.org; Thu, 29 Nov 2007 16:53:08 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxrJj-0007YP-St for mext@ietf.org; Thu, 29 Nov 2007 16:53:08 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lATLqfmt010605; Thu, 29 Nov 2007 15:52:55 -0600 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 23:52:05 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 15:52:03 -0600 Received: from 172.19.244.165 ([172.19.244.165]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 29 Nov 2007 21:52:02 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 29 Nov 2007 15:52:14 -0600 Subject: Re: [MEXT] v4 HoA allocation using IKEv2 in DSMIP6 From: Basavaraj Patil To: Vijay Devarapalli Message-ID: Thread-Topic: [MEXT] v4 HoA allocation using IKEv2 in DSMIP6 Thread-Index: Acgy0hnzWMFT+p7FEdyj4wARJNUNiA== In-Reply-To: <474F3327.7090104@azairenet.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Nov 2007 21:52:03.0365 (UTC) FILETIME=[139D3550:01C832D2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: mext@ietf.org, Hesham Soliman 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 Okay... True. I guess you need an IPv6 address anyway even if the MN does not use it. Getting the IPv4 address in the BAck should be sufficient. Don't see a real reason to get it at the time of IKEv2 negotiation. -Raj On 11/29/07 3:46 PM, "ext Vijay Devarapalli" wrote: > Raj, > > An IPv6 home address is always assigned to the mobile node. The > IPsec security associations between the MN and the HA are based > on the IPv6 home address. And the IPv6 home address is *the > address* used for DS-MIPv6 signaling. Getting only an IPv4 home > address without the IPv6 home address is not specified. > > Vijay > > Basavaraj Patil wrote: >> It may be the case that a device may use DS-MIP6 but only require an IPv4 >> address. And hence it would make sense to get the IPv4 address for the MN >> via IKEv2 bootstrapping mechanism. >> >> -Raj >> >> >> On 11/29/07 2:38 PM, "ext George Tsirtsis" wrote: >> >>> Vijay why do you say that? If this works for IPv6 address why does it >>> not work for IPv4 address? In either case the MN will then have to >>> include these addresses in the BU, so the HA will know. >>> >>> George >>> >>> On Nov 29, 2007 6:34 PM, Vijay Devarapalli >>> wrote: >>>> Premec, Domagoj wrote: >>>>> Hi Hesham, >>>>> >>>>> I was wondering if DSMIP6 host can request v4 HoA in IKEv2 CFG >>>>> payload and then use it as v4 HoA in the BU? It seems that this is >>>>> possible as it is not precluded by the spec, but on the other hand >>>>> section 2.5 "Dynamic v4 HoA allocation" mentiones only BU with 0.0.0.0 >>>>> as a means to dynamically get IPv4 HoA. Maybe a sentence could be added >>>>> to the draft to clarify this? >>>> Why would you want the IPv4 HoA in the IKEv2 exchange? If the IKEv2 >>>> configuration payloads are used, the HA and the MN might not know >>>> that is an IPv4 HoA to be associated with the DS-MIPv6 binding cache >>>> entry. >>>> >>>> Vijay >>>> >>>> >>>>> thanks >>>>> domagoj >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> _______________________________________________ >>> 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 VickiealluvialDempsey@davidsuzuki.org Thu Nov 29 18:10:23 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxsWV-0008Ah-4w; Thu, 29 Nov 2007 18:10:23 -0500 Received: from 84.121.216.2.dyn.user.ono.com ([84.121.216.2] helo=usuario0bcb6ff) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxsWU-0002aK-FI; Thu, 29 Nov 2007 18:10:22 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host58530181.davidsuzuki.org (8.13.1/8.13.1) with SMTP id XpssXfzA75.164542.Ymi.YsY.9756349018307 for ; Fri, 30 Nov 2007 00:10:08 -0100 Message-ID: <2c49c01c832dd$02cd7680$6402a8c0@usuario0bcb6ff> From: "Lydia Dubois" To: Subject: Your order approved Date: Fri, 30 Nov 2007 00:10:08 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_2C498_01C832DD.02CD7680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_2C498_01C832DD.02CD7680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_2C498_01C832DD.02CD7680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_2C498_01C832DD.02CD7680-- From AlisoneclatTidwell@freedict.com Thu Nov 29 19:00:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxtIa-000557-Ju; Thu, 29 Nov 2007 19:00:04 -0500 Received: from d38-245-94.home1.cgocable.net ([72.38.245.94] helo=homecxjkohrxyw) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxtIY-0005V7-Bz; Thu, 29 Nov 2007 19:00:04 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host15692393.freedict.com (8.13.1/8.13.1) with SMTP id bjxvnu9J70.092697.Y3a.gqb.9474769070358 for ; Thu, 29 Nov 2007 18:59:43 +0500 Message-ID: <59f5f01c832e3$f29b2d00$5ef52648@homecxjkohrxyw> From: "Luz Tidwell" To: Subject: Hi Date: Thu, 29 Nov 2007 18:59:43 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_59F5B_01C832E3.F29B2D00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_59F5B_01C832E3.F29B2D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_59F5B_01C832E3.F29B2D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_59F5B_01C832E3.F29B2D00-- From JanellesportswritingOverton@xoops.org Thu Nov 29 20:38:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixupm-0003NS-4X; Thu, 29 Nov 2007 20:38:26 -0500 Received: from pool-151-198-13-101.nwrk.east.verizon.net ([151.198.13.101] helo=omarpc1) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ixupl-0002vI-Hq; Thu, 29 Nov 2007 20:38:26 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host34173900.xoops.org (8.13.1/8.13.1) with SMTP id wqAePAJW58.250196.tsy.sUU.3971631395293 for ; Thu, 29 Nov 2007 20:38:14 +0500 Message-ID: <73e9d01c832f1$b35d6a50$6401a8c0@omarpc1> From: "Tracie Akins" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_73E99_01C832F1.B35D6A50-- From mext-bounces@ietf.org Fri Nov 30 04:07:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy1pq-00050l-3U; Fri, 30 Nov 2007 04:06:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy1po-000501-Ns for mext@ietf.org; Fri, 30 Nov 2007 04:06:56 -0500 Received: from static-ip-174-194-65-202.rev.dyxnet.com ([202.65.194.174] helo=hitachihk8.hitachi.cn) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy1pn-0006MC-RY for mext@ietf.org; Fri, 30 Nov 2007 04:06:56 -0500 Received: (qmail 18749 invoked from network); 30 Nov 2007 09:06:52 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk8;3b947c892828de839bbabe2f7ab3a28a; Received: from unknown (HELO hitachihk7.hitachi.cn) (170.95.94.4) by 170.95.94.11 with SMTP; 30 Nov 2007 09:06:52 -0000 Received: (qmail 10598 invoked from network); 30 Nov 2007 09:06:51 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk7;861bb3b6d7b51151851cfa7a44f58454; Received: from hchidc401.hitachi-china.com (170.95.94.69) by 172.16.10.10 with SMTP; 30 Nov 2007 09:06:51 -0000 Received: from hchibjrdpyang ([10.96.2.35]) by hchidc401.hitachi-china.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 17:06:50 +0800 From: "Peng Yang" To: "'Hesham Soliman'" , "'marcelo bagnulo braun'" , Subject: RE: [MEXT] New items for the mext charter discussion Date: Fri, 30 Nov 2007 17:06:50 +0800 Message-ID: <007201c83330$57f9e1e0$2302600a@hitachichina.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 30 Nov 2007 09:06:50.0856 (UTC) FILETIME=[580A0E80:01C83330] X-Scanned-By-hitachihk7: Virus scan performed by network-box X-Scanned-By-hitachihk7: Scanner file id is hitachihk7-1196413611.574-10588-000 X-Scanned-By-hitachihk7: No known viruses found in message (received+scanned in 0.01/0.03 secs) X-Scanned-By-hitachihk7: 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-1196413612.412-18725-000 X-Scanned-By-hitachihk8: No known viruses found in message (received+scanned in 0.03/0.04 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 hitachihk7) X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 'Julien Laganier' 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, Hesham: Please check the words in-line with [P.Y] > > > - Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions > > > > > > Work on the solution of interface, by which IKEv2 could get the > > > information from MIPv6 and negotiate or update right IPsec security > > > associations for MIPv6 when MN bootstrap in foreign network or > > > handover to new foreign network. > > > >=> Not important IMO. We already have an IKE-based AAA solution. [P.Y] I guess you are talking about IKEv2 getting MIP6 information (for example: CoA) from AAA for SA negotiation. But when MN bootstrap in foreign network, IKEv2 daemon in MN should get the CoA before the first round-trip of IKE procedure. In this stage, the MIP6 information in AAA is not accessible to MN. And, after handover, it's not so efficient to update SA in MN/HA by this IKE-based AAA way, IMHO. Thanks a lot P.Y Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From FreddyinimitableMorrow@cbsnews.com Fri Nov 30 04:47:30 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy2T4-0001PH-Hk; Fri, 30 Nov 2007 04:47:30 -0500 Received: from pool-71-124-156-71.bstnma.east.verizon.net ([71.124.156.71] helo=bob.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iy2T3-0004hP-8t; Fri, 30 Nov 2007 04:47:30 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host52811933.cbsnews.com (8.13.1/8.13.1) with SMTP id cWQmka1896.508885.bGx.1L2.4267600636505 for ; Fri, 30 Nov 2007 04:40:32 +0500 Message-ID: <5b88001c83335$170dc200$2e01a8c0@bob> From: "Junior Gilmore" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_5B87C_01C83335.170DC200-- From IsidroheadsetWeeks@brownsvilleherald.com Fri Nov 30 06:17:18 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy3ry-0003CA-1d; Fri, 30 Nov 2007 06:17:18 -0500 Received: from 62.43.195.45.static.user.ono.com ([62.43.195.45] helo=terminal01) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iy3rw-0008B8-RD; Fri, 30 Nov 2007 06:17:17 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host67107663.brownsvilleherald.com (8.13.1/8.13.1) with SMTP id 42u7vr7486.027666.SuC.qgV.2450491410568 for ; Fri, 30 Nov 2007 12:16:47 -0100 Message-ID: <1654c01c83342$8cc9e980$0b01a8c0@Terminal01> From: "Isidro Rivers" To: Subject: Your order Date: Fri, 30 Nov 2007 12:16:47 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_16548_01C83342.8CC9E980" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_16548_01C83342.8CC9E980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_16548_01C83342.8CC9E980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_16548_01C83342.8CC9E980-- From mext-bounces@ietf.org Fri Nov 30 06:17: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 1Iy3sB-0003Hy-I5; Fri, 30 Nov 2007 06:17:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy3sA-0003Hr-Qt for mext@ietf.org; Fri, 30 Nov 2007 06:17:30 -0500 Received: from smtp03.uc3m.es ([163.117.176.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy3s9-0003FT-Ay for mext@ietf.org; Fri, 30 Nov 2007 06:17:30 -0500 Received: from [163.117.139.227] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.227])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp03.uc3m.es (Postfix) with ESMTP id 937D8262703;Fri, 30 Nov 2007 12:17:28 +0100 (CET) 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: marcelo bagnulo braun Date: Fri, 30 Nov 2007 12:17:28 +0100 To: mext@ietf.org X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-7.3203 TC:1F TRN:16 TV:5.0.1023(15576.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -1.9 (-) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Julien Laganier Subject: [MEXT] Proposed MEXT interim meeting february 2008 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, We are considering the possibility of doing a MEXT interim meeting before the 71 IETF. The dates we are considering are the 6, 7 or 8 of feb 2008 The duration would be about one day and half. The proposed location would be somewhere in Europe (well connected city) The meeting will be a MEXT interim meeting so it is open to discuss any MEXT related item, but the main motivation for having such an interim meeting is to start working on the NEMO RO solution and related NEMO deployment items. We would like to know how many people would be willing to attend to this meeting. Please send a private email to the chairs stating if you are willing to attend. Thanks, Julien and marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 30 06:27: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 1Iy41r-0006vG-TM; Fri, 30 Nov 2007 06:27:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy41q-0006v1-Hg for mext@ietf.org; Fri, 30 Nov 2007 06:27:30 -0500 Received: from smtp03.uc3m.es ([163.117.176.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy41o-0004Ic-Ab for mext@ietf.org; Fri, 30 Nov 2007 06:27:30 -0500 Received: from [163.117.139.227] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.227])by smtp03.uc3m.es (Postfix) with ESMTP id 7AB482628BE;Fri, 30 Nov 2007 12:27:26 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MEXT] New items for the mext charter discussion Date: Fri, 30 Nov 2007 12:27:26 +0100 To: Basavaraj Patil X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-13.9645 TC:1F TRN:31 TV:5.0.1023(15576.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -1.9 (-) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Julien Laganier , 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 Vijay, El 29/11/2007, a las 22:17, Basavaraj Patil escribi=F3: > > Marcelo, > > On 11/29/07 5:55 AM, "ext marcelo bagnulo braun" > wrote: > >> >> - Generic Notification Message for Mobile IPv6 >> >> A proposal for defining generic notification framework that can be >> used by the mobility >> entities for sending and receiving asynchronous notification messages >> was proposed and >> the same was adopted by the WG. >> > > This was already adopted by the MIP6 WG via consensus call and =20 > published as > a MIP6 WG document. Why revisit this discussion again? > I thought the MEXT charter would include all the WG I-Ds from MIP6, =20= > NEMO and > MONAMI6 to begin with. > AFAIU, this is not included in the MEXT charter, so in order to work =20 on this (or in any other work item), it must be included in the MEXT =20 charter. So, if there is consensus in the WG that we should work on =20 this, and the Ads are ok with it, we include it in the charter and we =20= do it. But as long we don't have it in the charter, we as MEXT wg we =20 cannot work on that. hence, why this is in the charter discussion (I don't know why this was not included in the MEXT charter in the =20 first place though, but at this point, it seems that this is not part =20= of the work MEXT is chartered to do) Regards, marcelo > -Raj > > > _______________________________________________ > 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 ElmolightRosa@boston.com Fri Nov 30 07:34:56 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy556-0006MH-Cu; Fri, 30 Nov 2007 07:34:56 -0500 Received: from cpc1-brmb1-0-0-cust442.bagu.cable.ntl.com ([82.27.101.187] helo=jones8o82yd2rg) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iy555-00014T-UG; Fri, 30 Nov 2007 07:34:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host63885449.boston.com (8.13.1/8.13.1) with SMTP id WxPvTmEl72.884971.vPt.ifR.6520056203268 for ; Fri, 30 Nov 2007 12:34:32 +0000 Message-ID: <45aaa01c8334d$6600dc90$bb651b52@jones8o82yd2rg> From: "Jerrod Fry" To: Subject: Your life Date: Fri, 30 Nov 2007 12:34:32 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_45AA6_01C8334D.6600DC90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_45AA6_01C8334D.6600DC90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_45AA6_01C8334D.6600DC90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_45AA6_01C8334D.6600DC90-- From mext-bounces@ietf.org Fri Nov 30 08:13:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy5gC-0008Kx-NS; Fri, 30 Nov 2007 08:13:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy5gB-0008Cz-FI for mext@ietf.org; Fri, 30 Nov 2007 08:13:15 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy5gB-0001nY-3a for mext@ietf.org; Fri, 30 Nov 2007 08:13:15 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lAUDD6f11900; Fri, 30 Nov 2007 13:13:06 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] Proposed MEXT interim meeting february 2008 Date: Fri, 30 Nov 2007 07:13:04 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Proposed MEXT interim meeting february 2008 Thread-Index: AcgzQqJVuzfKn4drTQ2dZF22gvnlzwAD92sA References: From: "Ahmad Muhanna" To: "marcelo bagnulo braun" , X-Spam-Score: -4.0 (----) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Julien Laganier 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 Marcelo, It would be helpful to mention where the meeting will be held. Thanks. Regards, Ahmad =20 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Friday, November 30, 2007 5:17 AM > To: mext@ietf.org > Cc: Julien Laganier > Subject: [MEXT] Proposed MEXT interim meeting february 2008 >=20 > Hi, >=20 > We are considering the possibility of doing a MEXT interim=20 > meeting before the 71 IETF. >=20 > The dates we are considering are the 6, 7 or 8 of feb 2008 >=20 > The duration would be about one day and half. >=20 > The proposed location would be somewhere in Europe (well=20 > connected city) >=20 > The meeting will be a MEXT interim meeting so it is open to=20 > discuss any MEXT related item, but the main motivation for=20 > having such an interim meeting is to start working on the=20 > NEMO RO solution and related NEMO deployment items. >=20 > We would like to know how many people would be willing to=20 > attend to this meeting. >=20 > Please send a private email to the chairs stating if you are=20 > willing to attend. >=20 > Thanks, Julien and marcelo >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 30 08:31: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 1Iy5y1-00005m-08; Fri, 30 Nov 2007 08:31:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy5y0-00005Q-3Y for mext@ietf.org; Fri, 30 Nov 2007 08:31:40 -0500 Received: from mxs1.siemens.at ([194.138.12.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy5xz-0002SO-Et for mext@ietf.org; Fri, 30 Nov 2007 08:31:40 -0500 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs1.siemens.at with ESMTP id lAUDVQUa003102; Fri, 30 Nov 2007 14:31:26 +0100 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id lAUDVPN1012061; Fri, 30 Nov 2007 14:31:25 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Nov 2007 14:31:24 +0100 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: [MEXT] v4 HoA allocation using IKEv2 in DSMIP6 Date: Fri, 30 Nov 2007 14:31:01 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD680306F1C1@zagh223a.ww300.siemens.net> In-Reply-To: <474F32B3.2080304@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] v4 HoA allocation using IKEv2 in DSMIP6 Thread-Index: Acgy0ROUZtPbtyT6ToKvxqnRSDWo4gAfvRhA References: <3C31CDD06342EA4A8137716247B1CD680304849D@zagh223a.ww300.siemens.net> <474F0632.2090306@azairenet.com> <474F32B3.2080304@azairenet.com> From: "Premec, Domagoj" To: "Vijay Devarapalli" , "George Tsirtsis" X-OriginalArrivalTime: 30 Nov 2007 13:31:24.0841 (UTC) FILETIME=[4DABF190:01C83355] 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::071130143126-6719EBB0-67507BEC/0-0/0-15 X-purgate-size: 3103/0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Hesham Soliman , 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 Vijay, > My original question still stands, why would you do all this=20 > instead of getting the IPv4 home address as part of the=20 > BU/BAck exchange. I would put this other way around, what prevents the MN to use IKE to = get v4 HoA? It comes at no additional cost and is inline with MIPv6. It = seems to me that MN has two mechanisms at its disposal, so I thought it = could be worth to mention both of them in the spec. That's all.=20 domagoj P.S. I would be happier if there were only one mechanism. > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com]=20 > Sent: 29. studeni 2007 22:44 > To: George Tsirtsis > Cc: Premec, Domagoj; mext@ietf.org; Hesham Soliman > Subject: Re: [MEXT] v4 HoA allocation using IKEv2 in DSMIP6 >=20 > George Tsirtsis wrote: > > Vijay why do you say that? If this works for IPv6 address=20 > why does it=20 > > not work for IPv4 address? >=20 > RFC 4877 and 5026 specify how the IPv6 address obtained in the > IKEv2 configuration payloads is used as the the home address.=20 > In DS-MIPv6, the IPv4 home address is "associated" with the=20 > binding cache entry that is based on the IPv6 home address=20 > (or the MN identifier), when the IPv4 home address is=20 > allocated as part of the BU/BAck exchange. >=20 > > In either case the MN will then have to include these=20 > addresses in the=20 > > BU, so the HA will know. >=20 > If the MN includes the IPv4 home address in the BU, then you=20 > are right it would work. >=20 > My original question still stands, why would you do all this=20 > instead of getting the IPv4 home address as part of the=20 > BU/BAck exchange. >=20 > Vijay >=20 > >=20 > > George > >=20 > > On Nov 29, 2007 6:34 PM, Vijay Devarapalli=20 > > wrote: > >> Premec, Domagoj wrote: > >>> Hi Hesham, > >>> > >>> I was wondering if DSMIP6 host can request v4 HoA in IKEv2 CFG=20 > >>> payload and then use it as v4 HoA in the BU? It seems=20 > that this is=20 > >>> possible as it is not precluded by the spec, but on the=20 > other hand=20 > >>> section 2.5 "Dynamic v4 HoA allocation" mentiones only BU with=20 > >>> 0.0.0.0 as a means to dynamically get IPv4 HoA. Maybe a sentence=20 > >>> could be added to the draft to clarify this? > >> Why would you want the IPv4 HoA in the IKEv2 exchange? If=20 > the IKEv2=20 > >> configuration payloads are used, the HA and the MN might not know=20 > >> that is an IPv4 HoA to be associated with the DS-MIPv6=20 > binding cache=20 > >> entry. > >> > >> Vijay > >> > >> > >>> thanks > >>> domagoj > >>> > >>> > >>> > >>>=20 > -------------------------------------------------------------------- > >>> ---- > >>> > >>> _______________________________________________ > >>> 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 > >> >=20 >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 30 08:33: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 1Iy5zM-0000o6-AS; Fri, 30 Nov 2007 08:33:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy5zK-0000nR-RT for mext@ietf.org; Fri, 30 Nov 2007 08:33:02 -0500 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy5zJ-0002lU-Dh for mext@ietf.org; Fri, 30 Nov 2007 08:33:01 -0500 Received: from oaamta03sl.mx.bigpond.com ([124.190.106.219]) by omta04sl.mx.bigpond.com with ESMTP id <20071130133257.HMMH1805.omta04sl.mx.bigpond.com@oaamta03sl.mx.bigpond.com> for ; Fri, 30 Nov 2007 13:32:57 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta03sl.mx.bigpond.com with ESMTP id <20071130133257.YPQK12231.oaamta03sl.mx.bigpond.com@PC20005>; Fri, 30 Nov 2007 13:32:57 +0000 From: "Hesham Soliman" To: "'Peng Yang'" , "'marcelo bagnulo braun'" , Subject: RE: [MEXT] New items for the mext charter discussion Date: Sat, 1 Dec 2007 00:32:43 +1000 Message-ID: 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.3198 In-Reply-To: <007201c83330$57f9e1e0$2302600a@hitachichina.com> Thread-Index: AcgzMFqCAcHsXivfRfSTNrtLOToPBAALSD2g X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'Julien Laganier' 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 > > >=> Not important IMO. We already have an IKE-based AAA solution. > [P.Y] I guess you are talking about IKEv2 getting MIP6 > information (for > example: CoA) from AAA for SA negotiation. But when MN bootstrap in > foreign network, IKEv2 daemon in MN should get the CoA > before the first > round-trip of IKE procedure. => I'm not sure what you mean by that. Of course any piece of networking SW on the MN would need to know its address before it starts communicating. But I don't see the relationship to this discussion. In this stage, the MIP6 > information in AAA > is not accessible to MN. And, after handover, it's not so > efficient to > update SA in MN/HA by this IKE-based AAA way, IMHO. => I'm sorry I can't follow. Have you looked at the IKEv2-based bootstrapping work? It covers this scenario. Hesham > > Thanks a lot > P.Y > > > > Disclaimer: > The contents of this e-mail, and its attachments, if any, > are confidential and may be protected > by law against any unauthorized use. If you have received > this e-mail by mistake or have > reason to believe that you are not the intended recipient, > please notify the sender by reply > e-mail as soon as possible and delete it from your computer > system immediately thereafter. > If you are not the intended recipient, you must not copy > this e-mail or attachment or disclose > the contents to any other person. While we have made every > effort to keep our network virus free, > we take no responsibility for any computer virus which might > be transferred by way of this e-mail. > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 30 08:36:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy62E-0002rA-W8; Fri, 30 Nov 2007 08:36:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy62C-0002pv-CZ for mext@ietf.org; Fri, 30 Nov 2007 08:36:00 -0500 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy62A-0003QQ-Pj for mext@ietf.org; Fri, 30 Nov 2007 08:35:59 -0500 Received: from oaamta07sl.mx.bigpond.com ([124.190.106.219]) by omta02sl.mx.bigpond.com with ESMTP id <20071130133556.UOKQ22254.omta02sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com> for ; Fri, 30 Nov 2007 13:35:56 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta07sl.mx.bigpond.com with ESMTP id <20071130133551.YSKE11533.oaamta07sl.mx.bigpond.com@PC20005>; Fri, 30 Nov 2007 13:35:51 +0000 From: "Hesham Soliman" To: "'Premec, Domagoj'" , "'Vijay Devarapalli'" , "'George Tsirtsis'" Subject: RE: [MEXT] v4 HoA allocation using IKEv2 in DSMIP6 Date: Sat, 1 Dec 2007 00:35:38 +1000 Message-ID: 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.3198 In-Reply-To: <3C31CDD06342EA4A8137716247B1CD680306F1C1@zagh223a.ww300.siemens.net> Thread-Index: Acgy0ROUZtPbtyT6ToKvxqnRSDWo4gAfvRhAAAN/nSA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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 > > My original question still stands, why would you do all this > > instead of getting the IPv4 home address as part of the > > BU/BAck exchange. > > I would put this other way around, what prevents the MN to > use IKE to get v4 HoA? => In the absence of an IPv6 home address, the MN cannot send a BU. So you may be able to do this once you already have an IPv6 address, but you can't do it without it. We do not support the mapped address format in the BU anymore, therefore you can't send a BU without having a real IPv6 home address. Hesham It comes at no additional cost and is > inline with MIPv6. It seems to me that MN has two mechanisms > at its disposal, so I thought it could be worth to mention > both of them in the spec. That's all. > > domagoj > > P.S. > I would be happier if there were only one mechanism. > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > > Sent: 29. studeni 2007 22:44 > > To: George Tsirtsis > > Cc: Premec, Domagoj; mext@ietf.org; Hesham Soliman > > Subject: Re: [MEXT] v4 HoA allocation using IKEv2 in DSMIP6 > > > > George Tsirtsis wrote: > > > Vijay why do you say that? If this works for IPv6 address > > why does it > > > not work for IPv4 address? > > > > RFC 4877 and 5026 specify how the IPv6 address obtained in the > > IKEv2 configuration payloads is used as the the home address. > > In DS-MIPv6, the IPv4 home address is "associated" with the > > binding cache entry that is based on the IPv6 home address > > (or the MN identifier), when the IPv4 home address is > > allocated as part of the BU/BAck exchange. > > > > > In either case the MN will then have to include these > > addresses in the > > > BU, so the HA will know. > > > > If the MN includes the IPv4 home address in the BU, then you > > are right it would work. > > > > My original question still stands, why would you do all this > > instead of getting the IPv4 home address as part of the > > BU/BAck exchange. > > > > Vijay > > > > > > > > George > > > > > > On Nov 29, 2007 6:34 PM, Vijay Devarapalli > > > wrote: > > >> Premec, Domagoj wrote: > > >>> Hi Hesham, > > >>> > > >>> I was wondering if DSMIP6 host can request v4 HoA in IKEv2 CFG > > >>> payload and then use it as v4 HoA in the BU? It seems > > that this is > > >>> possible as it is not precluded by the spec, but on the > > other hand > > >>> section 2.5 "Dynamic v4 HoA allocation" mentiones only BU with > > >>> 0.0.0.0 as a means to dynamically get IPv4 HoA. Maybe > a sentence > > >>> could be added to the draft to clarify this? > > >> Why would you want the IPv4 HoA in the IKEv2 exchange? If > > the IKEv2 > > >> configuration payloads are used, the HA and the MN > might not know > > >> that is an IPv4 HoA to be associated with the DS-MIPv6 > > binding cache > > >> entry. > > >> > > >> Vijay > > >> > > >> > > >>> thanks > > >>> domagoj > > >>> > > >>> > > >>> > > >>> > > > -------------------------------------------------------------------- > > >>> ---- > > >>> > > >>> _______________________________________________ > > >>> 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 > > >> > > > > > > _______________________________________________ > 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 Fri Nov 30 08:36: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 1Iy635-0003Kp-22; Fri, 30 Nov 2007 08:36:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy633-0003KN-QS for mext@ietf.org; Fri, 30 Nov 2007 08:36:53 -0500 Received: from mxs2.siemens.at ([194.138.12.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy633-0003di-83 for mext@ietf.org; Fri, 30 Nov 2007 08:36:53 -0500 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs2.siemens.at with ESMTP id lAUDamkf023617; Fri, 30 Nov 2007 14:36:48 +0100 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id lAUDaijT014516; Fri, 30 Nov 2007 14:36:45 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Nov 2007 14:36:12 +0100 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: [MEXT] v4 HoA allocation using IKEv2 in DSMIP6 Date: Fri, 30 Nov 2007 14:36:11 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD680306F1DE@zagh223a.ww300.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] v4 HoA allocation using IKEv2 in DSMIP6 Thread-Index: AcgysVf7Pt03DDv5QVmpkHJsibh+PAAo/Hpg References: <3C31CDD06342EA4A8137716247B1CD680304849D@zagh223a.ww300.siemens.net> From: "Premec, Domagoj" To: "George Tsirtsis" X-OriginalArrivalTime: 30 Nov 2007 13:36:12.0829 (UTC) FILETIME=[F9536CD0:01C83355] 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::071130143648-519BCBB0-51E6C21D/0-0/0-15 X-purgate-size: 1718/999999 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: mext@ietf.org, Hesham Soliman 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 George, > I think if the IPv4 address in the BU is not 0.0.0.0, then=20 > from the perspective of DSMIPv6, it is not dynamically=20 > allocated. I think that would be the case if the IPv4 address=20 > was allocated outside DSMIPv6, with whatever way, including via IKEv2. I see. I was looking at terms static and dynamic from the perspective of = the MN. regards domagoj =20 > -----Original Message----- > From: George Tsirtsis [mailto:tsirtsis@googlemail.com]=20 > Sent: 29. studeni 2007 18:58 > To: Premec, Domagoj > Cc: Hesham Soliman; mext@ietf.org > Subject: Re: [MEXT] v4 HoA allocation using IKEv2 in DSMIP6 >=20 > Hi Domagoj, >=20 > I think if the IPv4 address in the BU is not 0.0.0.0, then=20 > from the perspective of DSMIPv6, it is not dynamically=20 > allocated. I think that would be the case if the IPv4 address=20 > was allocated outside DSMIPv6, with whatever way, including via IKEv2. >=20 > Regards > George >=20 > On Nov 29, 2007 4:03 PM, Premec, Domagoj=20 > wrote: > > > > > > Hi Hesham, > > > > I was wondering if DSMIP6 host can request v4 HoA in IKEv2=20 > CFG payload=20 > > and then use it as v4 HoA in the BU? It seems that this is=20 > possible as=20 > > it is not precluded by the spec, but on the other hand section 2.5=20 > > "Dynamic v4 HoA allocation" mentiones only BU with 0.0.0.0=20 > as a means=20 > > to dynamically get > > IPv4 HoA. Maybe a sentence could be added to the draft to=20 > clarify this? > > > > thanks > > domagoj > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > > > >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From MarialessorShirley@biblegateway.com Fri Nov 30 08:43:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy692-0002bZ-VV; Fri, 30 Nov 2007 08:43:05 -0500 Received: from bzq-84-109-10-2.red.bezeqint.net ([84.109.10.2] helo=home5428b82fb4) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iy692-0004xc-8V; Fri, 30 Nov 2007 08:43:04 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host50265166.biblegateway.com (8.13.1/8.13.1) with SMTP id aDAeE6VG29.841069.clJ.WEk.7680617945280 for ; Fri, 30 Nov 2007 15:42:39 -0200 Message-ID: <35fa601c83356$eaeaf590$020a6d54@home5428b82fb4> From: "Ruth Shea" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_35FA2_01C83356.EAEAF590-- From mext-bounces@ietf.org Fri Nov 30 09:02:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy6Ra-0005VW-Gt; Fri, 30 Nov 2007 09:02:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy6RZ-0005VL-TG for mext@ietf.org; Fri, 30 Nov 2007 09:02:13 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iy6RX-0003hw-In for mext@ietf.org; Fri, 30 Nov 2007 09:02:13 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1196431330!10113741!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 14147 invoked from network); 30 Nov 2007 14:02:10 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-10.tower-128.messagelabs.com with SMTP; 30 Nov 2007 14:02:10 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lAUE299X023672; Fri, 30 Nov 2007 07:02:09 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lAUE289A019796; Fri, 30 Nov 2007 08:02:08 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id lAUE25Gv019674; Fri, 30 Nov 2007 08:02:06 -0600 (CST) Message-ID: <475017D5.20002@gmail.com> Date: Fri, 30 Nov 2007 15:01:57 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [MEXT] Proposed MEXT interim meeting february 2008 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071128-0, 28/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Julien Laganier , 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 marcelo bagnulo braun wrote: > Hi, > > We are considering the possibility of doing a MEXT interim meeting > before the 71 IETF. > > The dates we are considering are the 6, 7 or 8 of feb 2008 > > The duration would be about one day and half. > > The proposed location would be somewhere in Europe (well connected > city) > > The meeting will be a MEXT interim meeting so it is open to discuss > any MEXT related item, but the main motivation for having such an > interim meeting is to start working on the NEMO RO solution and > related NEMO deployment items. People spend money to meet interim for NEMO RO? Sounds as if some new strong incentive showed up recently for developing NEMO RO solution? Some opportunity resulted from market research I haven't seen coming? Some SDO requesting this? Some new customer requesting this? Or is it just because it's been on table for years and we should simply advance it to finish it once for all? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 30 09:08: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 1Iy6XT-0001ea-CT; Fri, 30 Nov 2007 09:08:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy6XS-0001e8-4X for mext@ietf.org; Fri, 30 Nov 2007 09:08:18 -0500 Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy6XR-00024f-O3 for mext@ietf.org; Fri, 30 Nov 2007 09:08:18 -0500 X-IronPort-AV: E=Sophos;i="4.23,234,1194217200"; d="vcf'?scan'208";a="19850272" Received: from dhcp-rocq-52.inria.fr ([128.93.62.52]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Nov 2007 15:08:16 +0100 Message-ID: <47501944.8010609@inria.fr> Date: Fri, 30 Nov 2007 15:08:04 +0100 From: Thierry Ernst Organization: INRIA User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [MEXT] Proposed MEXT interim meeting february 2008 References: <475017D5.20002@gmail.com> In-Reply-To: <475017D5.20002@gmail.com> Content-Type: multipart/mixed; boundary="------------080905040506030409080609" X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: mext@ietf.org, Julien Laganier 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 This is a multi-part message in MIME format. --------------080905040506030409080609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> We are considering the possibility of doing a MEXT interim meeting >> before the 71 IETF. >> >> The dates we are considering are the 6, 7 or 8 of feb 2008 >> >> The duration would be about one day and half. >> >> The proposed location would be somewhere in Europe (well connected >> city) >> >> The meeting will be a MEXT interim meeting so it is open to discuss >> any MEXT related item, but the main motivation for having such an >> interim meeting is to start working on the NEMO RO solution and >> related NEMO deployment items. > > People spend money to meet interim for NEMO RO? > > Sounds as if some new strong incentive showed up recently for developing > NEMO RO solution? Some opportunity resulted from market research I > haven't seen coming? Some SDO requesting this? Some new customer > requesting this? > > Or is it just because it's been on table for years and we should simply > advance it to finish it once for all? I guess it's a mix of all of that and a desire to move forward addressing operational needs in NEMO. This is why I would call to enlarge this interim meeting to simply discuss "NEMO Operational issues" , including prefix delegation and anything else along these lines. Actually, we should have had NEMO interim meetings in the past, probably we would have progressed at lot on this. Thierry --------------080905040506030409080609 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA Rocquencourt;IMARA - LARA adr:;;;;;;France tel;work:+33 1 39 63 59 30 tel;fax:+33 1 39 63 54 91 url:http://www.lara.prd.fr version:2.1 end:vcard --------------080905040506030409080609 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 --------------080905040506030409080609-- From mext-bounces@ietf.org Fri Nov 30 09:35: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 1Iy6xX-0008H4-2I; Fri, 30 Nov 2007 09:35:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy6xV-0008GL-5K for mext@ietf.org; Fri, 30 Nov 2007 09:35:13 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy6xU-0008MU-RR for mext@ietf.org; Fri, 30 Nov 2007 09:35:13 -0500 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 9046925; Fri, 30 Nov 2007 09:35:12 -0500 In-Reply-To: <47501944.8010609@inria.fr> References: <475017D5.20002@gmail.com> <47501944.8010609@inria.fr> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0A4AEAF4-F56A-47D0-BF0D-EDFA6F1C007B@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [MEXT] Proposed MEXT interim meeting february 2008 Date: Fri, 30 Nov 2007 09:35:02 -0500 To: Thierry Ernst X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Julien Laganier , 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 What will this meeting do that could not be done in either Vancouver or Philadelphia ? Regards Marshall On Nov 30, 2007, at 9:08 AM, Thierry Ernst wrote: > >>> We are considering the possibility of doing a MEXT interim >>> meeting before the 71 IETF. >>> >>> The dates we are considering are the 6, 7 or 8 of feb 2008 >>> >>> The duration would be about one day and half. >>> >>> The proposed location would be somewhere in Europe (well connected >>> city) >>> >>> The meeting will be a MEXT interim meeting so it is open to discuss >>> any MEXT related item, but the main motivation for having such an >>> interim meeting is to start working on the NEMO RO solution and >>> related NEMO deployment items. >> People spend money to meet interim for NEMO RO? >> Sounds as if some new strong incentive showed up recently for >> developing >> NEMO RO solution? Some opportunity resulted from market research I >> haven't seen coming? Some SDO requesting this? Some new customer >> requesting this? >> Or is it just because it's been on table for years and we should >> simply >> advance it to finish it once for all? > > I guess it's a mix of all of that and a desire to move forward > addressing operational needs in NEMO. This is why I would call to > enlarge this interim meeting to simply discuss "NEMO Operational > issues" , including prefix delegation and anything else along these > lines. > > Actually, we should have had NEMO interim meetings in the past, > probably we would have progressed at lot on this. > > > Thierry > > _______________________________________________ > 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 Fri Nov 30 10:11:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy7WB-0001TL-Hl; Fri, 30 Nov 2007 10:11:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy7WA-0001T5-Ds for mext@ietf.org; Fri, 30 Nov 2007 10:11:02 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy7WA-0003OB-2j for mext@ietf.org; Fri, 30 Nov 2007 10:11:02 -0500 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 lAUFAmvZ023253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Nov 2007 09:10:49 -0600 (CST) 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 lAUFAm8D006370; Fri, 30 Nov 2007 09:10:48 -0600 (CST) 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 lAUFAjIU006244; Fri, 30 Nov 2007 09:10:48 -0600 (CST) 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, 30 Nov 2007 07:10:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] Proposed MEXT interim meeting february 2008 Date: Fri, 30 Nov 2007 07:10:00 -0800 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A0537BC82@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Proposed MEXT interim meeting february 2008 Thread-Index: AcgzQqX9xy/v+a9gRdm34x2jFe/9AQAIGNyQ References: From: "Davis, Terry L" To: "marcelo bagnulo braun" , X-OriginalArrivalTime: 30 Nov 2007 15:10:46.0797 (UTC) FILETIME=[2F463BD0:01C83363] X-Spam-Score: -4.0 (----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Julien Laganier 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 Marcelo I will put it in my calendar. Take care Terry > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: Friday, November 30, 2007 3:17 AM > To: mext@ietf.org > Cc: Julien Laganier > Subject: [MEXT] Proposed MEXT interim meeting february 2008 >=20 > Hi, >=20 > We are considering the possibility of doing a MEXT interim meeting > before the 71 IETF. >=20 > The dates we are considering are the 6, 7 or 8 of feb 2008 >=20 > The duration would be about one day and half. >=20 > The proposed location would be somewhere in Europe (well connected city) >=20 > The meeting will be a MEXT interim meeting so it is open to discuss > any MEXT related item, but the main motivation for having such an > interim meeting is to start working on the NEMO RO solution and > related NEMO deployment items. >=20 > We would like to know how many people would be willing to attend to > this meeting. >=20 > Please send a private email to the chairs stating if you are willing > to attend. >=20 > Thanks, Julien and marcelo >=20 > _______________________________________________ > 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 nemo-bounces@ietf.org Fri Nov 30 10:19:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy7eG-0004kw-Ej; Fri, 30 Nov 2007 10:19:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy7eE-0004jt-Lc; Fri, 30 Nov 2007 10:19:22 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iy7eD-00032h-SP; Fri, 30 Nov 2007 10:19:22 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm8b47509760; Fri, 30 Nov 2007 23:32:17 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmff474b7b4c; Tue, 27 Nov 2007 05:31:11 +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, 27 Nov 2007 05:31:11 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwlIo-0007ch-J2; Mon, 26 Nov 2007 16:15:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwlIi-00075N-SU; Mon, 26 Nov 2007 16:15:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwlIi-0005Oz-LO; Mon, 26 Nov 2007 16:15:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 893D82AC48; Mon, 26 Nov 2007 21:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IwlIE-0003WR-7t; Mon, 26 Nov 2007 16:15:02 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Mon, 26 Nov 2007 16:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: nemo@ietf.org, Thierry Ernst Subject: [nemo] WG Action: Conclusion of Network Mobility WG (nemo) X-BeenThere: nemo@ietf.org List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org The Network Mobility WG (nemo)in the Internet Area has concluded. The IESG contact persons are Jari Arkko and Mark Townsley. The mailing list will remain active. "The work continues in the new MEXT WG, combining the Mobile IPv6 related efforts from the MIP6, NEMO, and MONAMI6 WGs. The new WG has its own mailing list. The MIP6, NEMO, and MONAMI6 mailing lists will continue to exist and the archives will be kept available. However, all discussion should be moved to mext@ietf.org instead." _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From mext-bounces@ietf.org Fri Nov 30 10:21:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy7g2-0001Qz-BB; Fri, 30 Nov 2007 10:21:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy7g0-0001QX-Fw; Fri, 30 Nov 2007 10:21:12 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iy7fy-0003eG-Aj; Fri, 30 Nov 2007 10:21:12 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmc47509844; Fri, 30 Nov 2007 23:32:17 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1ad474b7b3b; Tue, 27 Nov 2007 05:31:12 +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, 27 Nov 2007 05:31:12 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwlIK-00049D-KS; Mon, 26 Nov 2007 16:15:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwlIH-00046c-IO; Mon, 26 Nov 2007 16:15:05 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwlIE-0003a9-AG; Mon, 26 Nov 2007 16:15:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 44B3F328BD; Mon, 26 Nov 2007 21:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IwlIE-0003WG-5y; Mon, 26 Nov 2007 16:15:02 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Mon, 26 Nov 2007 16:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Cc: mext@ietf.org, Julien Laganier Subject: [MEXT] WG Action: Mobility EXTensions for IPv6 WG (mext) X-BeenThere: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org A new IETF working group has been formed in the Internet Area. For additional information, please contact the Area Directors or the WG Chairs. +++ Mobility EXTensions for IPv6 (mext) ==================================== Current Status: Active Working Group Chair(s): Julien Laganier Marcelo Bagnulo 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, network mobility (NEMO) 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 (Mobile IPv6) o RFC 3963 (NEMO) o RFC 4877 (Mobile IPv6 Operation with IKEv2) The MEXT Working Group continues the work of the former 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 Mobile IPv6 and NEMO 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 Mobile IPv6 or NEMO capable dual-stack hosts. (A.2) A protocol based solution for enhancing the reliability of home agents and a method to force a host/router 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: Done Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard Done Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard. Done Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard. Dec 2007 Submit Multiple CoA Registration to IESG Dec 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational. Dec 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard. Feb 2008 Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments Feb 2008 Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments Feb 2008 Submit -00 draft on Route Optimization needs for Personal Mobile Router Feb 2008 Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational. Mar 2008 Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard May 2008 Submit -00 draft for solution to aircraft/spacecraft problem May 2008 Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational May 2008 Submit final doc on Route Optimization Needs for Automobile and Highway Deployments, for Informational May 2008 Submit final doc on Route Optimization needs for Personal Mobile Router, for Informational Jun 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. Jun 2008 Determine how to proceed with 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 the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard Aug 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Oct 2008 Submit Flow/binding policy format to IESG, for Proposed Standard Oct 2008 Submit Flow/binding policy transport to IESG, for Proposed Standard Nov 2008 Submit final doc for solution to aircraft/spacecraft problem to the IESG, for Proposed Standard Nov 2008 Recharter to work on the remaining automotive/Personal Mobile Router solutions Dec 2008 Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. Dec 2008 Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From ViolapleadGroves@chinadigitaltimes.net Fri Nov 30 10:43:41 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy81l-0005UJ-F3; Fri, 30 Nov 2007 10:43:41 -0500 Received: from [83.144.138.106] (helo=duarte63b00b3e.pluricanal.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iy81k-0002K1-No; Fri, 30 Nov 2007 10:43:41 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host57170257.chinadigitaltimes.net (8.13.1/8.13.1) with SMTP id swX0XeYu42.197439.l2D.yt9.9078657814817 for ; Fri, 30 Nov 2007 15:43:22 +0000 Message-ID: From: "Marian Cisneros" To: Subject: Approval process Date: Fri, 30 Nov 2007 15:43:22 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_F572_01C83367.C6BE2FA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_F572_01C83367.C6BE2FA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_F572_01C83367.C6BE2FA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_F572_01C83367.C6BE2FA0-- From Guzikjgjjq@aacadman.8k.com Fri Nov 30 11:26:22 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy8h4-0007Yz-MF for nemo-archive@lists.ietf.org; Fri, 30 Nov 2007 11:26:22 -0500 Received: from ppp-225-172.21-151.libero.it ([151.21.172.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy8h3-0007J7-UT for nemo-archive@lists.ietf.org; Fri, 30 Nov 2007 11:26:22 -0500 Received: by 10.195.115.176 with SMTP id gMTLmhMALElPx; Fri, 30 Nov 2007 17:26:29 +0100 (GMT) Received: by 192.168.179.117 with SMTP id tlSEynLhsKYTxZ.2173425194990; Fri, 30 Nov 2007 17:26:27 +0100 (GMT) Message-ID: <000201c8336d$c01320b0$e1ac1597@mattiahgt> From: "hesham Guzik" To: Subject: gakusiin Date: Fri, 30 Nov 2007 17:26:24 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C83376.21D788B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a ------=_NextPart_000_0009_01C83376.21D788B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable haha this girl im dating said i was HUGE... here is my secret = http://mintstl.com/ ------=_NextPart_000_0009_01C83376.21D788B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
haha this girl im dating said i was HUGE... = here is=20 my secret http://mintstl.com/ ------=_NextPart_000_0009_01C83376.21D788B0-- From mext-bounces@ietf.org Fri Nov 30 13:33: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 1IyAfg-0007Ee-4r; Fri, 30 Nov 2007 13:33:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyAfe-0007E8-Qb for mext@ietf.org; Fri, 30 Nov 2007 13:33:02 -0500 Received: from smtp03.uc3m.es ([163.117.176.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyAfe-0008Jm-3S for mext@ietf.org; Fri, 30 Nov 2007 13:33:02 -0500 Received: from [163.117.139.227] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.227])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp03.uc3m.es (Postfix) with ESMTP id 38D8E265E46;Fri, 30 Nov 2007 19:33:01 +0100 (CET) In-Reply-To: <0A4AEAF4-F56A-47D0-BF0D-EDFA6F1C007B@multicasttech.com> References: <475017D5.20002 @gmail.com> <47501944.8010609@inria.fr> <0A4AEAF4-F56A-47D0-BF0D-EDFA6F1C007B@multicasttech.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MEXT] Proposed MEXT interim meeting february 2008 Date: Fri, 30 Nov 2007 19:33:01 +0100 To: Marshall Eubanks X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-21.5808 TC:1F TRN:43 TV:5.0.1023(15578.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.1 (++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: mext@ietf.org, Julien Laganier 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 Marshall, =46rom my experience, having one day an a half meeting helps a lot =20 when we want to forward the work on a topic. In normal IETF meetings =20 we don't have so much time to go in depth on disucssions and i think =20 that this would be useful in this particular case, where we want to =20 start exploring and understanding the solution space for these issues. Regards, marcelo El 30/11/2007, a las 15:35, Marshall Eubanks escribi=F3: > What will this meeting do that could not be done in either =20 > Vancouver or Philadelphia ? > > Regards > Marshall > > On Nov 30, 2007, at 9:08 AM, Thierry Ernst wrote: > >> >>>> We are considering the possibility of doing a MEXT interim =20 >>>> meeting before the 71 IETF. >>>> >>>> The dates we are considering are the 6, 7 or 8 of feb 2008 >>>> >>>> The duration would be about one day and half. >>>> >>>> The proposed location would be somewhere in Europe (well connected >>>> city) >>>> >>>> The meeting will be a MEXT interim meeting so it is open to discuss >>>> any MEXT related item, but the main motivation for having such an >>>> interim meeting is to start working on the NEMO RO solution and >>>> related NEMO deployment items. >>> People spend money to meet interim for NEMO RO? >>> Sounds as if some new strong incentive showed up recently for =20 >>> developing >>> NEMO RO solution? Some opportunity resulted from market research I >>> haven't seen coming? Some SDO requesting this? Some new customer >>> requesting this? >>> Or is it just because it's been on table for years and we should =20 >>> simply >>> advance it to finish it once for all? >> >> I guess it's a mix of all of that and a desire to move forward =20 >> addressing operational needs in NEMO. This is why I would call to =20 >> enlarge this interim meeting to simply discuss "NEMO Operational =20 >> issues" , including prefix delegation and anything else along =20 >> these lines. >> >> Actually, we should have had NEMO interim meetings in the past, =20 >> probably we would have progressed at lot on this. >> >> >> Thierry >> >> _______________________________________________ >> 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 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From DustincontiguousCunningham@annapolischorale.org Fri Nov 30 18:23:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyFCs-0007NM-A7; Fri, 30 Nov 2007 18:23:38 -0500 Received: from bzq-79-179-244-64.red.bezeqint.net ([79.179.244.64] helo=home6f7b948a77) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IyFCq-0002gX-W2; Fri, 30 Nov 2007 18:23:38 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host92072318.annapolischorale.org (8.13.1/8.13.1) with SMTP id zd3ugNae31.556751.RCO.MyC.1741586941691 for ; Sat, 1 Dec 2007 01:23:08 -0200 Message-ID: <2e81301c833a8$0357b0e0$0401a8c0@home6f7b948a77> From: "Warren Payne" To: Cc: , =20

Even if you have no erection problems = Cialis Soft=20 Tabs would help you to make better sex more often and to bring=20 unimaginable plesure to her. Just disolve half a pill under your tongue = and get=20 ready for action in 30 minutes. The tests showed that the majority of = men after=20 taking this medication were able to have perfect erection during = 24=20 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Cialis Soft Tabs gives you confidence in any chance, every time.

------=_NextPart_000_2E80F_01C833A8.0357B0E0--