From mext-bounces@ietf.org Sun Jun 1 06:05:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05D4828C5ED; Sun, 1 Jun 2008 06:05:48 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB0F728C5E5 for ; Sun, 1 Jun 2008 06:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P7S0cPCmblx for ; Sun, 1 Jun 2008 06:05:44 -0700 (PDT) Received: from moog.chdir.org (unknown [IPv6:2002:58bf:2aa0:339b:f654:e10e:317f:e6fa]) by core3.amsl.com (Postfix) with ESMTP id 707CB2A2B45 for ; Sun, 1 Jun 2008 05:23:18 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1K2mah-0000tA-C2; Sun, 01 Jun 2008 14:23:15 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: "George Tsirtsis" References: <48401470.40706@it.uc3m.es> <87mym74jeu.fsf@natisbad.org> <48407564.9000209@it.uc3m.es> <87bq2n4anr.fsf@natisbad.org> X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080601:marcelo@it.uc3m.es::JSJSZhJrSfS9yM2+:00000000000000000000000000000000000000000000yzm X-Hashcash: 1:20:080601:tsirtsis@googlemail.com::GO6jHjMFYuGDd+po:000000000000000000000000000000000000001/Op X-Hashcash: 1:20:080601:julien.ietf@laposte.net::+broYnpgdnra40ei:0000000000000000000000000000000000000038x8 X-Hashcash: 1:20:080601:mext@ietf.org::84JeXVgdgUuD4IJX:00005Yi+ Date: Sun, 01 Jun 2008 14:23:07 +0200 In-Reply-To: (George Tsirtsis's message of "Sun, 1 Jun 2008 08:50:56 +0100") Message-ID: <87tzgdgx90.fsf@natisbad.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0044828919==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0044828919== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Hi George, "George Tsirtsis" writes: >> That been said, it's not because I consider that the document deserves >> to be WG item for that part of the audience that I think it will provide >> a "one size fits all" solution for NEMO PD, for instance for very small >> devices like PDA or Phones. I was basically wondering if I will ever >> have to install and configure a DHCPv6 server with Relay and PD support >> on my Phone or PDA just for the purpose of getting a prefix from my >> HA. But considering what you write below (hiring DHCP for the job is >> the consensus), this will be the case. >> > > Arnaud, > > This maybe simply a misunderstanding but draft-droms does not require > you to do this. The Mobile Router, is a Requesting Router (RR) i.e., a > DHCP-PD client. So no server functionality is required in you small > devices. You are correct, the terms I used were not precise: I thought "daemon" but used "server". I should have said "DHCPv6 relay and/or DHCPv6 client with PD support". My point was that DHCPv6 is in all cases not a light requirement for small devices just for providing a prefix. Anyway, the use of DHCPv6 is the consensus, so I will not argue anymore. Regards, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIQpSxAlWVfAR6UCYRAm3cAJ4lnwlmV20HyItxidSqw/ySYn7FUQCdELji /zqly5zjgHT7KLSN6IooKFg= =vGRg -----END PGP SIGNATURE----- --=-=-=-- --===============0044828919== 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://www.ietf.org/mailman/listinfo/mext --===============0044828919==-- From mext-bounces@ietf.org Sun Jun 1 15:58:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD65F3A6AC6; Sun, 1 Jun 2008 15:57:59 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 128A73A6768 for ; Sun, 1 Jun 2008 15:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cHhy6SfjlDO for ; Sun, 1 Jun 2008 15:49:50 -0700 (PDT) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by core3.amsl.com (Postfix) with ESMTP id 0C33E3A689B for ; Sun, 1 Jun 2008 15:49:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 1BB712E89EC; Mon, 2 Jun 2008 00:49:49 +0200 (CEST) Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIzQ6-KQfqak; Mon, 2 Jun 2008 00:49:48 +0200 (CEST) Received: from [192.168.0.20] (bro67-5-88-177-196-175.fbx.proxad.net [88.177.196.175]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 02FA42E89E5; Mon, 2 Jun 2008 00:49:47 +0200 (CEST) Message-Id: <7E43E173-9E24-4023-9BBE-07BE33BC5B7E@lsiit.u-strasbg.fr> From: Romain KUNTZ To: marcelo bagnulo braun In-Reply-To: <48401470.40706@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 2 Jun 2008 00:49:47 +0200 References: <48401470.40706@it.uc3m.es> X-Mailer: Apple Mail (2.924) Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, I'm in favor of accepting this document as WG doc. I have however one major concern: it proposes to use DHAAD to discover DHCPv6PD-enabled HA. However, the MIPv6 bootstrapping documents does not rely on DHAAD at all. More relationship should be considered between MIPv6 and NEMO bootstrapping, to enable the selection of a DHCPv6PD-enabled HA when the HA selection is performed during the MIPv6 bootstrapping time (e.g. by extending the DNS SRV lookup). About the text itself, for clarity I think that the section about to the home link (3.4) should be merged with section 3.1 ("When the MR uses DHCPv6"). Regards, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr Louis Pasteur University - Networks and Protocols Team On 2008/05/30, at 16:51, marcelo bagnulo braun wrote: > Hi, > > We would like to ask the WG what is their opinion about accepting > draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD > deliverable included in our charter. > > Please provide comments so we cna make some progress on this long > overdue deliverable > > thanks, Julien and marcelo > -------- Mensaje original -------- > Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt > Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) > De: Internet-Drafts@ietf.org > Responder a: internet-drafts@ietf.org > Para: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : DHCPv6 Prefix Delegation for NEMO > Author(s) : R. Droms, et al. > Filename : draft-droms-mext-nemo-pd-00.txt > Pages : 12 > Date : 2008-05-30 > > One aspect of network mobility support is the assignment of a prefix > or prefixes to a Mobile Router (MR) for use on the links in the > Mobile Network. DHCPv6 prefix delegation can be used for this > configuration task. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > Content-Type: text/plain > Content-ID: <2008-05-30054232.I-D@ietf.org> > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Jun 1 16:16:01 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAAA83A6A48; Sun, 1 Jun 2008 16:16:01 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FEEF3A69C4 for ; Sun, 1 Jun 2008 16:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeUTtkLkUmVu for ; Sun, 1 Jun 2008 16:08:21 -0700 (PDT) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by core3.amsl.com (Postfix) with ESMTP id D07CB3A69A0 for ; Sun, 1 Jun 2008 16:08:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 2FD452E8AA2; Mon, 2 Jun 2008 01:08:21 +0200 (CEST) Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EPWArtRpoSO; Mon, 2 Jun 2008 01:08:20 +0200 (CEST) Received: from [192.168.0.20] (bro67-5-88-177-196-175.fbx.proxad.net [88.177.196.175]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 692D22E8A99; Mon, 2 Jun 2008 01:08:20 +0200 (CEST) Message-Id: <6E6D2998-9A0D-460F-B4FD-01C20AB9E556@lsiit.u-strasbg.fr> From: Romain KUNTZ To: Behcet Sarikaya In-Reply-To: <744491.3565.qm@web84303.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 2 Jun 2008 01:08:19 +0200 References: <744491.3565.qm@web84303.mail.re1.yahoo.com> X-Mailer: Apple Mail (2.924) Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0598800263==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0598800263== Content-Type: multipart/alternative; boundary=Apple-Mail-9--21217918 --Apple-Mail-9--21217918 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2008/05/31, at 0:13, Behcet Sarikaya wrote: > I think this is a good point, we should not hurry up a solution just > because it was long overdue. > I have the same concern. Instead of MR, HA could be a better place > for DHCP PD. > http://tools.ietf.org/id/draft-sarikaya-mext-prefix- > delegation-00.txt explains this and it is a much simpler document. I think this document is a companion document to draft-ietf-nemo- prefix-delegation-02, which is based on the MIPv6 signaling (BU/BA) between the MR and the HA for prefix delegation. If I understand well, your document tells how to provision the HA with a list of prefixes, but in the end the MIPv6 signaling is used to delegate a prefix to the MR. This is different from what is proposed in draft-droms-mext-nemo- pd which uses DHCP in all the prefix delegation process. As DHCP already got the consensus of the WG, that would be better to not debate again on "DHCP versus MIP6 signaling". Regards, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr Louis Pasteur University - Networks and Protocols Team --Apple-Mail-9--21217918 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
I think this is a good point, = we should not hurry up a solution just because it was long overdue.
I = have the same concern. Instead of MR, HA could be a better place for = DHCP PD. 
http://tools.ietf.org/id/draft-sarikaya-mext-prefix-delegation-00.txt=  explains this and = it is a much simpler = document.

I think this document is a companion document = to draft-ietf-nemo-prefix-delegation-02, which is based on the = MIPv6 signaling (BU/BA) between the MR and the HA for prefix = delegation. If I understand well, your document tells how to = provision the HA with a list of prefixes, but in the end the MIPv6 = signaling is used to delegate a prefix to the MR. This is different = from what is proposed in draft-droms-mext-nemo-pd which uses DHCP in all = the prefix delegation process. 

As DHCP = already got the consensus of the WG, that would be better to not debate = again on "DHCP versus MIP6 = signaling".

Regards,
kuntz@lsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols = Team

= --Apple-Mail-9--21217918-- --===============0598800263== 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://www.ietf.org/mailman/listinfo/mext --===============0598800263==-- From mext-bounces@ietf.org Sun Jun 1 18:45:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CEEB3A69A0; Sun, 1 Jun 2008 18:45:12 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02C723A68FA for ; Sun, 1 Jun 2008 18:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LzbBIQYfEmj for ; Sun, 1 Jun 2008 18:45:07 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id B751C3A69A0 for ; Sun, 1 Jun 2008 18:45:06 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 1 Jun 2008 21:45:00 -0400 Message-ID: In-Reply-To: <7E43E173-9E24-4023-9BBE-07BE33BC5B7E@lsiit.u-strasbg.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Thread-Index: AcjEOx0fCdV7crzCR9+DSKow/yF0RAAFWLiQ References: <48401470.40706@it.uc3m.es> <7E43E173-9E24-4023-9BBE-07BE33BC5B7E@lsiit.u-strasbg.fr> From: "Vijay Devarapalli" To: "Romain KUNTZ" , "marcelo bagnulo braun" Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Roamin and others, IMO, we should remove the extensions to DHAAD from this document. It's a bad idea to keep extending DHAAD every time we add an extension to MIPv6. We could extend DNS-based HA lookup for discovering a home agent that is capable of NEMO prefix delegation. But I think this is also unnecessary. The mobile router can always try the next home agent in the list of the home agents if the first one does not respond to DHCPv6 messages. If none of the home agents are capable of prefix delegation, then there is nothing the mobile router can do about it, maybe use some static mobile network prefixes. Vijay > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Romain KUNTZ > Sent: Sunday, June 01, 2008 3:50 PM > To: marcelo bagnulo braun > Cc: Julien Laganier; mext@ietf.org > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > Hi, > > I'm in favor of accepting this document as WG doc. > I have however one major concern: it proposes to use DHAAD to > discover > DHCPv6PD-enabled HA. However, the MIPv6 bootstrapping documents does > not rely on DHAAD at all. More relationship should be considered > between MIPv6 and NEMO bootstrapping, to enable the selection of a > DHCPv6PD-enabled HA when the HA selection is performed during the > MIPv6 bootstrapping time (e.g. by extending the DNS SRV lookup). > > About the text itself, for clarity I think that the section about to > the home link (3.4) should be merged with section 3.1 ("When the MR > uses DHCPv6"). > > Regards, > -- > Romain KUNTZ > kuntz@lsiit.u-strasbg.fr > Louis Pasteur University - Networks and Protocols Team > > > On 2008/05/30, at 16:51, marcelo bagnulo braun wrote: > > > Hi, > > > > We would like to ask the WG what is their opinion about accepting > > draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD > > deliverable included in our charter. > > > > Please provide comments so we cna make some progress on this long > > overdue deliverable > > > > thanks, Julien and marcelo > > -------- Mensaje original -------- > > Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt > > Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) > > De: Internet-Drafts@ietf.org > > Responder a: internet-drafts@ietf.org > > Para: i-d-announce@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : DHCPv6 Prefix Delegation for NEMO > > Author(s) : R. Droms, et al. > > Filename : draft-droms-mext-nemo-pd-00.txt > > Pages : 12 > > Date : 2008-05-30 > > > > One aspect of network mobility support is the assignment of a prefix > > or prefixes to a Mobile Router (MR) for use on the links in the > > Mobile Network. DHCPv6 prefix delegation can be used for this > > configuration task. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > Content-Type: text/plain > > Content-ID: <2008-05-30054232.I-D@ietf.org> > > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 2 01:58:58 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A0DE3A6C42; Mon, 2 Jun 2008 01:58:58 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DACE83A6C42 for ; Mon, 2 Jun 2008 01:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.646 X-Spam-Level: X-Spam-Status: No, score=-3.646 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKON8GOi-uaX for ; Mon, 2 Jun 2008 01:58:56 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 15E8B3A67FE for ; Mon, 2 Jun 2008 01:58:55 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (dummyhost21.it.uc3m.es [163.117.139.215])by smtp02.uc3m.es (Postfix) with ESMTP id 7B21239E3DA;Mon, 2 Jun 2008 10:58:55 +0200 (CEST) Message-ID: <4843B64E.8040307@it.uc3m.es> Date: Mon, 02 Jun 2008 10:58:54 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: mext@ietf.org X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-4.5355 TC:1F TRN:15 TV:5.5.1026(15946.005) 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) Cc: charliep@computer.org, Jari Arkko , Julien Laganier Subject: [MEXT] RFC3775 update X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, In last IETF we said that we will accept input for RFC3775 changes for about 3 months and then try to wrap up this issues. This is reminder of that plan and that proposals for changes for RFC3775 are accepted till the 15 of june. After that we will go through the proposed changes and try to reach consensus on each of the proposed changes (including the text to be included and removed) in the ml. After that we will ask the authors of rfc3775 to submit a 3775bis including the accepted changes and go to WGLC. Regards, Julien and marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 2 02:44:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA94B3A688F; Mon, 2 Jun 2008 02:44:46 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF4C3A68F9 for ; Mon, 2 Jun 2008 02:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nosu7VRUaSh3 for ; Mon, 2 Jun 2008 02:44:45 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.245.51]) by core3.amsl.com (Postfix) with SMTP id 052643A688F for ; Mon, 2 Jun 2008 02:44:44 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1212399885!26175462!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 11750 invoked from network); 2 Jun 2008 09:44:45 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-119.messagelabs.com with SMTP; 2 Jun 2008 09:44:45 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m529idHf014966 for ; Mon, 2 Jun 2008 02:44:44 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id m529id6Q005738 for ; Mon, 2 Jun 2008 04:44:39 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id m529icRF005700 for ; Mon, 2 Jun 2008 04:44:38 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Jun 2008 10:44:37 +0100 Message-ID: <4843C104.3030706@gmail.com> Date: Mon, 02 Jun 2008 11:44:36 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4843B64E.8040307@it.uc3m.es> In-Reply-To: <4843B64E.8040307@it.uc3m.es> X-Antivirus: avast! (VPS 080531-1, 31/05/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 02 Jun 2008 09:44:37.0603 (UTC) FILETIME=[458BF330:01C8C495] X-CFilter-Loop: Reflected Cc: charliep@computer.org, Julien Laganier , Jari Arkko , mext@ietf.org Subject: Re: [MEXT] TC/flow label copying (was: RFC3775 update) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, I'm not sure whether this has been discussed or not. rfc3775 is silent about HA copying or ignoring the Trafic Class and Flow Label fields when de/encapsulating from/to MN. It can prove to be an issue when using that field. In some implementations the field _is_ copied, which is a good thing IMHO. On this topic, rfc3775 points to rfc2473 ("Generic Packet Tunneling in IPv6") which further says "Depending on the entry-point node tunnel configuration, the [flow label]/traffic class can be set to that of either the original packet or a pre-configured value." In practice however, many implementations of rfc2473 don't have a means to set a pre-configured value for the traffic class/flow label. This is something relatively difficult to implement because it's difficult to link a set of parameters into a pre-configured traffic class/flow label: What does a pre-configured traffic class/flow label correspond to: a pair of IP addresses? port numbers? etc. On this reasoning, I prefer 3775 to say that the HA must either copy the traffic class/flow label, or set it to 0. Just say a good recommendation instead of relying on rfc2473 unimplemented means of this behaviour. Alex marcelo bagnulo braun wrote: > Hi, > > In last IETF we said that we will accept input for RFC3775 changes for > about 3 months and then try to wrap up this issues. > > This is reminder of that plan and that proposals for changes for RFC3775 > are accepted till the 15 of june. > > After that we will go through the proposed changes and try to reach > consensus on each of the proposed changes (including the text to be > included and removed) in the ml. > > After that we will ask the authors of rfc3775 to submit a 3775bis > including the accepted changes and go to WGLC. > > Regards, Julien and marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 2 02:52:56 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31FC53A688F; Mon, 2 Jun 2008 02:52:56 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C3C33A6BFA for ; Mon, 2 Jun 2008 02:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xd0kwwin+GLq for ; Mon, 2 Jun 2008 02:52:54 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.245.51]) by core3.amsl.com (Postfix) with SMTP id 3FECA28C234 for ; Mon, 2 Jun 2008 02:52:08 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1212400324!32794432!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 25067 invoked from network); 2 Jun 2008 09:52:04 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-13.tower-119.messagelabs.com with SMTP; 2 Jun 2008 09:52:04 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m529q3LP021327 for ; Mon, 2 Jun 2008 02:52:03 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id m529q2Ww000407 for ; Mon, 2 Jun 2008 04:52:02 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id m529q14H000400 for ; Mon, 2 Jun 2008 04:52:01 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Jun 2008 10:52:00 +0100 Message-ID: <4843C2BF.1030302@gmail.com> Date: Mon, 02 Jun 2008 11:51:59 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Vijay Devarapalli References: <48401470.40706@it.uc3m.es> <7E43E173-9E24-4023-9BBE-07BE33BC5B7E@lsiit.u-strasbg.fr> In-Reply-To: X-Antivirus: avast! (VPS 080531-1, 31/05/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 02 Jun 2008 09:52:00.0458 (UTC) FILETIME=[4D8242A0:01C8C496] X-CFilter-Loop: Reflected Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay Devarapalli wrote: > Hi Roamin and others, > > IMO, we should remove the extensions to DHAAD from this document. It's a > bad idea to keep extending DHAAD every time we add an extension to > MIPv6. It's a bad idea to not extend DHAAD. > We could extend DNS-based HA lookup for discovering a home agent that is > capable of NEMO prefix delegation. It's a bad idea to extend DNS for discovering stuff. DNS is not for discovery. Alex But I think this is also unnecessary. > The mobile router can always try the next home agent in the list of the > home agents if the first one does not respond to DHCPv6 messages. If > none of the home agents are capable of prefix delegation, then there is > nothing the mobile router can do about it, maybe use some static mobile > network prefixes. > > Vijay > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Romain KUNTZ >> Sent: Sunday, June 01, 2008 3:50 PM >> To: marcelo bagnulo braun >> Cc: Julien Laganier; mext@ietf.org >> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> >> Hi, >> >> I'm in favor of accepting this document as WG doc. >> I have however one major concern: it proposes to use DHAAD to >> discover >> DHCPv6PD-enabled HA. However, the MIPv6 bootstrapping documents does >> not rely on DHAAD at all. More relationship should be considered >> between MIPv6 and NEMO bootstrapping, to enable the selection of a >> DHCPv6PD-enabled HA when the HA selection is performed during the >> MIPv6 bootstrapping time (e.g. by extending the DNS SRV lookup). >> >> About the text itself, for clarity I think that the section about to >> the home link (3.4) should be merged with section 3.1 ("When the MR >> uses DHCPv6"). >> >> Regards, >> -- >> Romain KUNTZ >> kuntz@lsiit.u-strasbg.fr >> Louis Pasteur University - Networks and Protocols Team >> >> >> On 2008/05/30, at 16:51, marcelo bagnulo braun wrote: >> >>> Hi, >>> >>> We would like to ask the WG what is their opinion about accepting >>> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD >>> deliverable included in our charter. >>> >>> Please provide comments so we cna make some progress on this long >>> overdue deliverable >>> >>> thanks, Julien and marcelo >>> -------- Mensaje original -------- >>> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt >>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >>> De: Internet-Drafts@ietf.org >>> Responder a: internet-drafts@ietf.org >>> Para: i-d-announce@ietf.org >>> >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : DHCPv6 Prefix Delegation for NEMO >>> Author(s) : R. Droms, et al. >>> Filename : draft-droms-mext-nemo-pd-00.txt >>> Pages : 12 >>> Date : 2008-05-30 >>> >>> One aspect of network mobility support is the assignment of a prefix >>> or prefixes to a Mobile Router (MR) for use on the links in the >>> Mobile Network. DHCPv6 prefix delegation can be used for this >>> configuration task. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> >>> Content-Type: text/plain >>> Content-ID: <2008-05-30054232.I-D@ietf.org> >>> >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 2 02:54:08 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118E53A6B94; Mon, 2 Jun 2008 02:54:08 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBD1C3A67F7 for ; Mon, 2 Jun 2008 02:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbC3n8IDcGag for ; Mon, 2 Jun 2008 02:54:06 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id C48593A688F for ; Mon, 2 Jun 2008 02:54:02 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1212400440!2780703!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 28350 invoked from network); 2 Jun 2008 09:54:00 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-128.messagelabs.com with SMTP; 2 Jun 2008 09:54:00 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m529s0Ia017350 for ; Mon, 2 Jun 2008 02:54:00 -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 m529rxI8010752 for ; Mon, 2 Jun 2008 04:53:59 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id m529rwtA010732 for ; Mon, 2 Jun 2008 04:53:58 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Jun 2008 10:53:57 +0100 Message-ID: <4843C335.70608@gmail.com> Date: Mon, 02 Jun 2008 11:53:57 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Arnaud Ebalard References: <48401470.40706@it.uc3m.es> <87mym74jeu.fsf@natisbad.org> <48407564.9000209@it.uc3m.es> <87bq2n4anr.fsf@natisbad.org> <87tzgdgx90.fsf@natisbad.org> In-Reply-To: <87tzgdgx90.fsf@natisbad.org> X-Antivirus: avast! (VPS 080531-1, 31/05/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 02 Jun 2008 09:53:58.0023 (UTC) FILETIME=[93954170:01C8C496] X-CFilter-Loop: Reflected Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Arnaud Ebalard wrote: > Hi George, > > "George Tsirtsis" writes: > >>> That been said, it's not because I consider that the document deserves >>> to be WG item for that part of the audience that I think it will provide >>> a "one size fits all" solution for NEMO PD, for instance for very small >>> devices like PDA or Phones. I was basically wondering if I will ever >>> have to install and configure a DHCPv6 server with Relay and PD support >>> on my Phone or PDA just for the purpose of getting a prefix from my >>> HA. But considering what you write below (hiring DHCP for the job is >>> the consensus), this will be the case. >>> >> Arnaud, >> >> This maybe simply a misunderstanding but draft-droms does not require >> you to do this. The Mobile Router, is a Requesting Router (RR) i.e., a >> DHCP-PD client. So no server functionality is required in you small >> devices. > > You are correct, the terms I used were not precise: I thought "daemon" > but used "server". I should have said "DHCPv6 relay and/or DHCPv6 client > with PD support". My point was that DHCPv6 is in all cases not a light > requirement for small devices just for providing a prefix. That sounds reasonable, but what do you mean by small devices? Most if not all such small devices first things they do when they come alive is DHCP and then TCP and then HTTP. DHCP PD is not heavier than DHCP tout court in terms of message numbers and size. 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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 2 03:02:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF0C93A6BAF; Mon, 2 Jun 2008 03:02:06 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A9B03A6BAF for ; Mon, 2 Jun 2008 03:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6U0c7kYsNhJS for ; Mon, 2 Jun 2008 03:02:00 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.245.51]) by core3.amsl.com (Postfix) with SMTP id 20FAC3A6B94 for ; Mon, 2 Jun 2008 03:01:50 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1212400909!20668189!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 29680 invoked from network); 2 Jun 2008 10:01:49 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-9.tower-119.messagelabs.com with SMTP; 2 Jun 2008 10:01:49 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id m52A1nL6007154 for ; Mon, 2 Jun 2008 03:01:49 -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 m52A1me6010311 for ; Mon, 2 Jun 2008 05:01:48 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id m52A1kre010280 for ; Mon, 2 Jun 2008 05:01:47 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Jun 2008 11:01:45 +0100 Message-ID: <4843C509.9010209@gmail.com> Date: Mon, 02 Jun 2008 12:01:45 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Arnaud Ebalard References: <48401470.40706@it.uc3m.es> <87mym74jeu.fsf@natisbad.org> In-Reply-To: <87mym74jeu.fsf@natisbad.org> X-Antivirus: avast! (VPS 080531-1, 31/05/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 02 Jun 2008 10:01:45.0926 (UTC) FILETIME=[AA799660:01C8C497] X-CFilter-Loop: Reflected Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Arnaud Ebalard wrote: > Hi, > > marcelo bagnulo braun writes: > >> We would like to ask the WG what is their opinion about accepting >> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD >> deliverable included in our charter. >> >> Please provide comments so we cna make some progress on this long >> overdue deliverable > > The document is short and easy to read (good point). On one side, I > think that DHCPv6 makes some sense for Nemo PD for devices with some > capabilities. On the other side, I wonder if it is not overkill > (complexity, roundtrips, ...) for a use in small devices (phone?, PDA?) > that will serve a single subnet with IPv6 stateless @ autoconf > > In practice (as a HA and MR administrator), I'd like to be able to > simply configure the prefixes for my MR in the HA configuration section > for this MR and that those prefixes be sent to the MR during the > initial binding if it ask for prefix(es). In a sense considering the > an initial static configuration of a MR, switching to PD would mean: > > - changing a knob in the MR config to switch to prefix delegation > - giving the prefix in the HA config, indicating PD for that MR I agree. Remark that HA must already know the prefixes of MR, because it must have them in the Prefix Table; regardless of HA using or not PD. It's for security reasons (make sure a certain MR doesn't claim somebody else's prefix in a BU). > i.e. no need for IDs, specific keys for auth, or additional relay and > associated IPsec credentials config. > > I also have some comments on the "Security Considerations" section of > the document. Don't hesitate to tell me if I missed sth or if it is out > of scope. > > IMHO, this is a bit simplistic to delegate the security of NEMO PD to > the Security Considerations sections of DHCPv6 and DHCPv6 PD documents. I mostly agree. It's true however that DHCPv6 PD security is bound to DHCPv6 security overall. If one attacks DHCPv6 then one can attack DHCPv6 PD too. > There are good chances that the environments where MR will operate may > be a bit more hostile than those where more common routers are expected > to operate (in operators or corporate networks). > > Some initial thoughts: > > - What are the hypothesis behind 3315 and 3633 design decisions that do > not hold anymore in MIPv6 environments (if any)? One such hypothesis is that the DHCPv6 Solicit happens between close entities: CLient and Server are usually near each other, often same subnet. With NEMO the MR would be far from its HA. > - "HAs and MRs SHOULD use DHCPv6 authentication": Why not a "MUST"? Maybe because HA and MR would MUST ESP and DHCPv6 auth would be through that ESP. > - how do the security mechanisms of both protocols interact? > - In the simple mode (no relay), how will the use of multicast interact > with IPsec protection of traffic if it is in place? > - HMAC-MD5-based authentication method is the only one defined in > 3315. Is it sufficient? Now, SHA-256 should too rfc4868 "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec". > - What is the impact of the assignment of new prefixes in a dynamic > fashion w.r.t. the SPD and SADB or IKE daemons? How should that be > handled. There may be some indeed. What is the available implementation of DHCPv6 PD that one could configure on a NEMOv6 MR? Alex > - ... > > Regards, > > a+ > > > > ------------------------------------------------------------------------ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 2 03:45:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F4353A6912; Mon, 2 Jun 2008 03:45:51 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A3B3A6AD6 for ; Mon, 2 Jun 2008 03:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zY-Ciyj1yeWz for ; Mon, 2 Jun 2008 03:45:49 -0700 (PDT) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by core3.amsl.com (Postfix) with ESMTP id 271053A690A for ; Mon, 2 Jun 2008 03:45:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 45ABF2EAF29; Mon, 2 Jun 2008 12:45:49 +0200 (CEST) Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoNnjo4UjFQL; Mon, 2 Jun 2008 12:45:48 +0200 (CEST) Received: from [130.79.91.222] (unknown [130.79.91.222]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id EAEF32EAF22; Mon, 2 Jun 2008 12:45:48 +0200 (CEST) Message-Id: <00DF2919-E072-4DD0-B70F-4194B6C9A86E@lsiit.u-strasbg.fr> From: Romain KUNTZ To: Alexandru Petrescu In-Reply-To: <4843C2BF.1030302@gmail.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 2 Jun 2008 12:45:48 +0200 References: <48401470.40706@it.uc3m.es> <7E43E173-9E24-4023-9BBE-07BE33BC5B7E@lsiit.u-strasbg.fr> <4843C2BF.1030302@gmail.com> X-Mailer: Apple Mail (2.924) Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, On 2008/06/02, at 11:51, Alexandru Petrescu wrote: > Vijay Devarapalli wrote: >> Hi Roamin and others, >> IMO, we should remove the extensions to DHAAD from this document. >> It's a >> bad idea to keep extending DHAAD every time we add an extension to >> MIPv6. > > It's a bad idea to not extend DHAAD. The DHAAD extension would still be useful in the case the MIPv6 bootstrapping is not used when the MR starts. But in that case, I would tend to agree with Vijay on the way to proceed (try the next HA on the list if it does not reply to DHCPv6 messages). >> We could extend DNS-based HA lookup for discovering a home agent >> that is >> capable of NEMO prefix delegation. > > It's a bad idea to extend DNS for discovering stuff. DNS is not for > discovery. Not discovering, but resolving a HA+DHCPv6 address through a DNS lookup by service name. Romain >>> -----Original Message----- >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>> Behalf Of Romain KUNTZ >>> Sent: Sunday, June 01, 2008 3:50 PM >>> To: marcelo bagnulo braun >>> Cc: Julien Laganier; mext@ietf.org >>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >>> >>> Hi, >>> >>> I'm in favor of accepting this document as WG doc. >>> I have however one major concern: it proposes to use DHAAD to >>> discover DHCPv6PD-enabled HA. However, the MIPv6 bootstrapping >>> documents does not rely on DHAAD at all. More relationship should >>> be considered between MIPv6 and NEMO bootstrapping, to enable the >>> selection of a DHCPv6PD-enabled HA when the HA selection is >>> performed during the MIPv6 bootstrapping time (e.g. by extending >>> the DNS SRV lookup). >>> >>> About the text itself, for clarity I think that the section about >>> to the home link (3.4) should be merged with section 3.1 ("When >>> the MR uses DHCPv6"). >>> >>> Regards, >>> -- >>> Romain KUNTZ >>> kuntz@lsiit.u-strasbg.fr >>> Louis Pasteur University - Networks and Protocols Team >>> >>> >>> On 2008/05/30, at 16:51, marcelo bagnulo braun wrote: >>> >>>> Hi, >>>> >>>> We would like to ask the WG what is their opinion about >>>> accepting draft-droms-mext-nemo-pd-00.txt as the WG document for >>>> the Nemo PD deliverable included in our charter. >>>> >>>> Please provide comments so we cna make some progress on this >>>> long overdue deliverable >>>> >>>> thanks, Julien and marcelo >>>> -------- Mensaje original -------- >>>> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt >>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >>>> De: Internet-Drafts@ietf.org >>>> Responder a: internet-drafts@ietf.org >>>> Para: i-d-announce@ietf.org >>>> >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet- >>>> Drafts directories. >>>> >>>> Title : DHCPv6 Prefix Delegation for NEMO >>>> Author(s) : R. Droms, et al. >>>> Filename : draft-droms-mext-nemo-pd-00.txt >>>> Pages : 12 >>>> Date : 2008-05-30 >>>> >>>> One aspect of network mobility support is the assignment of a >>>> prefix >>>> or prefixes to a Mobile Router (MR) for use on the links in the >>>> Mobile Network. DHCPv6 prefix delegation can be used for this >>>> configuration task. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >>>> >>>> Content-Type: text/plain >>>> Content-ID: <2008-05-30054232.I-D@ietf.org> >>>> >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 2 04:23:54 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 380FA3A6B45; Mon, 2 Jun 2008 04:23:54 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6AEC3A6C15 for ; Mon, 2 Jun 2008 04:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKZwNnufmEdu for ; Mon, 2 Jun 2008 04:23:49 -0700 (PDT) Received: from moog.chdir.org (unknown [IPv6:2002:58bf:2aa0:339b:f654:e10e:317f:e6fa]) by core3.amsl.com (Postfix) with ESMTP id B20EF3A6B45 for ; Mon, 2 Jun 2008 04:23:48 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1K388e-0000gy-IZ; Mon, 02 Jun 2008 13:23:44 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Alexandru Petrescu In-Reply-To: <4843C335.70608@gmail.com> (Alexandru Petrescu's message of "Mon, 02 Jun 2008 11:53:57 +0200") References: <48401470.40706@it.uc3m.es> <87mym74jeu.fsf@natisbad.org> <48407564.9000209@it.uc3m.es> <87bq2n4anr.fsf@natisbad.org> <87tzgdgx90.fsf@natisbad.org> <4843C335.70608@gmail.com> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.2 (gnu/linux) X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080602:julien.ietf@laposte.net::BR1j/5eDiq18XOU8:000000000000000000000000000000000000001Wnd X-Hashcash: 1:20:080602:alexandru.petrescu@gmail.com::HSSlvaJlF+VNZNDJ:0000000000000000000000000000000002tIA X-Hashcash: 1:20:080602:mext@ietf.org::TEJWZjdGfVqnK4V7:00007J/u X-Hashcash: 1:20:080602:tsirtsis@googlemail.com::uD9fLGTVhHmvw+iU:000000000000000000000000000000000000009yDb Date: Mon, 02 Jun 2008 13:23:37 +0200 Message-ID: <87zlq4rsg6.fsf@natisbad.org> MIME-Version: 1.0 Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0599834344==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0599834344== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Hi, Alexandru Petrescu writes: > Arnaud Ebalard wrote: >> Hi George, >> >> "George Tsirtsis" writes: >> >>>> That been said, it's not because I consider that the document deserves >>>> to be WG item for that part of the audience that I think it will provi= de >>>> a "one size fits all" solution for NEMO PD, for instance for very small >>>> devices like PDA or Phones. I was basically wondering if I will ever >>>> have to install and configure a DHCPv6 server with Relay and PD support >>>> on my Phone or PDA just for the purpose of getting a prefix from my >>>> HA. But considering what you write below (hiring DHCP for the job is >>>> the consensus), this will be the case. >>>> >>> Arnaud, >>> >>> This maybe simply a misunderstanding but draft-droms does not require >>> you to do this. The Mobile Router, is a Requesting Router (RR) i.e., a >>> DHCP-PD client. So no server functionality is required in you small >>> devices. >> >> You are correct, the terms I used were not precise: I thought "daemon" >> but used "server". I should have said "DHCPv6 relay and/or DHCPv6 client >> with PD support". My point was that DHCPv6 is in all cases not a light >> requirement for small devices just for providing a prefix. > > That sounds reasonable, but what do you mean by small devices?=20 Mainly two things: =2D limited hardware (RAM, processor, storage and *battery*). =2D limited maintenance/configuration (limited user interaction or no user interaction at all) > Most if not all such small devices first things they do when they come=20 > alive is DHCP and then TCP and then HTTP. Certainly true for MN. But I think that there will be MR out there that will be deployed only to do their job: route IPv6 traffic. They will possibly come with TCP. HTTP will depend on the need. Here we just add DHCPv6 to the picture. > DHCP PD is not heavier than DHCP tout court in terms of message > numbers and size. AFAICT, my MN (the laptop this mail is sent from) does not have DHCPv6 and use DHCPv4 when needed (for teredo to bootstrap in those networks) only because there is no such thing as SLAAC for IPv4 (i.e. no other way to get an IPv4 @). Maybe current consensus of the WG is towards providing the most generic solution without considering *specifically* the scope of all the possible target platforms and their constraints but only the goal: providing a solution for NEMO PD. In the end, if some *lighter* but *more specific* solution is needed at some point, someone will probably make a draft (for instance based on the other one proposed in this thread). Hence, my support for current document as a WG item: it answers the question in the context of the consensus. Regards, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIQ9g+AlWVfAR6UCYRAg1gAJ0XdmDSSyJp/78W4kFeNZYmrbFCUwCeOW6P EhorMtilIOIRMGUvJNu1iV0= =9Q0J -----END PGP SIGNATURE----- --=-=-=-- --===============0599834344== 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://www.ietf.org/mailman/listinfo/mext --===============0599834344==-- From mext-bounces@ietf.org Mon Jun 2 04:54:14 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3CEE3A691D; Mon, 2 Jun 2008 04:54:13 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98DE43A6867 for ; Mon, 2 Jun 2008 04:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7JXNblAlztQ for ; Mon, 2 Jun 2008 04:54:11 -0700 (PDT) Received: from moog.chdir.org (unknown [IPv6:2002:58bf:2aa0:339b:f654:e10e:317f:e6fa]) by core3.amsl.com (Postfix) with ESMTP id 63E1B3A67B0 for ; Mon, 2 Jun 2008 04:54:11 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1K38c3-0000jt-BL; Mon, 02 Jun 2008 13:54:07 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Alexandru Petrescu References: <48401470.40706@it.uc3m.es> <87mym74jeu.fsf@natisbad.org> <4843C509.9010209@gmail.com> X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080602:mext@ietf.org::uvoXMm/+r9nNUw7H:00000oVl X-Hashcash: 1:20:080602:julien.ietf@laposte.net::ZHRDh0Rtz7ARPN/K:000000000000000000000000000000000000000vJs X-Hashcash: 1:20:080602:marcelo@it.uc3m.es::+T+wIOFn7WX8b2/C:00000000000000000000000000000000000000000002uAP X-Hashcash: 1:20:080602:alexandru.petrescu@gmail.com::8hpQPSNADZSaTONS:0000000000000000000000000000000006AXS Date: Mon, 02 Jun 2008 13:54:00 +0200 In-Reply-To: <4843C509.9010209@gmail.com> (Alexandru Petrescu's message of "Mon, 02 Jun 2008 12:01:45 +0200") Message-ID: <87ve0srr1j.fsf@natisbad.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0925763857==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0925763857== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Hi, Alexandru Petrescu writes: >> In practice (as a HA and MR administrator), I'd like to be able to >> simply configure the prefixes for my MR in the HA configuration section >> for this MR and that those prefixes be sent to the MR during the >> initial binding if it ask for prefix(es). In a sense considering the >> an initial static configuration of a MR, switching to PD would mean: >> >> - changing a knob in the MR config to switch to prefix delegation >> - giving the prefix in the HA config, indicating PD for that MR > > I agree. Remark that HA must already know the prefixes of MR, because > it must have them in the Prefix Table; regardless of HA using or not > PD. It's for security reasons (make sure a certain MR doesn't claim > somebody else's prefix in a BU). Yes. There are two parts in the picture: =2D how HA gets the prefixes for the MR (manual config, PD, ...) =2D how MR gets the prefix from its home netwok >> IMHO, this is a bit simplistic to delegate the security of NEMO PD to >> the Security Considerations sections of DHCPv6 and DHCPv6 PD documents. > > I mostly agree. > > It's true however that DHCPv6 PD security is bound to DHCPv6 security > overall. If one attacks DHCPv6 then one can attack DHCPv6 PD too. Clearly, I don't ask for removal of that part of the section. There are some threats to DHCPv6 and PD that apply too in NEMO context (possibly all): only clarification and extensions. i.e. my opinion is just that the content of the section is probably not sufficient. >> There are good chances that the environments where MR will operate may >> be a bit more hostile than those where more common routers are expected >> to operate (in operators or corporate networks).=20 >> >> Some initial thoughts: >> >> - What are the hypothesis behind 3315 and 3633 design decisions that do >> not hold anymore in MIPv6 environments (if any)? > > One such hypothesis is that the DHCPv6 Solicit happens between close > entities: CLient and Server are usually near each other, often same > subnet. With NEMO the MR would be far from its HA. Yes. I was under the impression (I think it is even written somewhere in the documents) that some security provided by the infrastructure in a usual [ISP] context is expected. Hence the point. >> - "HAs and MRs SHOULD use DHCPv6 authentication": Why not a "MUST"? > > Maybe because HA and MR would MUST ESP and DHCPv6 auth would be > through that ESP. If it is that, then it should probably be stated. My point was: *must* some security mechanism be used or is it optional? Which one is mandatory/preferred? When?=20 >> - how do the security mechanisms of both protocols interact? >> - In the simple mode (no relay), how will the use of multicast interact >> with IPsec protection of traffic if it is in place? >> - HMAC-MD5-based authentication method is the only one defined in >> 3315. Is it sufficient? > > Now, SHA-256 should too rfc4868 "Using HMAC-SHA-256, HMAC-SHA-384, and > HMAC-SHA-512 with IPsec". You cover all my 4 points with an IPsec argument (those 3 ones and previous one). Is that correct? If the intent of the authors is to only provide security of NEMO PD using IPsec, the security considerations section can not directly be built on top of 3315 and 3633. If not, I think my questions are still on the table.=20 >> - What is the impact of the assignment of new prefixes in a dynamic >> fashion w.r.t. the SPD and SADB or IKE daemons? How should that be >> handled. > > There may be some indeed. > > What is the available implementation of DHCPv6 PD that one could > configure on a NEMOv6 MR? It will probably depends of the platform (Linux, vendor, BSD ...) and what you want to do. Even if this is probably off-topic, AFAICT, there is at least a NEMO+IPsec/IKE implementation available (kinda) for Linux (contact me off-list for details). WIDE DHCPv6 supports PD and is available for BSD and Linux. Francis might have more information on that. For vendors, I do not know. Regards, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIQ99eAlWVfAR6UCYRAiRkAKCIg/sWuvXoZpcw1lVTH3buIybihwCfVfXK HEDLaeoXubqrPDhdsRb5NYs= =awoe -----END PGP SIGNATURE----- --=-=-=-- --===============0925763857== 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://www.ietf.org/mailman/listinfo/mext --===============0925763857==-- From mext-bounces@ietf.org Mon Jun 2 06:03:01 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18F9C3A68CE; Mon, 2 Jun 2008 06:03:01 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F04AC3A68CE for ; Mon, 2 Jun 2008 06:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9GedC0HIKy9 for ; Mon, 2 Jun 2008 06:02:54 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id D74BC3A68F1 for ; Mon, 2 Jun 2008 06:02:54 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-128.messagelabs.com!1212411766!719149!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 7510 invoked from network); 2 Jun 2008 13:02:46 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-128.messagelabs.com with SMTP; 2 Jun 2008 13:02:46 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m52D2jSJ010313 for ; Mon, 2 Jun 2008 06:02:45 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id m52D2jDQ007932 for ; Mon, 2 Jun 2008 08:02:45 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id m52D2ifH007919 for ; Mon, 2 Jun 2008 08:02:44 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Jun 2008 14:02:43 +0100 Message-ID: <4843EF72.8020104@gmail.com> Date: Mon, 02 Jun 2008 15:02:42 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Arnaud Ebalard References: <48401470.40706@it.uc3m.es> <87mym74jeu.fsf@natisbad.org> <4843C509.9010209@gmail.com> <87ve0srr1j.fsf@natisbad.org> In-Reply-To: <87ve0srr1j.fsf@natisbad.org> X-Antivirus: avast! (VPS 080531-1, 31/05/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 02 Jun 2008 13:02:43.0957 (UTC) FILETIME=[F25DA250:01C8C4B0] X-CFilter-Loop: Reflected Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Arnaud Ebalard wrote: >>> HMAC-MD5-based authentication method is the only one defined in >>> 3315. Is it sufficient? >> >> Now, SHA-256 should too rfc4868 "Using HMAC-SHA-256, HMAC-SHA-384, >> and HMAC-SHA-512 with IPsec". > > You cover all my 4 points with an IPsec argument (those 3 ones and > previous one). Is that correct? No, only the last one. >>> - how do the security mechanisms of both protocols interact? I'm wondering same. >>> - In the simple mode (no relay), how will the use of multicast >>> interact with IPsec protection of traffic if it is in place? Not sure I understand how IPsec would interact DHCPv6-PD. MIP6' IPsec protection should be up _after_ the prefix assignment phase, I think. So I suppose the prefix assignment - or PD - should happen straight multicast, not through MR-HA tunnel (contrary to droms-mext-nemo-pd "The HA and MR exchange DHCPv6PD protocol messages through the tunnel connecting them.") Or, maybe DHCPv6-PD doesn't use the multicast Solicit/Advertise and uses only the unicast Request/Reply/Confirm messages - in which case MR should discover Server's or HA's address somehow. > If the intent of the authors is to only provide security of NEMO PD > using IPsec, the security considerations section can not directly be > built on top of 3315 and 3633. If not, I think my questions are > still on the table. Well I think yes. >> What is the available implementation of DHCPv6 PD that one could >> configure on a NEMOv6 MR? > > It will probably depends of the platform (Linux, vendor, BSD ...) and > what you want to do. Even if this is probably off-topic, AFAICT, > there is at least a NEMO+IPsec/IKE implementation available (kinda) > for Linux (contact me off-list for details). WIDE DHCPv6 supports PD > and is available for BSD and Linux. Francis might have more > information on that. For vendors, I do not know. DHCPv6-PD implementation for Linux - where? 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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 2 06:44:38 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E6C928C0E7; Mon, 2 Jun 2008 06:44:38 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C183A6B24 for ; Mon, 2 Jun 2008 06:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5GBVfn1cB8L for ; Mon, 2 Jun 2008 06:44:34 -0700 (PDT) Received: from moog.chdir.org (unknown [IPv6:2002:58bf:2aa0:339b:f654:e10e:317f:e6fa]) by core3.amsl.com (Postfix) with ESMTP id 326193A6977 for ; Mon, 2 Jun 2008 06:44:34 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1K3AKu-0004n1-EM; Mon, 02 Jun 2008 15:44:32 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Alexandru Petrescu References: <48401470.40706@it.uc3m.es> <87mym74jeu.fsf@natisbad.org> <4843C509.9010209@gmail.com> <87ve0srr1j.fsf@natisbad.org> <4843EF72.8020104@gmail.com> X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080602:mext@ietf.org::HxBUWYPOgDxuaZJK:000010gS X-Hashcash: 1:20:080602:alexandru.petrescu@gmail.com::+H1MVoc+pisXVlyz:0000000000000000000000000000000001lTr X-Hashcash: 1:20:080602:julien.ietf@laposte.net::K1xv0iS/QHpvIARj:000000000000000000000000000000000000002OSV X-Hashcash: 1:20:080602:marcelo@it.uc3m.es::tFe28WYeVSGH2ARn:0000000000000000000000000000000000000000000A987 Date: Mon, 02 Jun 2008 15:44:26 +0200 In-Reply-To: <4843EF72.8020104@gmail.com> (Alexandru Petrescu's message of "Mon, 02 Jun 2008 15:02:42 +0200") Message-ID: <87r6bgrlxh.fsf@natisbad.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1103057641==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1103057641== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Hi, Alexandru Petrescu writes: >>>> - In the simple mode (no relay), how will the use of multicast >>>> interact with IPsec protection of traffic if it is in place? > > Not sure I understand how IPsec would interact DHCPv6-PD. Possibly for: =2D protection of the DHCPv6 flows themselves =2D protection of flows routed by the MR which use the newly acquired prefix.=20 > MIP6' IPsec protection should be up _after_ the prefix assignment > phase, I think.=20 I would say *before* (DHCPv6 traffic will possibly trigger IKE nego or be the first to use existing SA protecting data traffic) but I will let the authors comment on how things should/could happen.=20 > So I suppose the prefix assignment - or PD - should > happen straight multicast, not through MR-HA tunnel (contrary to > droms-mext-nemo-pd "The HA and MR exchange DHCPv6PD protocol messages > through the tunnel connecting them.") > > Or, maybe DHCPv6-PD doesn't use the multicast Solicit/Advertise and > uses only the unicast Request/Reply/Confirm messages - in which case > MR should discover Server's or HA's address somehow. AFAICT, this is not covered yet. >> If the intent of the authors is to only provide security of NEMO PD >> using IPsec, the security considerations section can not directly be >> built on top of 3315 and 3633. If not, I think my questions are >> still on the table. > > Well I think yes. ok. >>> What is the available implementation of DHCPv6 PD that one could >>> configure on a NEMOv6 MR? >> >> It will probably depends of the platform (Linux, vendor, BSD ...) and >> what you want to do. Even if this is probably off-topic, AFAICT, >> there is at least a NEMO+IPsec/IKE implementation available (kinda) >> for Linux (contact me off-list for details). WIDE DHCPv6 supports PD >> and is available for BSD and Linux. Francis might have more >> information on that. For vendors, I do not know. > > DHCPv6-PD implementation for Linux - where? Packages are is wide-dhcpv6-{server, client, relay} under Debian. Support might be partial, you will have to look at the man pages. The project is on sourceforge (wide-dhcpv6). Regards, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIQ/k+AlWVfAR6UCYRAkjMAJ0TpXbvirOhAsNpqLhAJ1hTNCwIVwCfZac7 kZFyO0M1mT0vbLE+zMhiQvE= =YWIA -----END PGP SIGNATURE----- --=-=-=-- --===============1103057641== 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://www.ietf.org/mailman/listinfo/mext --===============1103057641==-- From mext-bounces@ietf.org Mon Jun 2 08:18:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B26343A6AB1; Mon, 2 Jun 2008 08:18:12 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E12523A69F8 for ; Mon, 2 Jun 2008 08:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOYQT8I0j6fB for ; Mon, 2 Jun 2008 08:18:10 -0700 (PDT) Received: from web84310.mail.re1.yahoo.com (web84310.mail.re1.yahoo.com [69.147.74.189]) by core3.amsl.com (Postfix) with SMTP id BA0553A69F7 for ; Mon, 2 Jun 2008 08:18:09 -0700 (PDT) Received: (qmail 69555 invoked by uid 60001); 2 Jun 2008 15:18:10 -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=t2y7JWl/8kIYXXVBgvsAhREHLSpGPoxwZClqhSbZQqR6H0Cs4lohB2G+HZMV6UrhcsWJYUm78UZe5GwSTFkNIMmGh227g6PqTeOWDRdRToqdkAk2lCt4LBsC1sNLRpHYb4mR2KEbKx7+yhzhPP+Ztpy5wJSJyWaI31rWCTT/SOk=; X-YMail-OSG: wptOEb4VM1kLgh__EtUxImqsizIz7zfOXcS6iNuglikzMqhg9Vc7FWvf41H79zel9vlPiCga819a9jJKP7DPeh2uHpUWVH0a0pj_FeUah7q4n6hCqJkZG59WAXM- Received: from [206.16.17.212] by web84310.mail.re1.yahoo.com via HTTP; Mon, 02 Jun 2008 08:18:10 PDT X-Mailer: YahooMailRC/975.41 YahooMailWebService/0.7.185 Date: Mon, 2 Jun 2008 08:18:10 -0700 (PDT) From: Behcet Sarikaya To: Romain KUNTZ MIME-Version: 1.0 Message-ID: <742376.69109.qm@web84310.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 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="===============1401462484==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1401462484== Content-Type: multipart/alternative; boundary="0-1417795276-1212419890=:69109" --0-1417795276-1212419890=:69109 Content-Type: text/plain; charset=us-ascii Hi Romain, Please see inline. Regards, Behcet ----- Original Message ---- From: Romain KUNTZ To: Behcet Sarikaya Cc: mext@ietf.org Sent: Sunday, June 1, 2008 6:08:19 PM Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Hi, On 2008/05/31, at 0:13, Behcet Sarikaya wrote: I think this is a good point, we should not hurry up a solution just because it was long overdue. I have the same concern. Instead of MR, HA could be a better place for DHCP PD. http://tools.ietf.org/id/draft-sarikaya-mext-prefix-delegation-00.txt explains this and it is a much simpler document. I think this document is a companion document to draft-ietf-nemo-prefix-delegation-02, which is based on the MIPv6 signaling (BU/BA) between the MR and the HA for prefix delegation. If I understand well, your document tells how to provision the HA with a list of prefixes, but in the end the MIPv6 signaling is used to delegate a prefix to the MR. This is different from what is proposed in draft-droms-mext-nemo-pd which uses DHCP in all the prefix delegation process. [behcet] You are right. I claim that from MR complexity point of view BU/BA signaling leads to a simpler solution. Also BU/BA guarantees that MR registration with HA is valid at the times of prefix provisioning, this is a big plus. As DHCP already got the consensus of the WG, that would be better to not debate again on "DHCP versus MIP6 signaling". [behcet] I was in the room when consensus call was made. The call was if the floor agrees with the use of DHCPv6 PD but did not specify from MR or from HA. So the consensus applies to my document as well which proposes to use DHCPv6 PD from HA. I mentioned this to the chair on a face to face meeting after the session. --0-1417795276-1212419890=:69109 Content-Type: text/html; charset=us-ascii
Hi Romain,
  Please see inline.

Regards,

Behcet
----- Original Message ----
From: Romain KUNTZ <kuntz@lsiit.u-strasbg.fr>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: mext@ietf.org
Sent: Sunday, June 1, 2008 6:08:19 PM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

Hi,

On 2008/05/31, at 0:13, Behcet Sarikaya wrote:
I think this is a good point, we should not hurry up a solution just because it was long overdue.
I have the same concern. Instead of MR, HA could be a better place for DHCP PD. 
http://tools.ietf.org/id/draft-sarikaya-mext-prefix-delegation-00.txt explains this and it is a much simpler document.

I think this document is a companion document to draft-ietf-nemo-prefix-delegation-02, which is based on the MIPv6 signaling (BU/BA) between the MR and the HA for prefix delegation. If I understand well, your document tells how to provision the HA with a list of prefixes, but in the end the MIPv6 signaling is used to delegate a prefix to the MR. This is different from what is proposed in draft-droms-mext-nemo-pd which uses DHCP in all the prefix delegation process. 
[behcet] You are right. I claim that from MR complexity point of view BU/BA signaling leads to a simpler solution. Also BU/BA  guarantees that MR registration with HA is valid at the times of prefix provisioning, this is a big plus.

As DHCP already got the consensus of the WG, that would be better to not debate again on "DHCP versus MIP6 signaling".

[behcet] I was in the room when consensus call was made. The call was if the floor agrees with the use of DHCPv6 PD but did not specify from MR or from HA.
So the consensus applies to my document as well which proposes to use DHCPv6 PD from HA.
I mentioned this to the chair on a face to face meeting after the session.

--0-1417795276-1212419890=:69109-- --===============1401462484== 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://www.ietf.org/mailman/listinfo/mext --===============1401462484==-- From mext-bounces@ietf.org Mon Jun 2 11:59:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFEDE3A6960; Mon, 2 Jun 2008 11:59:38 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2583A6960 for ; Mon, 2 Jun 2008 11:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oULGnSQ1faLw for ; Mon, 2 Jun 2008 11:59:34 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id D9F753A691B for ; Mon, 2 Jun 2008 11:59:33 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 67ACA198771; Mon, 2 Jun 2008 21:59:34 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 640A7198719; Mon, 2 Jun 2008 21:59:33 +0300 (EEST) Message-ID: <48444315.1030602@piuha.net> Date: Mon, 02 Jun 2008 14:59:33 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Alexandru Petrescu References: <4843B64E.8040307@it.uc3m.es> <4843C104.3030706@gmail.com> In-Reply-To: <4843C104.3030706@gmail.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: charliep@computer.org, Julien Laganier , mext@ietf.org Subject: Re: [MEXT] TC/flow label copying X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I'm not sure copying text from already normatively referenced documents is going to change the situation. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 2 15:37:43 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197E23A67A5; Mon, 2 Jun 2008 15:37:43 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C5D03A67A5 for ; Mon, 2 Jun 2008 15:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1i-N3ZvbbeIQ for ; Mon, 2 Jun 2008 15:37:40 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id 89BF23A6783 for ; Mon, 2 Jun 2008 15:37:40 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m52MbeK3064144; Tue, 3 Jun 2008 00:37:40 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200806022237.m52MbeK3064144@givry.fdupont.fr> From: Francis Dupont To: Alexandru Petrescu In-reply-to: Your message of Mon, 02 Jun 2008 11:51:59 +0200. <4843C2BF.1030302@gmail.com> Date: Tue, 03 Jun 2008 00:37:40 +0200 Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org In your previous mail you wrote: It's a bad idea to not extend DHAAD. => or DHAAD is a bad idea (:-)? It's a bad idea to extend DNS for discovering stuff. DNS is not for discovery. => RFC 2782 (aka DNS SRV RR) is enough used to prove you are wrong. Regards Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 2 15:41:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A1BE3A68D1; Mon, 2 Jun 2008 15:41:47 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7254A3A6906 for ; Mon, 2 Jun 2008 15:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGkXBvEgzgHs for ; Mon, 2 Jun 2008 15:41:45 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id 15C163A6A81 for ; Mon, 2 Jun 2008 15:41:02 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m52Mf3ks064163; Tue, 3 Jun 2008 00:41:03 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200806022241.m52Mf3ks064163@givry.fdupont.fr> From: Francis Dupont To: Alexandru Petrescu In-reply-to: Your message of Mon, 02 Jun 2008 11:53:57 +0200. <4843C335.70608@gmail.com> Date: Tue, 03 Jun 2008 00:41:03 +0200 Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org In your previous mail you wrote: DHCP PD is not heavier than DHCP tout court in terms of message numbers and size. => in fact it is smaller (i.e., a PD only client is smaller) and BTW PD doesn't use some messages (Confirm and Decline). Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 2 15:56:42 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD093A67A1; Mon, 2 Jun 2008 15:56:42 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453CD3A6A8A for ; Mon, 2 Jun 2008 15:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2N6gLAmuQ2HI for ; Mon, 2 Jun 2008 15:56:40 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id B69F93A67B3 for ; Mon, 2 Jun 2008 15:55:24 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m52MtMS1064267; Tue, 3 Jun 2008 00:55:22 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200806022255.m52MtMS1064267@givry.fdupont.fr> From: Francis Dupont To: Alexandru Petrescu In-reply-to: Your message of Mon, 02 Jun 2008 15:02:42 +0200. <4843EF72.8020104@gmail.com> Date: Tue, 03 Jun 2008 00:55:22 +0200 Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org In your previous mail you wrote: Or, maybe DHCPv6-PD doesn't use the multicast Solicit/Advertise and uses only the unicast Request/Reply/Confirm messages - in which case MR should discover Server's or HA's address somehow. => this is not possible (to use only the unicast Request/Reply/Confirm messages), this is why I introduced the DHCPv6 relay agent to use only unicast Relay-Forw/Relay-Reply... DHCPv6-PD implementation for Linux - where? => at the last DHCPv6 bake-off there were many PD implementations and most of them ran on Linux (or BSD or both)... Regards Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 2 18:28:17 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C4CD3A6B24; Mon, 2 Jun 2008 18:28:17 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78633A6B09 for ; Mon, 2 Jun 2008 18:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OPtpNo-pbGc for ; Mon, 2 Jun 2008 18:28:15 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 617143A6B69 for ; Mon, 2 Jun 2008 18:28:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Jun 2008 13:46:31 -0400 Message-ID: In-Reply-To: <4843C104.3030706@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] TC/flow label copying (was: RFC3775 update) Thread-Index: AcjElWSd1wqvzmxlQXSVc8TDNFgV9AAQmocw References: <4843B64E.8040307@it.uc3m.es> <4843C104.3030706@gmail.com> From: "Vijay Devarapalli" To: "Alexandru Petrescu" , "marcelo bagnulo braun" Cc: charliep@computer.org, mext@ietf.org, Jari Arkko , Julien Laganier Subject: Re: [MEXT] TC/flow label copying (was: RFC3775 update) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alex, I think this should be addressed as part of updating RFC 2473. (there was some discussion on the INT Area mailing list on updating RFC 2473). PMIPv6, FMIPv6, HMIPv6, all use tunneling. They all refer to RFC 2473. What you bring up below would be applicable to all these protocols as well. So we shouldn't make changes to how encapsulation/decapsulation is done in 3775bis. Vijay > Hi Marcelo, I'm not sure whether this has been discussed or not. > > rfc3775 is silent about HA copying or ignoring the Trafic > Class and Flow > Label fields when de/encapsulating from/to MN. It can prove to be an > issue when using that field. In some implementations the field _is_ > copied, which is a good thing IMHO. > > On this topic, rfc3775 points to rfc2473 ("Generic Packet > Tunneling in > IPv6") which further says "Depending on the entry-point node tunnel > configuration, the [flow label]/traffic class can be set to that of > either the original packet or a pre-configured value." > > In practice however, many implementations of rfc2473 don't > have a means > to set a pre-configured value for the traffic class/flow > label. This is > something relatively difficult to implement because it's difficult to > link a set of parameters into a pre-configured traffic > class/flow label: > What does a pre-configured traffic class/flow label correspond to: a > pair of IP addresses? port numbers? etc. > > On this reasoning, I prefer 3775 to say that the HA must > either copy the > traffic class/flow label, or set it to 0. > > Just say a good recommendation instead of relying on rfc2473 > unimplemented means of this behaviour. > > Alex > > marcelo bagnulo braun wrote: > > Hi, > > > > In last IETF we said that we will accept input for RFC3775 > changes for > > about 3 months and then try to wrap up this issues. > > > > This is reminder of that plan and that proposals for > changes for RFC3775 > > are accepted till the 15 of june. > > > > After that we will go through the proposed changes and try to reach > > consensus on each of the proposed changes (including the text to be > > included and removed) in the ml. > > > > After that we will ask the authors of rfc3775 to submit a 3775bis > > including the accepted changes and go to WGLC. > > > > Regards, Julien and marcelo > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.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://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 2 19:38:14 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 277493A6AB4; Mon, 2 Jun 2008 19:38:14 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64C053A69DD for ; Mon, 2 Jun 2008 19:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwO2A+KQxKHh for ; Mon, 2 Jun 2008 19:38:12 -0700 (PDT) Received: from web84312.mail.re1.yahoo.com (web84312.mail.re1.yahoo.com [69.147.74.191]) by core3.amsl.com (Postfix) with SMTP id 1980F3A6BEC for ; Mon, 2 Jun 2008 19:37:57 -0700 (PDT) Received: (qmail 11076 invoked by uid 60001); 3 Jun 2008 02:37:59 -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=sT3AQhz6eLHLZJm1QQYKmBsjDybalahe55mqeAixgiy5UXWAWFt1sjfcXGrCTn8AVP2lD08Fz7BI657P5R/WxzsyutMFZ98ebIew6ycX69l7TJaLK6lFKiAu1IibatJXFymch/c6feN36oymAVPoc5M+5Pn/3keuKWPq8VOOHC4=; X-YMail-OSG: G5PP5C4VM1nVmA5jBxA2Cd9OoTvsZ6bKZB1MHq8R.o3_8CyYNPn4gvZKaok6lo7Agg-- Received: from [71.252.164.196] by web84312.mail.re1.yahoo.com via HTTP; Mon, 02 Jun 2008 19:37:59 PDT X-Mailer: YahooMailRC/975.41 YahooMailWebService/0.7.185 Date: Mon, 2 Jun 2008 19:37:59 -0700 (PDT) From: Behcet Sarikaya To: Francis Dupont MIME-Version: 1.0 Message-ID: <582780.8185.qm@web84312.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 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="===============0485237274==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0485237274== Content-Type: multipart/alternative; boundary="0-1797964466-1212460679=:8185" --0-1797964466-1212460679=:8185 Content-Type: text/plain; charset=us-ascii My comments below. Regards, Behcet ----- Original Message ---- From: Francis Dupont To: Alexandru Petrescu Cc: Julien Laganier ; mext@ietf.org Sent: Monday, June 2, 2008 5:55:22 PM Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? In your previous mail you wrote: Or, maybe DHCPv6-PD doesn't use the multicast Solicit/Advertise and uses only the unicast Request/Reply/Confirm messages - in which case MR should discover Server's or HA's address somehow. => this is not possible (to use only the unicast Request/Reply/Confirm messages), this is why I introduced the DHCPv6 relay agent to use only unicast Relay-Forw/Relay-Reply... [behcet] This is correct. Previous version of this draft was using DHCP Client to do DHCPv6 PD and people said (I think Ryuji it was) this can not work because you are not on link, these messages are going far away to the HA. Then Francis' draft came to the rescue with the Relay Agent idea. However what I would like to point out is that the main idea of this draft and its previous versions is since MR is a router, let MR be the requesting router in DHCPv6 PD. I think that was flawed. MR is a router but it is also an MN, its upstream link is wireless and MR is moving. It needs to establish and maintain MR-HA tunnel. Now, running DHCPv6 PD under these conditions is unprecedented. What the authors of the previous versions missed is the fact that this was not the only way to do DHCPv6 PD under these circumstances. --0-1797964466-1212460679=:8185 Content-Type: text/html; charset=us-ascii
My comments below.

Regards,

Behcet

----- Original Message ----
From: Francis Dupont <Francis.Dupont@fdupont.fr>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Cc: Julien Laganier <julien.IETF@laposte.net>; mext@ietf.org
Sent: Monday, June 2, 2008 5:55:22 PM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

In your previous mail you wrote:

  Or, maybe DHCPv6-PD doesn't use the multicast Solicit/Advertise and uses
  only the unicast Request/Reply/Confirm messages - in which case MR
  should discover Server's or HA's address somehow.
 
=> this is not possible (to use only the unicast Request/Reply/Confirm
messages), this is why I introduced the DHCPv6 relay agent to use
only unicast Relay-Forw/Relay-Reply...

[behcet] This is correct. Previous version of this draft was using DHCP Client to do DHCPv6 PD and people said (I think Ryuji it was) this can not work because you are not on link, these messages are going far away to the HA.
Then Francis' draft came to the rescue with the Relay Agent idea.
  However what I would like to point out is that the main idea of this draft and its previous versions is since MR is a router, let MR be the requesting router in DHCPv6 PD. I think that was flawed. MR is a router but it is also an MN, its upstream link is wireless and MR is moving. It needs to establish and maintain MR-HA tunnel. Now, running DHCPv6 PD under these conditions is unprecedented.
  What the authors of the previous versions missed is the fact that this was not the only way to do DHCPv6 PD under these circumstances.



--0-1797964466-1212460679=:8185-- --===============0485237274== 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://www.ietf.org/mailman/listinfo/mext --===============0485237274==-- From mext-bounces@ietf.org Mon Jun 2 19:58:24 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 938843A6893; Mon, 2 Jun 2008 19:58:24 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6879D3A6893 for ; Mon, 2 Jun 2008 19:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaaZfl0Lo5LT for ; Mon, 2 Jun 2008 19:58:22 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5D5B73A6836 for ; Mon, 2 Jun 2008 19:58:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,581,1204531200"; d="scan'208";a="30101919" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 02 Jun 2008 19:58:22 -0700 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 m532wMMP004797; Mon, 2 Jun 2008 19:58:22 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m532wMYg003653; Tue, 3 Jun 2008 02:58:22 GMT Date: Mon, 2 Jun 2008 19:58:22 -0700 (PDT) From: Sri Gundavelli To: Vijay Devarapalli In-Reply-To: Message-ID: References: <4843B64E.8040307@it.uc3m.es> <4843C104.3030706@gmail.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=865; t=1212461902; x=1213325902; 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]=20TC/flow=20label=20copying=20(w as=3A=20=20RFC3775=20update) |Sender:=20; bh=WiNWEUF47DgvQaK6Q0cOAsJorKZ5LNL/qrkpcn5lHgg=; b=cdTvayExA37vAvJDkmNNmWbfH79G5XQIDwhI1np2HiB1yQN9GlaabP9f2L q62FgaHkIe+nP/kEMZiEEf/GgaBRguEd2fjdEBgPN6LD5ciqkxqLyQMLr/EU fbOX5e9UTd; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: charliep@computer.org, Jari Arkko , mext@ietf.org, Julien Laganier Subject: Re: [MEXT] TC/flow label copying (was: RFC3775 update) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Just one comment. On Mon, 2 Jun 2008, Vijay Devarapalli wrote: > > PMIPv6, FMIPv6, HMIPv6, all use tunneling. They all refer to RFC 2473. > What you bring up below would be applicable to all these protocols as > well. So we shouldn't make changes to how encapsulation/decapsulation is > done in 3775bis. The transport AD did not agree with this stand and we ended up specifying the ECN handling for the PMIP tunnels. But, thats a new spec. If we make the tunnel normative to 3168 specification, we can just state on the ECN copying and leave it there. DSMIP spec also seems to have done that. Unless you see an issue with this addition of what is missing in 2473, we can probably specify this. In any case, the same will get added to 2473-bis, normative to 3168. But again, 3775-bis is a simple update, some what an error correction. Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 2 20:36:55 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B6D33A682B; Mon, 2 Jun 2008 20:36:55 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8AA73A682B for ; Mon, 2 Jun 2008 20:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GTuO-RR9zDu for ; Mon, 2 Jun 2008 20:36:53 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 027CC3A67A3 for ; Mon, 2 Jun 2008 20:36:52 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1163910wfd.31 for ; Mon, 02 Jun 2008 20:36:53 -0700 (PDT) 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=e86LC3yvgUCHftb/cYUqWxvaChDLYpP4yzSqci89moc=; b=v60zCkEEzXkIgceJPhsqBCZAp5t1nt9zY5YrylNHMBJCDw+u8EAiKtBdHCclLq6ODYVfT2QSAjLUZ1RibMsEgViJZtQcQBci1XJ62EOKmBBx0JR9qHzdmUl+woD6uTtH4QsMJ/1BuQ4KIHOzidStWvivXYkAX9M1XMNmwJwQFQw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Uc3EbSrLeXECkfzmVgLJQtRPrmhJ/ocX6ufXZcH36QvNbIlDT1s/wh7krHlVL7ZsB04PKqQC1asiq6bV0XRS3kheoybvFCLr461ZiiPUltY0UNp/SsSrftrk2ZEakS0iVvu/Sx9O/AjESGEa5D2KBLPNDfXa7cT/YJQkcWfNtdo= Received: by 10.142.232.20 with SMTP id e20mr1312601wfh.237.1212464212960; Mon, 02 Jun 2008 20:36:52 -0700 (PDT) Received: by 10.142.200.13 with HTTP; Mon, 2 Jun 2008 20:36:52 -0700 (PDT) Message-ID: Date: Mon, 2 Jun 2008 20:36:52 -0700 From: "Vijay Devarapallli" To: "Sri Gundavelli" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <4843B64E.8040307@it.uc3m.es> <4843C104.3030706@gmail.com> Cc: charliep@computer.org, Julien Laganier , Jari Arkko , mext@ietf.org Subject: Re: [MEXT] TC/flow label copying (was: RFC3775 update) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Mon, Jun 2, 2008 at 7:58 PM, Sri Gundavelli wrote: > Just one comment. > > > > On Mon, 2 Jun 2008, Vijay Devarapalli wrote: >> >> PMIPv6, FMIPv6, HMIPv6, all use tunneling. They all refer to RFC 2473. >> What you bring up below would be applicable to all these protocols as >> well. So we shouldn't make changes to how encapsulation/decapsulation is >> done in 3775bis. > > The transport AD did not agree with this stand and we ended up > specifying the ECN handling for the PMIP tunnels. But, thats a > new spec. It was more of a procedural issue. I am sure you didn't want PMIPv6 approval held up until 2473bis was done. :) Vijay If we make the tunnel normative to 3168 specification, > we can just state on the ECN copying and leave it there. DSMIP > spec also seems to have done that. Unless you see an issue with > this addition of what is missing in 2473, we can probably specify > this. In any case, the same will get added to 2473-bis, normative > to 3168. But again, 3775-bis is a simple update, some what an > error correction. > > Sri > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 2 20:52:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D6F23A68C4; Mon, 2 Jun 2008 20:52:47 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D8F03A68C4 for ; Mon, 2 Jun 2008 20:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EI0MTE+SwZ-s for ; Mon, 2 Jun 2008 20:52:45 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 4D9743A686C for ; Mon, 2 Jun 2008 20:52:44 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id A67B51987F6; Tue, 3 Jun 2008 06:52:45 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 08CBC198772; Tue, 3 Jun 2008 06:52:32 +0300 (EEST) Message-ID: <4844BFFE.9020005@piuha.net> Date: Mon, 02 Jun 2008 23:52:30 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Sri Gundavelli References: <4843B64E.8040307@it.uc3m.es> <4843C104.3030706@gmail.com> In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: charliep@computer.org, mext@ietf.org, Julien Laganier Subject: Re: [MEXT] TC/flow label copying X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Sri, > The transport AD did not agree with this stand and we ended up > specifying the ECN handling for the PMIP tunnels. I think there are several different cases: 1) The referenced spec does have the needed words 2) The referenced spec does not have the needed words 3) The referenced spec has the words, but the referring spec needs further details 4) The referenced spec has the words, but its important to highlight the issue for some reason 5) ... I don't think its necessary to add any explanation for case 1. In other cases, it may be needed. Like Netlmm, I think we were mostly in items 2 and 3. But what I understood from Alex we had case 1 here. I have not checked the RFC recently, however... Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 00:53:08 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067B728C11E; Tue, 3 Jun 2008 00:53:08 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 884A43A69CF for ; Tue, 3 Jun 2008 00:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gs54C9yymjJI for ; Tue, 3 Jun 2008 00:53:06 -0700 (PDT) Received: from moog.chdir.org (unknown [IPv6:2002:58bf:2aa0:339b:f654:e10e:317f:e6fa]) by core3.amsl.com (Postfix) with ESMTP id A5B2028C150 for ; Tue, 3 Jun 2008 00:51:51 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1K3RJ8-000516-VV; Tue, 03 Jun 2008 09:51:51 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Francis Dupont References: <200806022225.m52MP8So064030@givry.fdupont.fr> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.2 (gnu/linux) X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080603:francis.dupont@fdupont.fr::KTDJkkF4FQvyXNqa:0000000000000000000000000000000000000xRS X-Hashcash: 1:20:080603:julien.ietf@laposte.net::gGE/7VAfw4DypIOr:000000000000000000000000000000000000001UiG X-Hashcash: 1:20:080603:marcelo@it.uc3m.es::3rAAD195r2zynsDf:000000000000000000000000000000000000000000035YP X-Hashcash: 1:20:080603:mext@ietf.org::ioz+j0nSLpe07Hdq:00004hXg Date: Tue, 03 Jun 2008 09:51:43 +0200 Message-ID: <87ej7f3qi8.fsf@natisbad.org> MIME-Version: 1.0 Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0705252685==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0705252685== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Hi Francis, Francis Dupont writes: > In your previous mail you wrote: > > On the other side, I wonder if it is not overkill > (complexity, roundtrips, ...) for a use in small devices (phone?, PDA?) > that will serve a single subnet with IPv6 stateless @ autoconf=3D20 >=20=20=20=20 > =3D> I believe you are talking about MRs so as the DHCPv6 use (and support > requirement) is at the initiative of the client/MR there is no issue: Yes, I am talking about MR. For HA, I see no possible issue regarding the implementation of DHCPv6 given their environment and expected capabilities: as router, they will most probably come with it anyway. > simply don't use it (and don't support it) on pico devices. ;-) > =3D> in fact I think the opposite: the critical parts will be protected, > for instance the MR-HA tunnel protected by ESP for all packets. >=20=20=20=20 > [...] > > * "HAs and MRs SHOULD use DHCPv6 authentication": Why not a "MUST"? > > =3D> mainly because there are better ways and when they are used the > weak DHCPv6 authentication is useless (or worse). > > * how do the security mechanisms of both protocols interact? > > =3D> badly! > > * In the simple mode (no relay), how will the use of multicast interact > with IPsec protection of traffic if it is in place? > > =3D> this is an IPsec issue. When IPsec protects all packets multicast > doesn't matter. > > * What is the impact of the assignment of new prefixes in a dynamic > fashion w.r.t. the SPD and SADB or IKE daemons? How should that be > handled. >=20=20=20=20 > =3D> irrelevant and BTW there is simple solution if IPsec is applied > to all packets in the MR-HA tunnel. If both protocols interact badly and IPsec is the best way to protect DHCPv6 traffic, then the Security Consideration section definitely needs to clarify that. What do you think? Thanks, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIRPgUAlWVfAR6UCYRAkSSAJ9zyT9sZtOTS9zKMnG8hjTGTZbBjgCgiFQx t/21jPobRlS5OHZDQLeMoJE= =KbqM -----END PGP SIGNATURE----- --=-=-=-- --===============0705252685== 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://www.ietf.org/mailman/listinfo/mext --===============0705252685==-- From mext-bounces@ietf.org Tue Jun 3 00:54:24 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAA6728C0E1; Tue, 3 Jun 2008 00:54:24 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25A73A69CF for ; Tue, 3 Jun 2008 00:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11eMYFE8dHRP for ; Tue, 3 Jun 2008 00:54:21 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by core3.amsl.com (Postfix) with ESMTP id 668433A68AB for ; Tue, 3 Jun 2008 00:54:21 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id i29so993247wxd.31 for ; Tue, 03 Jun 2008 00:54:19 -0700 (PDT) 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=y8KaYgQBoKJSV3blRjc3H7hRlT4ORKaL4odG3IhmUUo=; b=SVB7STMWmMzRd4n3waw7STLmj8KGogQHgT7bEfh1bBAxcpGpw0X/SThERE6+Ot/Krp5vDShtRMNkvd3Zi2CSP9PY1+Wa0FLyRNGJD3CyAA1URcEqKAKhy04p01y3dAEs0A+qf+pxNl3mKtkq5GjmkzTj6fwfw+C6XnI9OThAYLA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=ELxrwGRqVxqq3lwS3px+19OxT77OX8S7py2og4CP1TM3lsxJ7TKT6jlogwFzlXMCCCYJTx/vZyMagnDIP6vMYb+qA+tx8bWhIm9YdCB0ft2S1zi1XcyRy59I6mkCl9x5+yPQVthT9Fb/qH8dM0cjl3JOU9KRjjJu3g5bRnyARM8= Received: by 10.90.25.11 with SMTP id 11mr12773881agy.102.1212479659278; Tue, 03 Jun 2008 00:54:19 -0700 (PDT) Received: from 113-3.life.jp.interop.net ( [45.8.3.113]) by mx.google.com with ESMTPS id c44sm2547041hsc.8.2008.06.03.00.54.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Jun 2008 00:54:17 -0700 (PDT) From: Ryuji Wakikawa To: marcelo bagnulo braun In-Reply-To: <48401470.40706@it.uc3m.es> References: <48401470.40706@it.uc3m.es> Message-Id: Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 3 Jun 2008 16:54:12 +0900 X-Mailer: Apple Mail (2.924) Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, I agree to accept this as WG doc. I also agree with Romain and Vijay. We don't need extension to DHAAD. Since MR can act as MN, MR should be able to bootstrap with the same mechanism of MIP (except for PD). We should not bring DHAAD back in the bootstrap process only for PD. regards, ryuji On 2008/05/30, at 23:51, marcelo bagnulo braun wrote: > Hi, > > We would like to ask the WG what is their opinion about accepting > draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD > deliverable included in our charter. > > Please provide comments so we cna make some progress on this long > overdue deliverable > > thanks, Julien and marcelo > -------- Mensaje original -------- > Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt > Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) > De: Internet-Drafts@ietf.org > Responder a: internet-drafts@ietf.org > Para: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : DHCPv6 Prefix Delegation for NEMO > Author(s) : R. Droms, et al. > Filename : draft-droms-mext-nemo-pd-00.txt > Pages : 12 > Date : 2008-05-30 > > One aspect of network mobility support is the assignment of a prefix > or prefixes to a Mobile Router (MR) for use on the links in the > Mobile Network. DHCPv6 prefix delegation can be used for this > configuration task. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > Content-Type: text/plain > Content-ID: <2008-05-30054232.I-D@ietf.org> > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 01:02:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7153C3A6BF2; Tue, 3 Jun 2008 01:02:21 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CEE13A6B4A for ; Tue, 3 Jun 2008 01:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.112 X-Spam-Level: X-Spam-Status: No, score=-6.112 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57KUCSS9M5um for ; Tue, 3 Jun 2008 01:01:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BB3893A6BEC for ; Tue, 3 Jun 2008 01:00:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,582,1204498800"; d="scan'208";a="10577833" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Jun 2008 10:00:30 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5380Ud8011224; Tue, 3 Jun 2008 10:00:30 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5380UBe005238; Tue, 3 Jun 2008 08:00:30 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, 3 Jun 2008 10:00:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Jun 2008 09:59:55 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05C0F035@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Thread-Index: AcjEOx0fCdV7crzCR9+DSKow/yF0RAAFWLiQAD7Yl1A= References: <48401470.40706@it.uc3m.es><7E43E173-9E24-4023-9BBE-07BE33BC5B7E@lsiit.u-strasbg.fr> From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Romain KUNTZ" , "marcelo bagnulo braun" X-OriginalArrivalTime: 03 Jun 2008 08:00:30.0050 (UTC) FILETIME=[E420C420:01C8C54F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5592; t=1212480030; x=1213344030; 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]=20Adoption=20of=20draft-droms-me xt-nemo-pd-00.txt? |Sender:=20; bh=hi5uYbSWoWJPinFUuPGQQA9ubC/Jhm6lsLNg5edHFYc=; b=KytuYSGT/5q6m6q/CW7k/0wgrsoMAEo6WBZe67lqlya8mtWClqlaxM+DYx L7eDK9pmdTDqelVixJqQfORgfyIqMvtR/3GoHQlPd6Gj7I3wiWEYsRGDbmVD EiWZ9jai6z; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay: Allow me to disagree. I'm not trying to challenge whether DHAAD is 'good' or 'bad'. Simply, it is the mechanism we have and we want to be consistent between our specs. If you can convince this group that DHAAD should be obsoleted, then we'll rev RFC 3775, 3963 and the PD work altogether and in a consistent manner. >IMO, we should remove the extensions to DHAAD from this document. It's a >bad idea to keep extending DHAAD every time we add an extension to >MIPv6. [Pascal] Why not? We do not have so many extensions in the charter and prefix delegation is a much needed and quite major one. DHAAD is exactly designed for the purpose at hand and the use in the PD draft is homogeneous with the use in RFC 3963. >We could extend DNS-based HA lookup for discovering a home agent that is >capable of NEMO prefix delegation. But I think this is also unnecessary. [Pascal] I think that Prefix Delegation can and should be a simple extension to complete the explicit and implicit modes on a NEMO MR. There's no necessity to prerequire support for the MIP bootstrap mechanism. PD is not specifically a provisionning function anyway, but something that also happens in the life of the MR, much like renumbering the Home Link. >The mobile router can always try the next home agent in the list of the >home agents if the first one does not respond to DHCPv6 messages. If [Pascal] Vijay, I do hope I see you in Dublin. But I'll certainly not go through all the rooms in the hotel to see if you are there or not :) >none of the home agents are capable of prefix delegation, then there is >nothing the mobile router can do about it, maybe use some static mobile >network prefixes. [Pascal] The MR should be able to raise an alert if it is configured for PD and there no HA that supports it. Then again, a simple flow to detect it is a good thing, and for the time being DHAAD is the simplest flow that fits the bill Pascal >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Romain KUNTZ >> Sent: Sunday, June 01, 2008 3:50 PM >> To: marcelo bagnulo braun >> Cc: Julien Laganier; mext@ietf.org >> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> >> Hi, >> >> I'm in favor of accepting this document as WG doc. >> I have however one major concern: it proposes to use DHAAD to >> discover >> DHCPv6PD-enabled HA. However, the MIPv6 bootstrapping documents does >> not rely on DHAAD at all. More relationship should be considered >> between MIPv6 and NEMO bootstrapping, to enable the selection of a >> DHCPv6PD-enabled HA when the HA selection is performed during the >> MIPv6 bootstrapping time (e.g. by extending the DNS SRV lookup). >> >> About the text itself, for clarity I think that the section about to >> the home link (3.4) should be merged with section 3.1 ("When the MR >> uses DHCPv6"). >> >> Regards, >> -- >> Romain KUNTZ >> kuntz@lsiit.u-strasbg.fr >> Louis Pasteur University - Networks and Protocols Team >> >> >> On 2008/05/30, at 16:51, marcelo bagnulo braun wrote: >> >> > Hi, >> > >> > We would like to ask the WG what is their opinion about accepting >> > draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD >> > deliverable included in our charter. >> > >> > Please provide comments so we cna make some progress on this long >> > overdue deliverable >> > >> > thanks, Julien and marcelo >> > -------- Mensaje original -------- >> > Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt >> > Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >> > De: Internet-Drafts@ietf.org >> > Responder a: internet-drafts@ietf.org >> > Para: i-d-announce@ietf.org >> > >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> > directories. >> > >> > Title : DHCPv6 Prefix Delegation for NEMO >> > Author(s) : R. Droms, et al. >> > Filename : draft-droms-mext-nemo-pd-00.txt >> > Pages : 12 >> > Date : 2008-05-30 >> > >> > One aspect of network mobility support is the assignment of a prefix >> > or prefixes to a Mobile Router (MR) for use on the links in the >> > Mobile Network. DHCPv6 prefix delegation can be used for this >> > configuration task. >> > >> > A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > Below is the data which will enable a MIME compliant mail reader >> > implementation to automatically retrieve the ASCII version of the >> > Internet-Draft. >> > >> > >> > Content-Type: text/plain >> > Content-ID: <2008-05-30054232.I-D@ietf.org> >> > >> > >> > _______________________________________________ >> > I-D-Announce mailing list >> > I-D-Announce@ietf.org >> > https://www.ietf.org/mailman/listinfo/i-d-announce >> > Internet-Draft directories: http://www.ietf.org/shadow.html >> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > >> > _______________________________________________ >> > MEXT mailing list >> > MEXT@ietf.org >> > https://www.ietf.org/mailman/listinfo/mext >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 01:09:32 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AA323A687D; Tue, 3 Jun 2008 01:09:32 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42F293A687D for ; Tue, 3 Jun 2008 01:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mxvoWj+lrAf for ; Tue, 3 Jun 2008 01:09:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id CDEB93A67D9 for ; Tue, 3 Jun 2008 01:09:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,582,1204498800"; d="scan'208";a="10579108" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Jun 2008 10:09:28 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5389SqS014312; Tue, 3 Jun 2008 10:09:28 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5389Swi008358; Tue, 3 Jun 2008 08:09:28 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, 3 Jun 2008 10:09:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Jun 2008 10:08:55 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05C0F044@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Thread-Index: AcjFTx0HAEViIGAwQxa/VPzIq3PuOAAAUmSw References: <48401470.40706@it.uc3m.es> From: "Pascal Thubert (pthubert)" To: "Ryuji Wakikawa" , "marcelo bagnulo braun" X-OriginalArrivalTime: 03 Jun 2008 08:09:28.0156 (UTC) FILETIME=[24DD39C0:01C8C551] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3366; t=1212480568; x=1213344568; 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]=20Adoption=20of=20draft-droms-me xt-nemo-pd-00.txt? |Sender:=20; bh=m6CssW5Ek0dyvpxR7td95uBkdG4d6Z2/IdxehQTMOnw=; b=V4+JxizmbV6HzzNlUGNQL5kzmYSooOhAty0YINAfDBPaOjVo+mWI8gMRX+ 4ZAsdnXSznXv+9BXGmiQtIArWEBYG+w3qO5eYNsuJIvC7CjHam5h3QgSNaIf 4RRNpn6IwH; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ryuji: I agree that PD should not impact bootstrap. These are and should be kept unrelated. We must be able to extend a RFC 3963 MR with PD without forcing the bootstrap process in the picture. So I agree not to bring DHAAD back into the bootstrap... But I think that PD is NOT a bootstrap process. It is post bootstrap and can reoccur many times in the life of the MR. Until we define a new process and rev 3775 and 3963, we should stay consistent and simple in what we are doing. Pascal >-----Original Message----- >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Ryuji Wakikawa >Sent: mardi 3 juin 2008 09:54 >To: marcelo bagnulo braun >Cc: Julien Laganier; mext@ietf.org >Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > >Hi Marcelo, > >I agree to accept this as WG doc. > >I also agree with Romain and Vijay. >We don't need extension to DHAAD. >Since MR can act as MN, MR should be able to bootstrap with the same >mechanism of MIP (except for PD). >We should not bring DHAAD back in the bootstrap process only for PD. > >regards, >ryuji > > >On 2008/05/30, at 23:51, marcelo bagnulo braun wrote: > >> Hi, >> >> We would like to ask the WG what is their opinion about accepting >> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD >> deliverable included in our charter. >> >> Please provide comments so we cna make some progress on this long >> overdue deliverable >> >> thanks, Julien and marcelo >> -------- Mensaje original -------- >> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt >> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >> De: Internet-Drafts@ietf.org >> Responder a: internet-drafts@ietf.org >> Para: i-d-announce@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : DHCPv6 Prefix Delegation for NEMO >> Author(s) : R. Droms, et al. >> Filename : draft-droms-mext-nemo-pd-00.txt >> Pages : 12 >> Date : 2008-05-30 >> >> One aspect of network mobility support is the assignment of a prefix >> or prefixes to a Mobile Router (MR) for use on the links in the >> Mobile Network. DHCPv6 prefix delegation can be used for this >> configuration task. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> Content-Type: text/plain >> Content-ID: <2008-05-30054232.I-D@ietf.org> >> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 01:24:19 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F4383A6AC0; Tue, 3 Jun 2008 01:24:19 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EABB73A6AC0 for ; Tue, 3 Jun 2008 01:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrPH+yZmV41e for ; Tue, 3 Jun 2008 01:24:17 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 21B8D3A6A6C for ; Tue, 3 Jun 2008 01:24:16 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1212481458!8151576!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 743 invoked from network); 3 Jun 2008 08:24:18 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-153.messagelabs.com with SMTP; 3 Jun 2008 08:24:18 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m538OHSO008732 for ; Tue, 3 Jun 2008 01:24:17 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id m538OHOE020273 for ; Tue, 3 Jun 2008 03:24:17 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id m538OGR9020268 for ; Tue, 3 Jun 2008 03:24:16 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 09:24:15 +0100 Message-ID: <4844FFAE.3090604@gmail.com> Date: Tue, 03 Jun 2008 10:24:14 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Francis Dupont References: <200806022237.m52MbeK3064144@givry.fdupont.fr> In-Reply-To: <200806022237.m52MbeK3064144@givry.fdupont.fr> X-Antivirus: avast! (VPS 080602-0, 02/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 03 Jun 2008 08:24:15.0737 (UTC) FILETIME=[35E75690:01C8C553] X-CFilter-Loop: Reflected Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] side discussion about discovering a HA (was: Adoption of draft-droms-mext-nemo-pd-00.txt?) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Francis Dupont wrote: > In your previous mail you wrote: > > It's a bad idea to not extend DHAAD. > > => or DHAAD is a bad idea (:-)? > > It's a bad idea to extend DNS for discovering stuff. DNS is not for > discovery. > > => RFC 2782 (aka DNS SRV RR) is enough used to prove you are wrong. Similarly to how a DHCP Client wouldn't DNS to discover a DHCP Server, a MN wouldn't DNS to discover a HA. Of course, one _would_ DNS to discover a LDAP, printing, SIP, web service. Right or wrong - I don't know. Alex > > Regards > > Francis.Dupont@fdupont.fr > ______________________________________________________________________ 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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 01:32:08 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1645B3A6B4C; Tue, 3 Jun 2008 01:32:08 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7EA3A6B4C for ; Tue, 3 Jun 2008 01:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4hVFPzpq+XK for ; Tue, 3 Jun 2008 01:32:06 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 0EF853A6B3D for ; Tue, 3 Jun 2008 01:32:06 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1212481919!4203133!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 11253 invoked from network); 3 Jun 2008 08:31:59 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-5.tower-128.messagelabs.com with SMTP; 3 Jun 2008 08:31:59 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id m538Vw3g022634 for ; Tue, 3 Jun 2008 01:31:58 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id m538Vuaj021850 for ; Tue, 3 Jun 2008 03:31:57 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id m538VtpW021830 for ; Tue, 3 Jun 2008 03:31:56 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 09:31:54 +0100 Message-ID: <48450179.8020004@gmail.com> Date: Tue, 03 Jun 2008 10:31:53 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Jari Arkko References: <4843B64E.8040307@it.uc3m.es> <4843C104.3030706@gmail.com> <4844BFFE.9020005@piuha.net> In-Reply-To: <4844BFFE.9020005@piuha.net> X-Antivirus: avast! (VPS 080602-0, 02/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 03 Jun 2008 08:31:54.0905 (UTC) FILETIME=[4796D090:01C8C554] X-CFilter-Loop: Reflected Cc: charliep@computer.org, mext@ietf.org, Julien Laganier Subject: Re: [MEXT] TC/flow label copying X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Jari Arkko wrote: > Sri, > >> The transport AD did not agree with this stand and we ended up >> specifying the ECN handling for the PMIP tunnels. > > I think there are several different cases: > > 1) The referenced spec does have the needed words > 2) The referenced spec does not have the needed words > 3) The referenced spec has the words, but the referring spec needs > further details > 4) The referenced spec has the words, but its important to highlight the > issue for some reason > 5) ... > > I don't think its necessary to add any explanation for case 1. In other > cases, it may be needed. Like Netlmm, I think we were mostly in items 2 > and 3. But what I understood from Alex we had case 1 here. I have not > checked the RFC recently, however... YEs, it was item 1: referenced spec (rfc2473) does have the words about the possibility to copy the TC/Flow labels or insert pre-configured values. However, at least one widespread implementation doesn't implement the latter feature. I think if some implementers realize there may be some issue in which qos is used with mip6 then we may need to clarify 3775. Otherwise, if in practice this aspect was not identified by some implementers then we may continue as now until the need becomes apparent. 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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 02:54:28 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 227093A683F; Tue, 3 Jun 2008 02:54:28 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AD1C3A68DA for ; Tue, 3 Jun 2008 02:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sQ6699HXg5f for ; Tue, 3 Jun 2008 02:54:26 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 742DD3A683F for ; Tue, 3 Jun 2008 02:54:26 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1232737rvf.49 for ; Tue, 03 Jun 2008 02:54:29 -0700 (PDT) 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=aLawQtVTMabQ+yGPlawA1LgVbFpCafx5356sHWEWxQc=; b=cRPj810K4ljl4MQZEnZqgnPWCAgUpJz0VUHb9kgdp7C8A1EnITHG0tAgDn3BRJ1k2xwe/0MtvtP/xy6T+cePv+dRVRghwjOhH2Itq/0O/95CWxbSI1kWIGOs0GB/cpXplNWavtyC4DO48z0js+SULo57Jd5ItBzJRP40rDniHYA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rhM9axpFCjk2xsAZOkzP6H3tU2AtBCeLhat55HNTbJxwgpBhbqSqH9aLjRmvwIeFmjcLK7wZBQskF3WpPdSdBEc+t18MBEjLZiBgZvvrLlAm7w2Hu6cREJH6xH6pFVtRE/zwRx16Dw+WdvEwouQ8NxEWfH0i++0dIP8W8EO+Vtg= Received: by 10.140.166.21 with SMTP id o21mr5640622rve.167.1212486868942; Tue, 03 Jun 2008 02:54:28 -0700 (PDT) Received: by 10.141.189.15 with HTTP; Tue, 3 Jun 2008 02:54:28 -0700 (PDT) Message-ID: <729b68be0806030254n3e4e66b3rea92f04484630c3d@mail.gmail.com> Date: Tue, 3 Jun 2008 11:54:28 +0200 From: "Jean-Michel Combes" To: "marcelo bagnulo braun" In-Reply-To: <48401470.40706@it.uc3m.es> MIME-Version: 1.0 Content-Disposition: inline References: <48401470.40706@it.uc3m.es> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, I agree that this draft becomes WG document. Best regards. JMC. 2008/5/30, marcelo bagnulo braun : > Hi, > > We would like to ask the WG what is their opinion about accepting > draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD > deliverable included in our charter. > > Please provide comments so we cna make some progress on this long overdue > deliverable > > thanks, Julien and marcelo > > -------- Mensaje original -------- > Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt > Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) > De: Internet-Drafts@ietf.org > Responder a: internet-drafts@ietf.org > Para: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : DHCPv6 Prefix Delegation for NEMO > Author(s) : R. Droms, et al. > Filename : draft-droms-mext-nemo-pd-00.txt > Pages : 12 > Date : 2008-05-30 > > One aspect of network mobility support is the assignment of a prefix > or prefixes to a Mobile Router (MR) for use on the links in the > Mobile Network. DHCPv6 prefix delegation can be used for this > configuration task. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > 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://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 03:03:08 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 810203A68AA; Tue, 3 Jun 2008 03:03:08 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02FFC3A68AA for ; Tue, 3 Jun 2008 03:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOe11dDCYSvA for ; Tue, 3 Jun 2008 03:03:04 -0700 (PDT) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by core3.amsl.com (Postfix) with ESMTP id 5F9533A68B5 for ; Tue, 3 Jun 2008 03:03:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id A98DA2F0611; Tue, 3 Jun 2008 12:03:05 +0200 (CEST) Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXjatKFFBUZ5; Tue, 3 Jun 2008 12:03:05 +0200 (CEST) Received: from [130.79.91.222] (unknown [130.79.91.222]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 38CAE2F060A; Tue, 3 Jun 2008 12:03:05 +0200 (CEST) Message-Id: <29411897-3DC8-4120-AC04-594CFF59A8FE@lsiit.u-strasbg.fr> From: Romain KUNTZ To: Behcet Sarikaya In-Reply-To: <742376.69109.qm@web84310.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 3 Jun 2008 12:03:04 +0200 References: <742376.69109.qm@web84310.mail.re1.yahoo.com> X-Mailer: Apple Mail (2.924) Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Behcet, On 2008/06/02, at 17:18, Behcet Sarikaya wrote: > [behcet] You are right. I claim that from MR complexity point of > view BU/BA signaling leads to a simpler solution. It also leads to the definition of 2 solutions: DHCPv6 between the HA and the DHCP server, and BU/BA extensions. I don't think this makes it simpler. > Also BU/BA guarantees that MR registration with HA is valid at the > times of prefix provisioning, this is a big plus. A point that was already raised is the home link support: how do you delegate prefixes when the MR boots in the Home Link and thus does not exchange BU/BA messages? By defining a third solution maybe? ;-) Synchronizing the MR registration and the DHCP exchange is just an implementation matter, and IMHO, not so big to deal with. > [behcet] I was in the room when consensus call was made. The call > was if the floor agrees with the use of DHCPv6 PD but did not > specify from MR or from HA. > So the consensus applies to my document as well which proposes to > use DHCPv6 PD from HA. > I mentioned this to the chair on a face to face meeting after the > session. Ok, what was their opinion on that? Regards, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr Louis Pasteur University - Networks and Protocols Team _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 03:08:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3931A3A68AA; Tue, 3 Jun 2008 03:08:47 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFFD53A683F for ; Tue, 3 Jun 2008 03:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4swjagkrgxUP for ; Tue, 3 Jun 2008 03:08:45 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by core3.amsl.com (Postfix) with ESMTP id C1CDE3A6821 for ; Tue, 3 Jun 2008 03:08:44 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so776756and.122 for ; Tue, 03 Jun 2008 03:08:47 -0700 (PDT) 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=MobEeaK4fG/WDz80Lpbrme5nDZSpPA+BHlORHMmS/fs=; b=ZJ6GuOqMCn9tS870ZtVSslCzBzagncz4Bfzn3/4mT2MUWPmygIAYixnO9DTLl6PcFB/Qrkl/WbgkZaIpFmG42FCNsXR/4CQ2vuqv4+4a2vowW1keixrM02+dp4zFWUE5qBMl4Zz8WfqPAv1OBZTJLHtjVuxO2iqjVlQXfq5aGBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XiwX2whfPVnQe0B6XVj0RMLwkpYi8nsM7tMgupML2CReoWy+tQ+WJeLQ+1J59sWw/VbJR7tf/EMBOj6wTA0OXCmswzOB4A4QQoLR40pnzv200mQMYZV7yMq4sGxRePnPERujJPhWetqHgsu6LnM53Oppn2sZ5Ogm+5NqIRpyhJA= Received: by 10.100.11.7 with SMTP id 7mr17139970ank.149.1212487726874; Tue, 03 Jun 2008 03:08:46 -0700 (PDT) Received: by 10.100.211.17 with HTTP; Tue, 3 Jun 2008 03:08:46 -0700 (PDT) Message-ID: <5e2406980806030308p7e644c6dp20b454fbd5551cdf@mail.gmail.com> Date: Tue, 3 Jun 2008 12:08:46 +0200 From: "Julien Bournelle" To: "Alexandru Petrescu" In-Reply-To: <4844FFAE.3090604@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <200806022237.m52MbeK3064144@givry.fdupont.fr> <4844FFAE.3090604@gmail.com> Cc: Julien Laganier , Francis Dupont , mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA (was: Adoption of draft-droms-mext-nemo-pd-00.txt?) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, On Tue, Jun 3, 2008 at 10:24 AM, Alexandru Petrescu wrote: > Francis Dupont wrote: >> In your previous mail you wrote: >> >> It's a bad idea to not extend DHAAD. >> >> => or DHAAD is a bad idea (:-)? >> >> It's a bad idea to extend DNS for discovering stuff. DNS is not for >> discovery. >> >> => RFC 2782 (aka DNS SRV RR) is enough used to prove you are wrong. > > Similarly to how a DHCP Client wouldn't DNS to discover a DHCP Server, a > MN wouldn't DNS to discover a HA. > why a MN wouldn't use DNS to discover a HA ? not sure to understand. Regards, Julien > Of course, one _would_ DNS to discover a LDAP, printing, SIP, web service. > > Right or wrong - I don't know. > > Alex > >> >> Regards >> >> Francis.Dupont@fdupont.fr >> > > > ______________________________________________________________________ > 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://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 03:45:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A6543A6951; Tue, 3 Jun 2008 03:45:12 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2848B3A6904 for ; Tue, 3 Jun 2008 03:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFnkU-+H7ett for ; Tue, 3 Jun 2008 03:45:09 -0700 (PDT) Received: from kafka.verkstad.net (kafka.verkstad.net [192.71.20.153]) by core3.amsl.com (Postfix) with ESMTP id 05C393A684B for ; Tue, 3 Jun 2008 03:45:09 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id 5D461710A7A; Tue, 3 Jun 2008 12:45:11 +0200 (CEST) Date: Tue, 3 Jun 2008 12:45:11 +0200 From: Michael Eriksson To: marcelo bagnulo braun Message-ID: <20080603104511.GA3314@kafka.verkstad.net> References: <483D5A50.1000208@it.uc3m.es> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <483D5A50.1000208@it.uc3m.es> Cc: mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Wed, May 28, 2008 at 15:12:48 +0200, marcelo bagnulo braun wrote: > In our new charter we have a new item on a generic notification mechanism. > During discussion over the last weeks, it seems to me that the WG needs to > make a decision about what is the scope of the generic notification > > In summary, we need to decide which is the scope of the generic > notification and what is the scope of the existing MH types. > Essentially, what need to be as clear as possible are the criteria > for using the generic notification and which is the criteria for > using a MH type. I think that a generic notification mechanism should be used for all in-session signaling for MIPv6, i.e., when there is a BCE for the MN at the HA (or CN). It should be bidirectional, and thus allow signaling both to and from a MN. Having one single in-session signaling mechanism means that we don't have to redesign/respecify message transport, protection, retransmission, sequence numbering etc for each new signaling message. This will make both the specifications and implementations less complex. The Generic Notification Message (GNM), as described in draft-haley-mext-generic-notification-message-00.txt, is a good start for such a mechanism (but see below for enhancements). For a real-life use case, the GNM is spot-on for transmitting flow distribution rules; see http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-00 We are planning to soon write a short draft on how to transmit the rules, both MN->HA and HA->MN, using the GNM. Currently, I see two areas for GNM extension/improvement: - The GNM should support protected signaling also between MN and CN, and not only between MN and HA as seems to be the case right now. - I don't particularly like the "notification" part of GNM's name, as I think it will should be used for more than notifications. Regards, Michael _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 04:06:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09B1C3A69D8; Tue, 3 Jun 2008 04:06:47 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452A83A69CF for ; Tue, 3 Jun 2008 04:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-zcuMvdV+YS for ; Tue, 3 Jun 2008 04:06:45 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 47C353A67DB for ; Tue, 3 Jun 2008 04:06:45 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id EA9F719867A; Tue, 3 Jun 2008 14:06:46 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 2D8A819866A; Tue, 3 Jun 2008 14:06:44 +0300 (EEST) Message-ID: <484525C6.4030709@piuha.net> Date: Tue, 03 Jun 2008 07:06:46 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Alexandru Petrescu References: <4843B64E.8040307@it.uc3m.es> <4843C104.3030706@gmail.com> <4844BFFE.9020005@piuha.net> <48450179.8020004@gmail.com> In-Reply-To: <48450179.8020004@gmail.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: charliep@computer.org, mext@ietf.org, Julien Laganier Subject: Re: [MEXT] TC/flow label copying X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alex, > YEs, it was item 1: referenced spec (rfc2473) does have the words > about the possibility to copy the TC/Flow labels or insert > pre-configured values. However, at least one widespread > implementation doesn't implement the latter feature. > > I think if some implementers realize there may be some issue in which > qos is used with mip6 then we may need to clarify 3775. Otherwise, if > in practice this aspect was not identified by some implementers then > we may continue as now until the need becomes apparent. I understand what you want to do. But if our situation is that implementors are ignoring IETF RFCs, its not going to be helped by publishing more RFCs. And including things in category 1 would be a never-ending task. Lets focus on the other categories where we can actually add some value. And hopefully because of you raising this issue now here on the list some implementors are now going back to fix their code :-) Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 04:36:58 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16BC73A693C; Tue, 3 Jun 2008 04:36:58 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38B9F3A69CF for ; Tue, 3 Jun 2008 04:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sG9L2eozoL-1 for ; Tue, 3 Jun 2008 04:36:56 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 5E7653A6868 for ; Tue, 3 Jun 2008 04:36:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-153.messagelabs.com!1212493014!8324236!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 16143 invoked from network); 3 Jun 2008 11:36:54 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-153.messagelabs.com with SMTP; 3 Jun 2008 11:36:54 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m53Ban1w028635 for ; Tue, 3 Jun 2008 04:36:54 -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 m53BamGU005528 for ; Tue, 3 Jun 2008 06:36:48 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id m53Bal9A005524 for ; Tue, 3 Jun 2008 06:36:48 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 12:36:47 +0100 Message-ID: <48452CCC.40205@gmail.com> Date: Tue, 03 Jun 2008 13:36:44 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Julien Bournelle References: <200806022237.m52MbeK3064144@givry.fdupont.fr> <4844FFAE.3090604@gmail.com> <5e2406980806030308p7e644c6dp20b454fbd5551cdf@mail.gmail.com> In-Reply-To: <5e2406980806030308p7e644c6dp20b454fbd5551cdf@mail.gmail.com> X-Antivirus: avast! (VPS 080602-0, 02/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 03 Jun 2008 11:36:47.0257 (UTC) FILETIME=[1B256890:01C8C56E] X-CFilter-Loop: Reflected Cc: Julien Laganier , Francis Dupont , mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien Bournelle wrote: > Hi, > > On Tue, Jun 3, 2008 at 10:24 AM, Alexandru Petrescu > wrote: >> Francis Dupont wrote: >>> In your previous mail you wrote: >>> >>> It's a bad idea to not extend DHAAD. >>> >>> => or DHAAD is a bad idea (:-)? >>> >>> It's a bad idea to extend DNS for discovering stuff. DNS is not for >>> discovery. >>> >>> => RFC 2782 (aka DNS SRV RR) is enough used to prove you are wrong. >> Similarly to how a DHCP Client wouldn't DNS to discover a DHCP Server, a >> MN wouldn't DNS to discover a HA. >> > > why a MN wouldn't use DNS to discover a HA ? not sure to understand. MN needs a HA that can bind a CoA to its HoA. The HA that can do that binding must have the same prefix as the HoA. In this sense, DNS does not offer any relationship whatsover between a prefix and an address (DNS relates names to addresses). I don't understand why using DNS to discover a HA? Alex Why would MN need to discover its HA in the first place? (regardless of the means of doing it). > > Regards, > > Julien > >> Of course, one _would_ DNS to discover a LDAP, printing, SIP, web service. >> >> Right or wrong - I don't know. >> >> Alex >> >>> Regards >>> >>> Francis.Dupont@fdupont.fr >>> >> >> ______________________________________________________________________ >> 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://www.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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 04:49:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CCAC3A6976; Tue, 3 Jun 2008 04:49:16 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4918B3A6976 for ; Tue, 3 Jun 2008 04:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.245 X-Spam-Level: X-Spam-Status: No, score=-6.245 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0KsdICJUppd for ; Tue, 3 Jun 2008 04:49:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C52403A68FC for ; Tue, 3 Jun 2008 04:49:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,582,1204498800"; d="scan'208";a="10612848" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Jun 2008 13:49:13 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m53BnDBt031113; Tue, 3 Jun 2008 13:49:13 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m53BnDFP006781; Tue, 3 Jun 2008 11:49:13 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, 3 Jun 2008 13:49:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Jun 2008 13:48:40 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05C7209B@xmb-ams-337.emea.cisco.com> In-Reply-To: <48452CCC.40205@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] side discussion about discovering a HA Thread-Index: AcjFbjRk0JJIGJvVStuI97bZhUdBLAAAOZVw References: <200806022237.m52MbeK3064144@givry.fdupont.fr> <4844FFAE.3090604@gmail.com><5e2406980806030308p7e644c6dp20b454fbd5551cdf@mail.gmail.com> <48452CCC.40205@gmail.com> From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Julien Bournelle" X-OriginalArrivalTime: 03 Jun 2008 11:49:13.0259 (UTC) FILETIME=[D7CC47B0:01C8C56F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2974; t=1212493753; x=1213357753; 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]=20side=20discussion=20about=20di scovering=20a=20HA |Sender:=20; bh=WEoSdNa3hkD7gSXx+gP0eRwW6u1bXurBbpC0UkiZda0=; b=dD73+OFSzQ5rm1ho5tUq+rJBft5M7+eItvl4ncdlZSeZaeqO2a5jYaj+bf ksahLe7kcoqFgQuAnmxyy+rvAZTesQHrBAAfr5GQpkxtgNljOMbHeOzvamGa SkTrpGjcj9; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: mext@ietf.org, Francis Dupont , Julien Laganier Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I'm with Alex on this. If we really want to deprecate DHAAD then let's go ahead design its successor and rev all the RFCs that use it. In the meantime, DHAAD is still the tool designed specifically to locate a HA and NEMO sets a precedent in adding filters to it. Things are complex enough as they are; so please let us not create a new HA localization tool for each sub-feature we come up with! Pascal >-----Original Message----- >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Alexandru Petrescu >Sent: mardi 3 juin 2008 13:37 >To: Julien Bournelle >Cc: Julien Laganier; Francis Dupont; mext@ietf.org >Subject: Re: [MEXT] side discussion about discovering a HA > >Julien Bournelle wrote: >> Hi, >> >> On Tue, Jun 3, 2008 at 10:24 AM, Alexandru Petrescu >> wrote: >>> Francis Dupont wrote: >>>> In your previous mail you wrote: >>>> >>>> It's a bad idea to not extend DHAAD. >>>> >>>> => or DHAAD is a bad idea (:-)? >>>> >>>> It's a bad idea to extend DNS for discovering stuff. DNS is not for >>>> discovery. >>>> >>>> => RFC 2782 (aka DNS SRV RR) is enough used to prove you are wrong. >>> Similarly to how a DHCP Client wouldn't DNS to discover a DHCP Server, a >>> MN wouldn't DNS to discover a HA. >>> >> >> why a MN wouldn't use DNS to discover a HA ? not sure to understand. > >MN needs a HA that can bind a CoA to its HoA. The HA that can do that >binding must have the same prefix as the HoA. In this sense, DNS does >not offer any relationship whatsover between a prefix and an address >(DNS relates names to addresses). > >I don't understand why using DNS to discover a HA? > >Alex > > > > >Why would MN need to discover its HA in the first place? (regardless of >the means of doing it). > > > >> >> Regards, >> >> Julien >> >>> Of course, one _would_ DNS to discover a LDAP, printing, SIP, web service. >>> >>> Right or wrong - I don't know. >>> >>> Alex >>> >>>> Regards >>>> >>>> Francis.Dupont@fdupont.fr >>>> >>> >>> ______________________________________________________________________ >>> 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://www.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://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 04:53:36 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D109E3A6988; Tue, 3 Jun 2008 04:53:36 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AFC63A6976 for ; Tue, 3 Jun 2008 04:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSztm1zbR9v9 for ; Tue, 3 Jun 2008 04:53:34 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 7D10E3A683F for ; Tue, 3 Jun 2008 04:53:34 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-128.messagelabs.com!1212494008!799078!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 7324 invoked from network); 3 Jun 2008 11:53:28 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-2.tower-128.messagelabs.com with SMTP; 3 Jun 2008 11:53:28 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id m53BrQRN000977 for ; Tue, 3 Jun 2008 04:53:27 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id m53BrPua005072 for ; Tue, 3 Jun 2008 06:53:25 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id m53BrNZm005060 for ; Tue, 3 Jun 2008 06:53:24 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 12:53:23 +0100 Message-ID: <484530B2.40501@gmail.com> Date: Tue, 03 Jun 2008 13:53:22 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Jari Arkko References: <4843B64E.8040307@it.uc3m.es> <4843C104.3030706@gmail.com> <4844BFFE.9020005@piuha.net> <48450179.8020004@gmail.com> <484525C6.4030709@piuha.net> In-Reply-To: <484525C6.4030709@piuha.net> X-Antivirus: avast! (VPS 080602-0, 02/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 03 Jun 2008 11:53:23.0189 (UTC) FILETIME=[6CC49250:01C8C570] X-CFilter-Loop: Reflected Cc: charliep@computer.org, mext@ietf.org, Julien Laganier Subject: Re: [MEXT] TC/flow label copying X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Jari Arkko wrote: > Alex, > >> YEs, it was item 1: referenced spec (rfc2473) does have the words >> about the possibility to copy the TC/Flow labels or insert >> pre-configured values. However, at least one widespread >> implementation doesn't implement the latter feature. >> >> I think if some implementers realize there may be some issue in >> which qos is used with mip6 then we may need to clarify 3775. >> Otherwise, if in practice this aspect was not identified by some >> implementers then we may continue as now until the need becomes >> apparent. > > I understand what you want to do. But if our situation is that > implementors are ignoring IETF RFCs, its not going to be helped by > publishing more RFCs. And including things in category 1 would be a > never-ending task. Lets focus on the other categories where we can > actually add some value. And hopefully because of you raising this > issue now here on the list some implementors are now going back to > fix their code :-) I agree on the value adding part and I somehow disagree suggesting stuff to implementers. I am here to suggest back stuff to specifiers. I often notice differences between what's being specified and what's getting widely implemented. Protocols don't make it to even a WG item yet get deployed, and Proposed Standards protocols whose implementation is still to happen - but I disgress. Let me stop commenting on this and come back to Chair's reminder on 3775bis next steps. 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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 05:04:41 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F603A6947; Tue, 3 Jun 2008 05:04:40 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07DAA3A68D9 for ; Tue, 3 Jun 2008 05:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bTy81UkcfCa for ; Tue, 3 Jun 2008 05:04:38 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by core3.amsl.com (Postfix) with ESMTP id 926ED3A6976 for ; Tue, 3 Jun 2008 05:04:38 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so793852and.122 for ; Tue, 03 Jun 2008 05:04:40 -0700 (PDT) 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=J5qjAb6VGhiLvsfd4O9jvFXb6dxQVkdH2CIt/xX2dyM=; b=xAPxHHlVuad7SJ2kfPU+e1v0kdjz1oHTvJwog/NU68sinOv6mbYv5QRdflRAzEsWUZKhj1ZoDZCJ53aTf/0d/AbKzueaXfiy5cnMiepIFQSHg7LkHySgqyWvuWAx08WtSMdzuHLmevOj3s09awlXrNDs9+zCSuWgXoSntsZNZOM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mKtB8f8URXTSC1TI/rbbepenKD0f5XPGfK02kqBCBICZx0WyV+zG3omKUl/O/aHKP+CvgRAw7Od4knsdYkBBYglEfLeXMha6eOlM9RRQcRVUv/2J/6r5GVl2JWdhjY3yxzFCYkjLdBFbmbsjpoM994ZL/Qy3SyACinfKZ6vm+vU= Received: by 10.100.58.19 with SMTP id g19mr17440088ana.44.1212494680820; Tue, 03 Jun 2008 05:04:40 -0700 (PDT) Received: by 10.100.211.17 with HTTP; Tue, 3 Jun 2008 05:04:40 -0700 (PDT) Message-ID: <5e2406980806030504q49016b4h626eed6d729f7e5a@mail.gmail.com> Date: Tue, 3 Jun 2008 14:04:40 +0200 From: "Julien Bournelle" To: "Alexandru Petrescu" In-Reply-To: <48452CCC.40205@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <200806022237.m52MbeK3064144@givry.fdupont.fr> <4844FFAE.3090604@gmail.com> <5e2406980806030308p7e644c6dp20b454fbd5551cdf@mail.gmail.com> <48452CCC.40205@gmail.com> Cc: Julien Laganier , Francis Dupont , mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org inline... On Tue, Jun 3, 2008 at 1:36 PM, Alexandru Petrescu wrote: > Julien Bournelle wrote: >> >> Hi, >> >> On Tue, Jun 3, 2008 at 10:24 AM, Alexandru Petrescu >> wrote: >>> >>> Francis Dupont wrote: >>>> >>>> In your previous mail you wrote: >>>> >>>> It's a bad idea to not extend DHAAD. >>>> >>>> => or DHAAD is a bad idea (:-)? >>>> >>>> It's a bad idea to extend DNS for discovering stuff. DNS is not for >>>> discovery. >>>> >>>> => RFC 2782 (aka DNS SRV RR) is enough used to prove you are wrong. >>> >>> Similarly to how a DHCP Client wouldn't DNS to discover a DHCP Server, a >>> MN wouldn't DNS to discover a HA. >>> >> >> why a MN wouldn't use DNS to discover a HA ? not sure to understand. > > MN needs a HA that can bind a CoA to its HoA. The HA that can do that > binding must have the same prefix as the HoA. In this sense, DNS does not > offer any relationship whatsover between a prefix and an address (DNS > relates names to addresses). > > I don't understand why using DNS to discover a HA? this is what we specified in RFC 5026, so I was surprised that you say: "MN wouldn't DNS to discover a HA". Julien > > Alex > > > > > Why would MN need to discover its HA in the first place? (regardless of the > means of doing it). > > > >> >> Regards, >> >> Julien >> >>> Of course, one _would_ DNS to discover a LDAP, printing, SIP, web >>> service. >>> >>> Right or wrong - I don't know. >>> >>> Alex >>> >>>> Regards >>>> >>>> Francis.Dupont@fdupont.fr >>>> >>> >>> ______________________________________________________________________ >>> 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://www.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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 05:09:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D794D3A68D9; Tue, 3 Jun 2008 05:09:05 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88FE03A68D9 for ; Tue, 3 Jun 2008 05:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJrFwFCOC3Pa for ; Tue, 3 Jun 2008 05:09:04 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id AF1EB3A68D5 for ; Tue, 3 Jun 2008 05:09:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1212494946!7274905!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 764 invoked from network); 3 Jun 2008 12:09:06 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-7.tower-153.messagelabs.com with SMTP; 3 Jun 2008 12:09:06 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id m53C8xYF021793 for ; Tue, 3 Jun 2008 05:09:05 -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 m53C8wOn019136 for ; Tue, 3 Jun 2008 07:08:58 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id m53C8uw5019114 for ; Tue, 3 Jun 2008 07:08:57 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 13:08:55 +0100 Message-ID: <48453457.1010208@gmail.com> Date: Tue, 03 Jun 2008 14:08:55 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Julien Bournelle References: <200806022237.m52MbeK3064144@givry.fdupont.fr> <4844FFAE.3090604@gmail.com> <5e2406980806030308p7e644c6dp20b454fbd5551cdf@mail.gmail.com> <48452CCC.40205@gmail.com> <5e2406980806030504q49016b4h626eed6d729f7e5a@mail.gmail.com> In-Reply-To: <5e2406980806030504q49016b4h626eed6d729f7e5a@mail.gmail.com> X-Antivirus: avast! (VPS 080602-0, 02/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 03 Jun 2008 12:08:56.0041 (UTC) FILETIME=[98CA7D90:01C8C572] X-CFilter-Loop: Reflected Cc: Julien Laganier , Francis Dupont , mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien Bournelle wrote: > inline... > > On Tue, Jun 3, 2008 at 1:36 PM, Alexandru Petrescu > wrote: >> Julien Bournelle wrote: >>> Hi, >>> >>> On Tue, Jun 3, 2008 at 10:24 AM, Alexandru Petrescu >>> wrote: >>>> Francis Dupont wrote: >>>>> In your previous mail you wrote: >>>>> >>>>> It's a bad idea to not extend DHAAD. >>>>> >>>>> => or DHAAD is a bad idea (:-)? >>>>> >>>>> It's a bad idea to extend DNS for discovering stuff. DNS is not for >>>>> discovery. >>>>> >>>>> => RFC 2782 (aka DNS SRV RR) is enough used to prove you are wrong. >>>> Similarly to how a DHCP Client wouldn't DNS to discover a DHCP Server, a >>>> MN wouldn't DNS to discover a HA. >>>> >>> why a MN wouldn't use DNS to discover a HA ? not sure to understand. >> MN needs a HA that can bind a CoA to its HoA. The HA that can do that >> binding must have the same prefix as the HoA. In this sense, DNS does not >> offer any relationship whatsover between a prefix and an address (DNS >> relates names to addresses). >> >> I don't understand why using DNS to discover a HA? > > this is what we specified in RFC 5026, so I was surprised that you say: > "MN wouldn't DNS to discover a HA". DHAAD is what's implemented in MIPL and others. DHAAD is what's been tested between two different implementations. How about RFC 5026? 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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 05:17:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 341F53A6A0F; Tue, 3 Jun 2008 05:17:46 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 134773A6A0F for ; Tue, 3 Jun 2008 05:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeijz8ONKnTT for ; Tue, 3 Jun 2008 05:17:39 -0700 (PDT) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by core3.amsl.com (Postfix) with ESMTP id A08813A69F2 for ; Tue, 3 Jun 2008 05:17:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 625652F1557; Tue, 3 Jun 2008 14:17:41 +0200 (CEST) Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVu79AqqKOEj; Tue, 3 Jun 2008 14:17:41 +0200 (CEST) Received: from [130.79.91.222] (unknown [130.79.91.222]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 241222F1550; Tue, 3 Jun 2008 14:17:41 +0200 (CEST) Message-Id: From: Romain KUNTZ To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05C7209B@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 3 Jun 2008 14:17:40 +0200 References: <200806022237.m52MbeK3064144@givry.fdupont.fr> <4844FFAE.3090604@gmail.com><5e2406980806030308p7e644c6dp20b454fbd5551cdf@mail.gmail.com> <48452CCC.40205@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC05C7209B@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.924) Cc: mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Pascal, On 2008/06/03, at 13:48, Pascal Thubert (pthubert) wrote: > Things are complex enough as they are; so please let us not create a > new > HA localization tool for each sub-feature we come up with! DNS is not new, and is the standardized tool to resolve a FQDN or a service by domain name. The MIPv6 bootstrapping makes the assumption that the HA domain or FQDN is initially configured on the MR, hence the use of DNS to get the HA address. This seems like an obvious choice to me. DHAAD cannot be used in that case because the home prefix is not known by the MR. RFC 5026 explain more the motivations about that. romain _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 05:38:19 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0B193A68FC; Tue, 3 Jun 2008 05:38:19 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA983A6A89 for ; Tue, 3 Jun 2008 05:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f71hgyskr7pF for ; Tue, 3 Jun 2008 05:38:16 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 54B953A6AFD for ; Tue, 3 Jun 2008 05:35:15 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so1045707fga.41 for ; Tue, 03 Jun 2008 05:35:17 -0700 (PDT) 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-disposition:message-id:content-type:content-transfer-encoding:sender; bh=izEDmJ36pCNK8sBtX7oHK03Gu6J4zHLIVVILFR4KNLQ=; b=NSmuBwGyFSZ2nVkD1Ude1G4MZQDI8Zg5Ei2EdxWIVNZmZ8cVvK4lIRDnvMg6E1HtkATRDbvxiJWXE7YDeFhqSuWj3oCyy/sZZW8ChB74RQ9PENdzRtQ/S2mdEzYbqOQdLtaIexJczE/FwXzEvWMD8H1DbMFU1gIJmgQBIW/Lm5g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-disposition:message-id:content-type:content-transfer-encoding:sender; b=ujKw8OUFDSerq/4aLnSw6cwd3WtwQ+ZHz8L2S5Mp5JMEXJpvHNpbinTbkCHuPVBN1kXkqSrp/Yn/wM4B9cTeDcfk72f9dGtmJl4gO4+DsZirMirYJ6hFnU3jUJPJ0ZQ8Bv77r/d8pyM8pZnvhpqecS4hdL8X6c3114PNfOm1SJw= Received: by 10.86.76.20 with SMTP id y20mr4181930fga.5.1212496517250; Tue, 03 Jun 2008 05:35:17 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 13sm13407445fks.12.2008.06.03.05.35.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Jun 2008 05:35:15 -0700 (PDT) From: Julien Laganier To: "Julien Bournelle" , Romain KUNTZ , "Pascal Thubert (pthubert)" , Alexandru Petrescu Date: Tue, 3 Jun 2008 14:35:19 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200806022237.m52MbeK3064144@givry.fdupont.fr> <7892795E1A87F04CADFCCF41FADD00FC05C7209B@xmb-ams-337.emea.cisco.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806031435.20717.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, We already have the DHAAD vs. RFC5026 discussion on that mailing list. The fact is there are indeed two standardized methods to discover a HA, one based on DHAAD, and the other based on RFC5026, with different properties and applicability. Let me suggest that we don't spend again a lot of time arguing again which one is better than the other, and concentrate on our deliverables. Thanks. --julien On Tuesday 03 June 2008, Romain KUNTZ wrote: > Hi Pascal, > > On 2008/06/03, at 13:48, Pascal Thubert (pthubert) wrote: > > Things are complex enough as they are; so please let us not create > > a new > > HA localization tool for each sub-feature we come up with! > > DNS is not new, and is the standardized tool to resolve a FQDN or a > service by domain name. The MIPv6 bootstrapping makes the assumption > that the HA domain or FQDN is initially configured on the MR, hence > the use of DNS to get the HA address. This seems like an obvious > choice to me. > > DHAAD cannot be used in that case because the home prefix is not > known by the MR. RFC 5026 explain more the motivations about that. > > romain > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 05:55:41 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14293A68A7; Tue, 3 Jun 2008 05:55:41 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8581D3A6B5A for ; Tue, 3 Jun 2008 05:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXZw317qw80N for ; Tue, 3 Jun 2008 05:55:39 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 6940B3A6B92 for ; Tue, 3 Jun 2008 05:54:47 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1212497689!18294017!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 25377 invoked from network); 3 Jun 2008 12:54:49 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-128.messagelabs.com with SMTP; 3 Jun 2008 12:54:49 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m53Csn7I021080 for ; Tue, 3 Jun 2008 05:54:49 -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 m53CsmOM016868 for ; Tue, 3 Jun 2008 07:54:48 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id m53Cslme016858 for ; Tue, 3 Jun 2008 07:54:48 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 13:54:47 +0100 Message-ID: <48453F16.3040806@gmail.com> Date: Tue, 03 Jun 2008 14:54:46 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Romain KUNTZ References: <200806022237.m52MbeK3064144@givry.fdupont.fr> <4844FFAE.3090604@gmail.com><5e2406980806030308p7e644c6dp20b454fbd5551cdf@mail.gmail.com> <48452CCC.40205@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC05C7209B@xmb-ams-337.emea.cisco.com> In-Reply-To: X-Antivirus: avast! (VPS 080602-0, 02/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 03 Jun 2008 12:54:47.0565 (UTC) FILETIME=[00D3BBD0:01C8C579] X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Romain KUNTZ wrote: > Hi Pascal, > > On 2008/06/03, at 13:48, Pascal Thubert (pthubert) wrote: >> Things are complex enough as they are; so please let us not create >> a new HA localization tool for each sub-feature we come up with! > > DNS is not new, and is the standardized tool to resolve a FQDN or a > service by domain name. Somehow agree with you, but MIP6 has a distinctive feature: a HA is bound to a subnet (which is the size of a link-local multicast.) I don't think any other protocol relying on SRV Resource Records make this assumption: LDAP, printing, sip, http don't make any assumption about a subnet and a domain; for example, there is a single SIP Server for an entire domain, regardless of how many subnets that domain spans. To deploy rfc5026 in a network one needs to assign a different subdomain name to each subnet. This is difficult to maintain. SRV RR were useful for discovering a MIP6 HA _only_ if HA were not bound to a subnet. But this is not the case. One can't imagine a HA for an entire domain. An HA is not a VPN Server. 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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 05:55:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 264C63A6B6C; Tue, 3 Jun 2008 05:55:45 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D541B3A6B05 for ; Tue, 3 Jun 2008 05:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5XwRmanviSF for ; Tue, 3 Jun 2008 05:55:43 -0700 (PDT) Received: from mxs2.siemens.at (mxs2.siemens.at [194.138.12.133]) by core3.amsl.com (Postfix) with ESMTP id BE81D3A6BAF for ; Tue, 3 Jun 2008 05:54:49 -0700 (PDT) Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs2.siemens.at with ESMTP id m53CsnI5003766; Tue, 3 Jun 2008 14:54:49 +0200 Received: from nets139a.ww300.siemens.net ([192.168.217.3]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m53Cskv1010909; Tue, 3 Jun 2008 14:54:48 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 14:54:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Jun 2008 14:54:41 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD6803F50FD2@zagh223a.ww300.siemens.net> In-Reply-To: <48452CCC.40205@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] side discussion about discovering a HA Thread-Index: AcjFbmbMUkV7HnLwS0WrmM47f72UjQACOzQQ References: <200806022237.m52MbeK3064144@givry.fdupont.fr> <4844FFAE.3090604@gmail.com><5e2406980806030308p7e644c6dp20b454fbd5551cdf@mail.gmail.com> <48452CCC.40205@gmail.com> From: "Premec, Domagoj" To: "Alexandru Petrescu" , "Julien Bournelle" X-OriginalArrivalTime: 03 Jun 2008 12:54:46.0203 (UTC) FILETIME=[0003E8B0:01C8C579] 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::080603145449-0F49FBA0-7671FD03/0-0/0-15 X-purgate-size: 3124/999999 Cc: mext@ietf.org, Francis Dupont , Julien Laganier Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Alex, > MN needs a HA that can bind a CoA to its HoA. The HA that > can do that binding must have the same prefix as the HoA. Not directly related to the topic, but... I thought that the HoA and the HA addresses could be based on different prefixes. What you say would be a limitation at least for the case when the per-MN prefix model is used. domagoj > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Alexandru Petrescu > Sent: 03. lipanj 2008 13:37 > To: Julien Bournelle > Cc: Julien Laganier; Francis Dupont; mext@ietf.org > Subject: Re: [MEXT] side discussion about discovering a HA > > Julien Bournelle wrote: > > Hi, > > > > On Tue, Jun 3, 2008 at 10:24 AM, Alexandru Petrescu > > wrote: > >> Francis Dupont wrote: > >>> In your previous mail you wrote: > >>> > >>> It's a bad idea to not extend DHAAD. > >>> > >>> => or DHAAD is a bad idea (:-)? > >>> > >>> It's a bad idea to extend DNS for discovering stuff. > DNS is not for > >>> discovery. > >>> > >>> => RFC 2782 (aka DNS SRV RR) is enough used to prove you > are wrong. > >> Similarly to how a DHCP Client wouldn't DNS to discover a DHCP > >> Server, a MN wouldn't DNS to discover a HA. > >> > > > > why a MN wouldn't use DNS to discover a HA ? not sure to > understand. > > MN needs a HA that can bind a CoA to its HoA. The HA that > can do that binding must have the same prefix as the HoA. In > this sense, DNS does not offer any relationship whatsover > between a prefix and an address (DNS relates names to addresses). > > I don't understand why using DNS to discover a HA? > > Alex > > > > > Why would MN need to discover its HA in the first place? > (regardless of the means of doing it). > > > > > > > Regards, > > > > Julien > > > >> Of course, one _would_ DNS to discover a LDAP, printing, > SIP, web service. > >> > >> Right or wrong - I don't know. > >> > >> Alex > >> > >>> Regards > >>> > >>> Francis.Dupont@fdupont.fr > >>> > >> > >> > ______________________________________________________________________ > >> 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://www.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://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 06:06:27 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F81028C219; Tue, 3 Jun 2008 06:06:27 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D304E3A6A32 for ; Tue, 3 Jun 2008 06:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyarogv6zSdG for ; Tue, 3 Jun 2008 06:06:24 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 8C2783A6B5C for ; Tue, 3 Jun 2008 06:02:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-153.messagelabs.com!1212498134!13393685!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 8991 invoked from network); 3 Jun 2008 13:02:14 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-2.tower-153.messagelabs.com with SMTP; 3 Jun 2008 13:02:14 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id m53D2DVq000293 for ; Tue, 3 Jun 2008 06:02:13 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id m53D2Cnx025439 for ; Tue, 3 Jun 2008 08:02:12 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id m53D2Axp025405 for ; Tue, 3 Jun 2008 08:02:11 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 14:02:10 +0100 Message-ID: <484540D1.3090206@gmail.com> Date: Tue, 03 Jun 2008 15:02:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Premec, Domagoj" References: <200806022237.m52MbeK3064144@givry.fdupont.fr> <4844FFAE.3090604@gmail.com><5e2406980806030308p7e644c6dp20b454fbd5551cdf@mail.gmail.com> <48452CCC.40205@gmail.com> <3C31CDD06342EA4A8137716247B1CD6803F50FD2@zagh223a.ww300.siemens.net> In-Reply-To: <3C31CDD06342EA4A8137716247B1CD6803F50FD2@zagh223a.ww300.siemens.net> X-Antivirus: avast! (VPS 080602-0, 02/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 03 Jun 2008 13:02:10.0357 (UTC) FILETIME=[08C06E50:01C8C57A] X-CFilter-Loop: Reflected Cc: mext@ietf.org, Francis Dupont , Julien Laganier Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Premec, Domagoj wrote: > Hi Alex, > >> MN needs a HA that can bind a CoA to its HoA. The HA that can do >> that binding must have the same prefix as the HoA. > > Not directly related to the topic, but... I thought that the HoA and > the HA addresses could be based on different prefixes. Which HA address(es)? The HA address with which the HA does proxy ND defending the HoA when not at home, and with which HA replies to DHAAD, and with which it builds the HA list among the other HAs, must have precisely the same prefix as the HoA. If one considers a HA with two interfaces: egress and ingress, and the ingress is the home of the mobiles then the egress and ingress could be assigned entirely different prefixes (differ at leftmost bit). Or could have a the same first few bits, or same leftmos 64 bits. Typically the two prefixes of HA do share some initial bits. But I don't think rfc3775 specifies HA to do anything with its address that is not on the same prefix as the HoA. Alex What you say > would be a limitation at least for the case when the per-MN prefix > model is used. > > domagoj > > >> -----Original Message----- From: mext-bounces@ietf.org >> [mailto:mext-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: 03. lipanj 2008 13:37 To: Julien Bournelle Cc: Julien >> Laganier; Francis Dupont; mext@ietf.org Subject: Re: [MEXT] side >> discussion about discovering a HA >> >> Julien Bournelle wrote: >>> Hi, >>> >>> On Tue, Jun 3, 2008 at 10:24 AM, Alexandru Petrescu >>> wrote: >>>> Francis Dupont wrote: >>>>> In your previous mail you wrote: >>>>> >>>>> It's a bad idea to not extend DHAAD. >>>>> >>>>> => or DHAAD is a bad idea (:-)? >>>>> >>>>> It's a bad idea to extend DNS for discovering stuff. >> DNS is not for >>>>> discovery. >>>>> >>>>> => RFC 2782 (aka DNS SRV RR) is enough used to prove you >> are wrong. >>>> Similarly to how a DHCP Client wouldn't DNS to discover a DHCP >>>> Server, a MN wouldn't DNS to discover a HA. >>>> >>> why a MN wouldn't use DNS to discover a HA ? not sure to >> understand. >> >> MN needs a HA that can bind a CoA to its HoA. The HA that can do >> that binding must have the same prefix as the HoA. In this sense, >> DNS does not offer any relationship whatsover between a prefix and >> an address (DNS relates names to addresses). >> >> I don't understand why using DNS to discover a HA? >> >> Alex >> >> >> >> >> Why would MN need to discover its HA in the first place? >> (regardless of the means of doing it). >> >> >> >>> Regards, >>> >>> Julien >>> >>>> Of course, one _would_ DNS to discover a LDAP, printing, >> SIP, web service. >>>> Right or wrong - I don't know. >>>> >>>> Alex >>>> >>>>> Regards >>>>> >>>>> Francis.Dupont@fdupont.fr >>>>> >>>> >> ______________________________________________________________________ >> >>>> 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://www.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://www.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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 06:38:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B3333A68B7; Tue, 3 Jun 2008 06:38:00 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D71A03A687D for ; Tue, 3 Jun 2008 06:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILw2fvPSy8RV for ; Tue, 3 Jun 2008 06:37:59 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6B19E3A6889 for ; Tue, 3 Jun 2008 06:37:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,583,1204498800"; d="scan'208";a="10635609" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Jun 2008 15:37:54 +0200 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 m53Dbs69025326; Tue, 3 Jun 2008 15:37:54 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m53DbsmU023329; Tue, 3 Jun 2008 13:37:54 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jun 2008 15:37:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Jun 2008 15:37:19 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05C72166@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] side discussion about discovering a HA Thread-Index: AcjFdAoORVOZeeekSpiBMQUuNgowkQACnOxg References: <200806022237.m52MbeK3064144@givry.fdupont.fr> <4844FFAE.3090604@gmail.com><5e2406980806030308p7e644c6dp20b454fbd5551cdf@mail.gmail.com> <48452CCC.40205@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC05C7209B@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Romain KUNTZ" X-OriginalArrivalTime: 03 Jun 2008 13:37:53.0896 (UTC) FILETIME=[06668680:01C8C57F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1320; t=1212500274; x=1213364274; 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]=20side=20discussion=20about=20di scovering=20a=20HA |Sender:=20; bh=LEwg2sum26paTSlhNK+ib5eoIItMlUKpIPxOq4Y88FU=; b=pKhRAbwDt13W5kJqYe4u7VSPElOm5aCNOg2IupicYk4LqrMQ8fqoW9cUh7 dMIkp/6K3Kin2+brxW93Ks/KVXIBi5w6+VFFczOfI/Wc0pSpsTlVw4lkKkjZ LMotjY88qE; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Romain: This thread started with the Prefix Delegation draft. PD is not bootstrap and does not have its assumptions and limitations. IOW, whether a MR is preconfigured or found its home info via 5026 is orthogonal to Prefix Delegation. So I perfectly respect the design is RFC 5026 but that's not the problem at hand. The precedent is actually RFC 3963 and the method is extending DHAAD... Pascal >-----Original Message----- >From: Romain KUNTZ [mailto:kuntz@lsiit.u-strasbg.fr] >Sent: mardi 3 juin 2008 14:18 >To: Pascal Thubert (pthubert) >Cc: mext@ietf.org >Subject: Re: [MEXT] side discussion about discovering a HA > >Hi Pascal, > >On 2008/06/03, at 13:48, Pascal Thubert (pthubert) wrote: >> Things are complex enough as they are; so please let us not create a >> new >> HA localization tool for each sub-feature we come up with! > >DNS is not new, and is the standardized tool to resolve a FQDN or a >service by domain name. The MIPv6 bootstrapping makes the assumption >that the HA domain or FQDN is initially configured on the MR, hence >the use of DNS to get the HA address. This seems like an obvious >choice to me. > >DHAAD cannot be used in that case because the home prefix is not known >by the MR. RFC 5026 explain more the motivations about that. > >romain _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 06:45:43 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C070928C0E2; Tue, 3 Jun 2008 06:45:43 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824C83A6ACC for ; Tue, 3 Jun 2008 06:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUTLeU1WmOIG for ; Tue, 3 Jun 2008 06:45:41 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id AF7B33A6B07 for ; Tue, 3 Jun 2008 06:44:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,583,1204498800"; d="scan'208";a="10636993" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Jun 2008 15:44:52 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m53DiqZE022147; Tue, 3 Jun 2008 15:44:52 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m53DiqdE026187; Tue, 3 Jun 2008 13:44:52 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jun 2008 15:44:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Jun 2008 15:44:17 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05C72172@xmb-ams-337.emea.cisco.com> In-Reply-To: <200806031435.20717.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] side discussion about discovering a HA Thread-Index: AcjFdky7xOoK1eG1QWWmWSi14OUUHAACMYaQ References: <200806022237.m52MbeK3064144@givry.fdupont.fr> <7892795E1A87F04CADFCCF41FADD00FC05C7209B@xmb-ams-337.emea.cisco.com> <200806031435.20717.julien.IETF@laposte.net> From: "Pascal Thubert (pthubert)" To: "Julien Laganier" , "Julien Bournelle" , "Romain KUNTZ" , "Alexandru Petrescu" X-OriginalArrivalTime: 03 Jun 2008 13:44:52.0130 (UTC) FILETIME=[FFAFF820:01C8C57F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2292; t=1212500692; x=1213364692; 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]=20side=20discussion=20about=20di scovering=20a=20HA |Sender:=20; bh=CPUpJjX/KL47R5yqCHNKACejnZZFdHe47daVuGXs0yQ=; b=vKgESeLbud1EstXagGpCWjtiUL8AIwnF4ivtu8C9lPtQKJFpWEk/cG80C7 XofVQSWSedXHpJzrLQzCbTaiYene+ZprXkv/DyQ8HMGeTIGuWsNwz7MtolGK 5qLsfY+mO2; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien: This is exactly what I'm trying to do. The use of DHAAD in the PD draft is being challenged and we have reach an agreement whether it's justified or not. There is a confusion that since PD might occur right after bootstrap it could be considered as bootstrap and thus use the bootstrap discovery method. I'm claiming it's not bootstrap but runtime and that at the time the PD process starts, the home prefix is known one way or another, regardless on whether config or RFC 5026 was used or not to get there. There should be no tie or dependency between PD and bootstrap. Pascal >-----Original Message----- >From: julien laganier [mailto:julien.laganier@gmail.com] On Behalf Of Julien Laganier >Sent: mardi 3 juin 2008 14:35 >To: Julien Bournelle; Romain KUNTZ; Pascal Thubert (pthubert); Alexandru Petrescu >Cc: mext@ietf.org >Subject: Re: [MEXT] side discussion about discovering a HA > >Folks, > > > >We already have the DHAAD vs. RFC5026 discussion on that mailing list. >The fact is there are indeed two standardized methods to discover a HA, >one based on DHAAD, and the other based on RFC5026, with different >properties and applicability. > >Let me suggest that we don't spend again a lot of time arguing again >which one is better than the other, and concentrate on our >deliverables. > >Thanks. > >--julien > >On Tuesday 03 June 2008, Romain KUNTZ wrote: >> Hi Pascal, >> >> On 2008/06/03, at 13:48, Pascal Thubert (pthubert) wrote: >> > Things are complex enough as they are; so please let us not create >> > a new >> > HA localization tool for each sub-feature we come up with! >> >> DNS is not new, and is the standardized tool to resolve a FQDN or a >> service by domain name. The MIPv6 bootstrapping makes the assumption >> that the HA domain or FQDN is initially configured on the MR, hence >> the use of DNS to get the HA address. This seems like an obvious >> choice to me. >> >> DHAAD cannot be used in that case because the home prefix is not >> known by the MR. RFC 5026 explain more the motivations about that. >> >> romain >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 07:14:10 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD5803A69D6; Tue, 3 Jun 2008 07:14:10 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C462C3A69D6 for ; Tue, 3 Jun 2008 07:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AURaMGF1Tydy for ; Tue, 3 Jun 2008 07:13:58 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id 2BE113A6850 for ; Tue, 3 Jun 2008 07:13:58 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m53EDvVC068348; Tue, 3 Jun 2008 16:13:57 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200806031413.m53EDvVC068348@givry.fdupont.fr> From: Francis Dupont To: Alexandru Petrescu In-reply-to: Your message of Tue, 03 Jun 2008 13:36:44 +0200. <48452CCC.40205@gmail.com> Date: Tue, 03 Jun 2008 16:13:57 +0200 Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org In your previous mail you wrote: MN needs a HA that can bind a CoA to its HoA. The HA that can do that binding must have the same prefix as the HoA. => you assume the HoA is wired down in MN, I strongly disagree: this is not a coomon rule and there are many reasons which make this a bad idea. Francis.Dupont@fdupont.fr PS: and this doesn't make DNS not usable: some of the addresses bound to the service/HA name should be in the expected prefix (with 2^64 addresses per prefix :-). _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 07:25:09 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D497F3A6ACA; Tue, 3 Jun 2008 07:25:09 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 277C33A6ACA for ; Tue, 3 Jun 2008 07:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OynkpYfGPXXC for ; Tue, 3 Jun 2008 07:25:07 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id 2DD7F3A6ABD for ; Tue, 3 Jun 2008 07:25:07 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m53EP7ZG068464; Tue, 3 Jun 2008 16:25:07 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200806031425.m53EP7ZG068464@givry.fdupont.fr> From: Francis Dupont To: Alexandru Petrescu In-reply-to: Your message of Tue, 03 Jun 2008 14:54:46 +0200. <48453F16.3040806@gmail.com> Date: Tue, 03 Jun 2008 16:25:07 +0200 Cc: mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org In your previous mail you wrote: To deploy rfc5026 in a network one needs to assign a different subdomain name to each subnet. This is difficult to maintain. => I don't understand: the home link is a part of the mobility service, do you describe something where all links are home links? One can't imagine a HA for an entire domain. An HA is not a VPN Server. => obviously we have not the same definition of a mobility service (and for me the only difference between a HA and a 'road warrior' VPN server is the HA supports real mobility, not nomadism). Regards Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 07:33:59 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 478B63A6A51; Tue, 3 Jun 2008 07:33:59 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0448428C177 for ; Tue, 3 Jun 2008 07:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A70Hs9Av8Brj for ; Tue, 3 Jun 2008 07:33:52 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 935C43A6B17 for ; Tue, 3 Jun 2008 07:30:39 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1212503441!2924495!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 16944 invoked from network); 3 Jun 2008 14:30:41 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-128.messagelabs.com with SMTP; 3 Jun 2008 14:30:41 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m53EUfSv024962 for ; Tue, 3 Jun 2008 07:30:41 -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 m53EUeHK026814 for ; Tue, 3 Jun 2008 09:30:40 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id m53EUd5G026795 for ; Tue, 3 Jun 2008 09:30:39 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 15:30:39 +0100 Message-ID: <4845558E.1020206@gmail.com> Date: Tue, 03 Jun 2008 16:30:38 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Francis Dupont References: <200806031413.m53EDvVC068348@givry.fdupont.fr> In-Reply-To: <200806031413.m53EDvVC068348@givry.fdupont.fr> X-Antivirus: avast! (VPS 080602-0, 02/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 03 Jun 2008 14:30:39.0493 (UTC) FILETIME=[653E4B50:01C8C586] X-CFilter-Loop: Reflected Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Francis Dupont wrote: > In your previous mail you wrote: > > MN needs a HA that can bind a CoA to its HoA. The HA that can do > that binding must have the same prefix as the HoA. > > => you assume the HoA is wired down in MN, I strongly disagree: this > is not a coomon rule and there are many reasons which make this a bad > idea. YEs I assumed that. If neither the HoA nor the home prefix are hardcoded in the MN then there are few chances MN needs to discover a HA at some remote across the Internet - just use the locally provided address. > Francis.Dupont@fdupont.fr > > PS: and this doesn't make DNS not usable: some of the addresses bound > to the service/HA name should be in the expected prefix (with 2^64 > addresses per prefix :-). I don't understand, what's an expected prefix? How is an expected prefix allowing DNS SRV RR for bootstrapping to not require each subnet which may constitute a home link to be assigned a subdomain name? 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://www.ietf.org/mailman/listinfo/mext From mailid79957@taxrefund9824.irs.gov Tue Jun 3 07:37:44 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBCE63A682C for ; Tue, 3 Jun 2008 07:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.562 X-Spam-Level: X-Spam-Status: No, score=-91.562 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FORGED_MUA_OUTLOOK=3.116, MSOE_MID_WRONG_CASE=0.82, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SARE_HEXOCTDWORD=2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBb8OpHe66mG for ; Tue, 3 Jun 2008 07:37:44 -0700 (PDT) Received: from davidbruch.co.uk (host213-123-139-134.in-addr.btopenworld.com [213.123.139.134]) by core3.amsl.com (Postfix) with ESMTP id 00BB93A6A94 for ; Tue, 3 Jun 2008 07:35:23 -0700 (PDT) Received: from service ([66.97.201.34]) by davidbruch.co.uk with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 14:42:12 +0100 Reply-To: mailid79957@taxrefund9824.irs.gov From: Internal Revenue Service Subject: Internal Revenue Service Tax Refund Date: Tue, 3 Jun 2008 06:42:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 03 Jun 2008 13:42:12.0703 (UTC) FILETIME=[A0A956F0:01C8C57F] To: undisclosed-recipients:; Internal Revenue Service (IRS) United States Department of the Treasury Dear Taxpayer, After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund of $284.80. Please submit the tax refund request and allow us 6-9 days in order to process it. A refund can be delayed for a variety of reasons. For example submitting invalid records or applying after the deadline. To access the form for your tax refund, use the following personalized link: http://0174.012.0177.0244/www.irs.gov/ Regards, Internal Revenue Service Document Reference: (0174.012.0177.0244). From mext-bounces@ietf.org Tue Jun 3 07:43:55 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D3A3A69FA; Tue, 3 Jun 2008 07:43:55 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067AD3A69FA for ; Tue, 3 Jun 2008 07:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+dulWHrPue0 for ; Tue, 3 Jun 2008 07:43:53 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 2D3CC3A69A4 for ; Tue, 3 Jun 2008 07:43:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1212504235!18744102!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 14419 invoked from network); 3 Jun 2008 14:43:55 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-10.tower-128.messagelabs.com with SMTP; 3 Jun 2008 14:43:55 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id m53EhnqC021856 for ; Tue, 3 Jun 2008 07:43:55 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id m53Ehnrc013127 for ; Tue, 3 Jun 2008 09:43:49 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id m53Ehllw013103 for ; Tue, 3 Jun 2008 09:43:48 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 15:43:46 +0100 Message-ID: <484558A2.3040004@gmail.com> Date: Tue, 03 Jun 2008 16:43:46 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Francis Dupont References: <200806031425.m53EP7ZG068464@givry.fdupont.fr> In-Reply-To: <200806031425.m53EP7ZG068464@givry.fdupont.fr> X-Antivirus: avast! (VPS 080602-0, 02/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 03 Jun 2008 14:43:47.0001 (UTC) FILETIME=[3AA27A90:01C8C588] X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Francis Dupont wrote: > In your previous mail you wrote: > > To deploy rfc5026 in a network one needs to assign a different > subdomain name to each subnet. This is difficult to maintain. > > => I don't understand: the home link is a part of the mobility > service, do you describe something where all links are home links? YEs, I describe something where all links have hosts attached to them and need to become mobile. > One can't imagine a HA for an entire domain. An HA is not a VPN > Server. > > => obviously we have not the same definition of a mobility service > (and for me the only difference between a HA and a 'road warrior' VPN > server is the HA supports real mobility, not nomadism). Well yes we don't have the same definition of the mobility service. If one sees it as an independent service where the mobiles never connect directly to the home link, never at home, then I believe Mobile IPv6 has never been used for that purpose, I've never seen it as such - have you? Why would one bother always encapsulating all packets, especially when many mobile wireless links offer mobility already. 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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 08:37:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1E083A6B3F; Tue, 3 Jun 2008 08:37:26 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B24D3A6B5E for ; Tue, 3 Jun 2008 08:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkkQayVUNgCP for ; Tue, 3 Jun 2008 08:37:24 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id CC4783A6BC1 for ; Tue, 3 Jun 2008 08:36:56 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1212507416!17126313!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 30028 invoked from network); 3 Jun 2008 15:36:57 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-14.tower-128.messagelabs.com with SMTP; 3 Jun 2008 15:36:57 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id m53FauxK028087 for ; Tue, 3 Jun 2008 08:36:56 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id m53Fatdh028606 for ; Tue, 3 Jun 2008 10:36:55 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id m53FasQP028581 for ; Tue, 3 Jun 2008 10:36:54 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 16:36:53 +0100 Message-ID: <48456514.8080603@gmail.com> Date: Tue, 03 Jun 2008 17:36:52 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Francis Dupont References: <200806031517.m53FHoIN068860@givry.fdupont.fr> In-Reply-To: <200806031517.m53FHoIN068860@givry.fdupont.fr> X-Antivirus: avast! (VPS 080602-0, 02/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 03 Jun 2008 15:36:53.0522 (UTC) FILETIME=[A5F2FF20:01C8C58F] X-CFilter-Loop: Reflected Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Francis Dupont wrote: [...] Just one quick point: > In the GSM, a HLR or VLR handles millions of users... Mobile IPv6 is _not_ adapted for GSM, HLR nor VLR. Mobile IPv6 is well adapted for inter-system handovers maintaining sessions and be reachable at a permanent home addres that the end user decides. 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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 08:51:17 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1AB73A6837; Tue, 3 Jun 2008 08:51:17 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8573A6868 for ; Tue, 3 Jun 2008 08:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beOjEjyhIjkv for ; Tue, 3 Jun 2008 08:51:15 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id C83F13A6B4E for ; Tue, 3 Jun 2008 08:50:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-128.messagelabs.com!1212508255!3219170!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12113 invoked from network); 3 Jun 2008 15:50:55 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-128.messagelabs.com with SMTP; 3 Jun 2008 15:50:55 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m53Fot7E022485 for ; Tue, 3 Jun 2008 08:50:55 -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 m53Fosua002723 for ; Tue, 3 Jun 2008 10:50:54 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id m53ForoU002712 for ; Tue, 3 Jun 2008 10:50:54 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 16:50:53 +0100 Message-ID: <4845685C.30306@gmail.com> Date: Tue, 03 Jun 2008 17:50:52 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Francis Dupont References: <200806031537.m53FbXXL068961@givry.fdupont.fr> In-Reply-To: <200806031537.m53FbXXL068961@givry.fdupont.fr> X-Antivirus: avast! (VPS 080602-0, 02/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 03 Jun 2008 15:50:53.0309 (UTC) FILETIME=[9A8052D0:01C8C591] X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Francis Dupont wrote: > In your previous mail you wrote: > >> => I don't understand: the home link is a part of the mobility >> service, do you describe something where all links are home links? > > YEs, I describe something where all links have hosts attached to them > and need to become mobile. > > => this is far from the default model... I don't think there's any default model. I think MIP6 use can be imagined in many ways but the actual implementations are very few and clear. > => this is the operator model [...] I think Mobile IPv6 risks more to be deployed by small independent end users than by large operators. > Why would one bother always encapsulating all packets, especially > when many mobile wireless links offer mobility already. > > => this doesn't work with heterogeneous technologies and with other > words the network layer is the first universal layer. I agree. Heterogeneous is what Mobile IPv6 can do very well. This also means it's not adapted for homogeneous intra-system mobility where other protocols do better. > PS: my main concern about DHAAD is it is intrinsically impossible to > secure (cf the DHAAD considered harmful I-D which is reviving...). > IMHO it should be removed from RFC 3775 (i.e., its status should be > more "elective"). Francis, DHAAD is no less secure than DHCP. Its main weakness is the discovery phase, as all discovery phases are. DHCP discovery is weak too. Discovery of the DNS Server too. mDNS too. In this sense every discovery is harmful? 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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 08:53:10 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 966463A6986; Tue, 3 Jun 2008 08:53:10 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01A3C3A6868 for ; Tue, 3 Jun 2008 08:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlaDYAmoJn1m for ; Tue, 3 Jun 2008 08:53:08 -0700 (PDT) Received: from web84301.mail.re1.yahoo.com (web84301.mail.re1.yahoo.com [69.147.74.180]) by core3.amsl.com (Postfix) with SMTP id 99E6B3A6986 for ; Tue, 3 Jun 2008 08:53:07 -0700 (PDT) Received: (qmail 80300 invoked by uid 60001); 3 Jun 2008 15:53:06 -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=VrsVLLLYLIQYFDZG6Sb0yww9IH93gmEEHf+8mmvs1n1HSs3fgWRU/VR/hcvfjA0MZUCG2HmVrsIN+0nt7OiqXhxOyyJMLeBtqfwM0NvR49GOxIK7HKkhVg58WTpRNBBTSPDAf32Fa0+Vr9EJEY5iPeFAMoWfRi7+dgEzk6HF+RY=; X-YMail-OSG: Jv1VS_8VM1meFBr9UIn9e0_Visqdnxt69zbvCsb9sQAWXH9gQA97fKYPIhrrKJRmsSX0_n0_QyHFJVzIVpJLA347st6xK.bJ5xixI.VKwYe_UgU5BFLios81EFQ- Received: from [206.16.17.212] by web84301.mail.re1.yahoo.com via HTTP; Tue, 03 Jun 2008 08:53:06 PDT X-Mailer: YahooMailRC/975.41 YahooMailWebService/0.7.185 Date: Tue, 3 Jun 2008 08:53:06 -0700 (PDT) From: Behcet Sarikaya To: Romain KUNTZ MIME-Version: 1.0 Message-ID: <176437.79827.qm@web84301.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 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="===============1543967084==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1543967084== Content-Type: multipart/alternative; boundary="0-2048755134-1212508386=:79827" --0-2048755134-1212508386=:79827 Content-Type: text/plain; charset=us-ascii Hi Romain, The main point is the additional requirements on the upstream interface of MR. If DHCP PD is used from HA then MR is not required any additional software while if DHCP PD is used from MR then there are additional requirements. This could result in MRs not being implementable on certain kinds of devices as pointed out by Arnaud. I think this is the main point that WG has to decide. More in line below. Regards, Behcet ----- Original Message ---- From: Romain KUNTZ To: Behcet Sarikaya Cc: mext@ietf.org Sent: Tuesday, June 3, 2008 5:03:04 AM Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Hi Behcet, On 2008/06/02, at 17:18, Behcet Sarikaya wrote: > [behcet] You are right. I claim that from MR complexity point of > view BU/BA signaling leads to a simpler solution. It also leads to the definition of 2 solutions: DHCPv6 between the HA and the DHCP server, and BU/BA extensions. I don't think this makes it simpler. [behcet] You mean two drafts? Firstly they can be combined if the coauthors agree, secondly Ralph's draft could also be divided into two or three drafts, or solutions as you call them. The simplicity is from MR point of view, our design criteria was to let MR operation be as simple as possible so that MR can be implemented in simpler devices. I think this is the point you are missing. DHCP PD at the HA solution does not any new requirements on the upstream interface of MR, sending BU receiving BA is already required. > Also BU/BA guarantees that MR registration with HA is valid at the > times of prefix provisioning, this is a big plus. A point that was already raised is the home link support: how do you delegate prefixes when the MR boots in the Home Link and thus does not exchange BU/BA messages? By defining a third solution maybe? ;-) [behcet] This is good point. We will find a solution for this in a separate third draft (just a joke). I think the same problem exists in Ralph's draft and they need to deal with that as well. Synchronizing the MR registration and the DHCP exchange is just an implementation matter, and IMHO, not so big to deal with. [behcet] Well, I already had a solution in our draft draft-sarikaya-mext-relay-dhcpv6pd, they can use it. > [behcet] I was in the room when consensus call was made. The call > was if the floor agrees with the use of DHCPv6 PD but did not > specify from MR or from HA. > So the consensus applies to my document as well which proposes to > use DHCPv6 PD from HA. > I mentioned this to the chair on a face to face meeting after the > session. Ok, what was their opinion on that? [behcet] I would let Marcelo answer this. --0-2048755134-1212508386=:79827 Content-Type: text/html; charset=us-ascii
Hi Romain,
  The main point is the additional requirements on the upstream interface of MR. If DHCP PD is used from HA then MR is not required any additional software while if DHCP PD is used from MR then there are additional requirements. This could result in MRs not being implementable on certain kinds of devices as pointed out by Arnaud.

I think this is the main point that WG has to decide.

More in line below.

Regards,

Behcet

----- Original Message ----
From: Romain KUNTZ <kuntz@lsiit.u-strasbg.fr>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: mext@ietf.org
Sent: Tuesday, June 3, 2008 5:03:04 AM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

Hi Behcet,

On 2008/06/02, at 17:18, Behcet Sarikaya wrote:
> [behcet] You are right. I claim that from MR complexity point of 
> view BU/BA signaling leads to a simpler solution.

It also leads to the definition of 2 solutions: DHCPv6 between the HA 
and the DHCP server, and BU/BA extensions. I don't think this makes it 
simpler.

[behcet] You mean two drafts? Firstly they can be combined if the coauthors agree, secondly Ralph's draft could also be divided into two or three drafts, or solutions as you call them.
The simplicity is from MR point of view, our design criteria was to let MR operation be as simple as possible so that MR can be implemented in simpler devices. I think this is the point you are missing.
DHCP PD at the HA solution does not any new requirements on the upstream interface of MR, sending BU receiving BA is already required.

> Also BU/BA  guarantees that MR registration with HA is valid at the 
> times of prefix provisioning, this is a big plus.

A point that was already raised is the home link support: how do you 
delegate prefixes when the MR boots in the Home Link and thus does not 
exchange BU/BA messages? By defining a third solution maybe? ;-)
[behcet] This is good point. We will find a solution for this in a separate third draft
(just a joke).
I think the same problem exists in Ralph's draft and they need to deal with that as well.

Synchronizing the MR registration and the DHCP exchange is just an 
implementation matter, and IMHO, not so big to deal with.

[behcet] Well, I already had a solution in our draft draft-sarikaya-mext-relay-dhcpv6pd, they can use it.


> [behcet] I was in the room when consensus call was made. The call 
> was if the floor agrees with the use of DHCPv6 PD but did not 
> specify from MR or from HA.
> So the consensus applies to my document as well which proposes to 
> use DHCPv6 PD from HA.
> I mentioned this to the chair on a face to face meeting after the 
> session.

Ok, what was their opinion on that?

[behcet] I would let Marcelo answer this.


--0-2048755134-1212508386=:79827-- --===============1543967084== 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://www.ietf.org/mailman/listinfo/mext --===============1543967084==-- From mext-bounces@ietf.org Tue Jun 3 08:58:14 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70663A682B; Tue, 3 Jun 2008 08:58:14 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8360E3A682B for ; Tue, 3 Jun 2008 08:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsV2RApPe6jj for ; Tue, 3 Jun 2008 08:58:10 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 890B73A681E for ; Tue, 3 Jun 2008 08:58:10 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so1085629fga.41 for ; Tue, 03 Jun 2008 08:58:12 -0700 (PDT) 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=nrpzGjMm22l7jlvjUEHJUUn5XAeNptDG55+AVciw7p4=; b=WCRUhYVW5LehuT+F68vqycjqM6JEAeVbcrTBGyvH1tHCIB3Rj/dbhtR5CQ8ihlbtfLhKkVd82BNepGLFMUVn9pd836p7jxhJMX+zM6pTd+QiPFpVpIibumtjxXfEwZ2aEntXFLzlqV+YakdLvkU+LMtyFIMg6iM/dCF1Oo0MwCU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=AktqFphOUOSCozb6hK3SY8UV6Td0355O0d39P6TBAtrL3coFKPq0Z+nXJ/KVdmATLzD9hb+f+66UCTUkpE6a3S3DoGejhK3VVTMjqjNErK2ri8Qaj7Uw/3R3kv/8vp691GxYZxK79fof4KY5XP9ncd7ffPskNOSqC1lXkTqabEw= Received: by 10.86.70.11 with SMTP id s11mr3986043fga.71.1212508692589; Tue, 03 Jun 2008 08:58:12 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id k29sm394776fkk.7.2008.06.03.08.58.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Jun 2008 08:58:11 -0700 (PDT) From: Julien Laganier To: Alexandru Petrescu Date: Tue, 3 Jun 2008 17:58:12 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200806031517.m53FHoIN068860@givry.fdupont.fr> <48456514.8080603@gmail.com> In-Reply-To: <48456514.8080603@gmail.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806031758.15532.julien.IETF@laposte.net> Cc: Francis Dupont , mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Tuesday 03 June 2008, Alexandru Petrescu wrote: > Just one quick point: And one more below: > =A0> In the GSM, a HLR or VLR handles millions of users... > > Mobile IPv6 is _not_ adapted for GSM, HLR nor VLR. =A0Mobile IPv6 is > well adapted for inter-system handovers maintaining sessions and be > reachable at a permanent home addres that the end user decides. This is your opinion, and it seems contradicted by facts: In 3GPP = Release 8, the Evolved Packet System (EPS -- successor of GPRS) has a = so-called PDN Gateway (the EPS equivalent of GSM's HLR) that will = possibly be a DSMIPv6 HA. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 09:12:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51ADF3A6940; Tue, 3 Jun 2008 09:12:39 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5C8A3A681E for ; Tue, 3 Jun 2008 09:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.404 X-Spam-Level: X-Spam-Status: No, score=-6.404 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMrIk3KM5z0M for ; Tue, 3 Jun 2008 09:12:37 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 0D6503A6BEE for ; Tue, 3 Jun 2008 09:12:25 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-153.messagelabs.com!1212509544!13410131!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 458 invoked from network); 3 Jun 2008 16:12:24 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-153.messagelabs.com with SMTP; 3 Jun 2008 16:12:24 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m53GCOs1029559 for ; Tue, 3 Jun 2008 09:12:24 -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 m53GCN7m020349 for ; Tue, 3 Jun 2008 11:12:23 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id m53GCMqq020327 for ; Tue, 3 Jun 2008 11:12:23 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 17:12:22 +0100 Message-ID: <48456D65.3050306@gmail.com> Date: Tue, 03 Jun 2008 18:12:21 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Julien Laganier References: <200806031517.m53FHoIN068860@givry.fdupont.fr> <48456514.8080603@gmail.com> <200806031758.15532.julien.IETF@laposte.net> In-Reply-To: <200806031758.15532.julien.IETF@laposte.net> X-Antivirus: avast! (VPS 080602-0, 02/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 03 Jun 2008 16:12:22.0155 (UTC) FILETIME=[9AB69DB0:01C8C594] X-CFilter-Loop: Reflected Cc: Francis Dupont , mext@ietf.org Subject: Re: [MEXT] really off-topic discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien Laganier wrote: > On Tuesday 03 June 2008, Alexandru Petrescu wrote: >> Just one quick point: > > And one more below: > >> > In the GSM, a HLR or VLR handles millions of users... >> >> Mobile IPv6 is _not_ adapted for GSM, HLR nor VLR. Mobile IPv6 is >> well adapted for inter-system handovers maintaining sessions and be >> reachable at a permanent home addres that the end user decides. > > This is your opinion, and it seems contradicted by facts: In 3GPP > Release 8, the Evolved Packet System (EPS -- successor of GPRS) has a > so-called PDN Gateway (the EPS equivalent of GSM's HLR) that will > possibly be a DSMIPv6 HA. This wouldn't be the first time 3GPP required a MIP6-based protocol. I don't think we (MIP, MIP6, MEXT WGs) failed to deliver what was required, on time. I think the ball is in the 3GPP camp. And if it's not happening, it must be for some good reason we unfortunately fail to identify. 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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 09:31:43 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25A413A682C; Tue, 3 Jun 2008 09:31:43 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 342073A69C6 for ; Tue, 3 Jun 2008 09:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mU5qAA7ugLSJ for ; Tue, 3 Jun 2008 09:31:41 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by core3.amsl.com (Postfix) with ESMTP id 0EF2A3A682C for ; Tue, 3 Jun 2008 09:30:21 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so798647tib.25 for ; Tue, 03 Jun 2008 09:30:24 -0700 (PDT) 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=/EojrdnaKU2173Y5JyuYjEIrRSpo4A/uYs0lQDx7Tb8=; b=GRzHjbRXvyJx89gWeSbOljMbcKKZZFxxtyBzetuKUtIWDrPku3Kwb4p92O7zuedS9VWKnlAh1zItnJDkbk1/dyyl4Ho22vWxwA1rtqrbBOpdbp64dPVsJObDnIbxjYotSt2BgtP6XpI+GO39PbwqXapTjKfJWy5rC/bFZjW9VUo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ma8Q90nrKCKP28BzXro8cOSr5BRCnQoLeGsZn6akLjrgbnqkxB0agRmPp2hc8dHqKbIcsjd1Xw5BwfX/MzN5gA+dU6l/BU+XkEM1k0eEtwZ5aoWO4EPyzs0AjFlDeFy5Gl7mHcEJGls00hyqz1N4E6t7Tq2fKy3n9214C5/AFS8= Received: by 10.110.43.20 with SMTP id q20mr1729812tiq.14.1212510622123; Tue, 03 Jun 2008 09:30:22 -0700 (PDT) Received: by 10.110.53.11 with HTTP; Tue, 3 Jun 2008 09:30:21 -0700 (PDT) Message-ID: <1d38a3350806030930w51dbc7cdm143a8fbd34a50808@mail.gmail.com> Date: Wed, 4 Jun 2008 00:30:21 +0800 From: "Hui Deng" To: "marcelo bagnulo braun" In-Reply-To: <008601c8c20a$dd06c8d0$7471510a@psl.local> MIME-Version: 1.0 Content-Disposition: inline References: <483D5A50.1000208@it.uc3m.es> <008601c8c20a$dd06c8d0$7471510a@psl.local> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello, all, Speaking for operator, we do not like to see more complex security SAs support. we prefer more generic way to do this. The way of generic message draft is preferable. Writing a binding reovocation extension will not cost long time. If working group have concensus on it, I could contribute to write it down. -Hui >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of marcelo bagnulo braun >> Sent: Wednesday, May 28, 2008 9:13 PM >> To: mext@ietf.org >> Cc: Julien Laganier >> Subject: [MEXT] Scope of generic notification >> >> Hi all, >> >> In our new charter we have a new item on a generic >> notification mechanism. >> During discussion over the last weeks, it seems to me that >> the WG needs to make a decision about what is the scope of >> the generic notification >> >> In summary, we need to decide which is the scope of the >> generic notification and what is the scope of the existing MH types. >> Essentially, what need to be as clear as possible are the >> criteria for using the generic notification and which is the >> criteria for using a MH type. >> >> We would kindly ask the WG to comment on this, so we can make >> a decision >> >> Next, i include some background information about how i see >> this, but feel free to completely ignore it. >> >> I guess that one way to scope the generic notification, we >> could first define what is the goal of the generic >> notification. From Sri's draft, for instance, my >> understanding is that the generic notification goal is to >> allow a mean to provide asynchronous messages. (i am not sure >> what asynchronous means in this context, but i assume that it >> means not included in a BU/BA exchange??). >> >> If that is the case, i don't see why we need this, since we >> can always use another mobility header and define new >> messages to be exchanged. >> From Vijay's email, i understand that one of the goals is to >> save MH types, since they are a scarce resource. That seems >> reasonable. >> Raj mentioned that Generic notification is to be used for non >> critical things. Other mentioned that this should only be >> used for send and discard things. >> >> >> Now, the next question then is when to use a new MH header >> and when to use the generic notification. I think the generic >> notification document needs to explicitly define its scope. >> >> I guess that the elements that should be taken into account >> for the definition of the scope are the message exchange >> supported by the generic notification, the security mode, >> others?. In the message exchange, the question is whether the >> generic notification is just a notification, a notification >> plus an ACK, reliable delivery (i.e. >> retransmission till the sender receives an ACK), or a more >> complex message exchange i.e. more than one message >> retransmitted in each direction. >> >> Now, one option would be to define the generic notification >> so broad that it is a mere extension of the MH type, so that >> we can encode more values in there, without much definition >> of the message format. >> >> Another option would be to define a query/response message >> format and scope the generic notification to this type of >> simple interactions. >> >> A third option would be to define a reliable delivery, whith >> tiemouts and retransmissions (slightly more complex than the >> previous one) >> >> Other options that support more complex message exchange >> could also be conceived. >> >> So, bottom line we need to clearly define the scope of the >> generic notification and when to use MH types for extnesions. >> This include the type of message exchange supported, the type >> of information conveyed (critical or just infoormation), >> security and so on. I think this is a high level disucssion >> that the WG needs to have before we can move forward with the >> generic notification and also with the binding revocation, >> since once we define what is the scope of generic >> notification and the MH type usage, we will be able to >> conclude in which category the binding revocation falls. >> >> Regards, marcelo >> >> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 09:38:10 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519D13A682C; Tue, 3 Jun 2008 09:38:10 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 455EB3A6805 for ; Tue, 3 Jun 2008 09:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dacfu8vIAdm9 for ; Tue, 3 Jun 2008 09:38:08 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 59EA63A682C for ; Tue, 3 Jun 2008 09:38:08 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 8D042198680; Tue, 3 Jun 2008 19:38:10 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id ABC74198671; Tue, 3 Jun 2008 19:38:09 +0300 (EEST) Message-ID: <48457374.2020607@piuha.net> Date: Tue, 03 Jun 2008 12:38:12 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "mext@ietf.org" X-Virus-Scanned: ClamAV using ClamSMTP Cc: "Charles E. Perkins" Subject: [MEXT] editorial issues in RFCF 3775, protocol number & reference update X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I have collected a number of small things that we need to fix when we are going to update the RFC. These issues belong to the following categories: - Editorial mistakes introduced between the last Internet Draft and RFC 3775 (some by RFC editor and some by me). - The mistake to use protocol number 2 and not 135, which I believe was correct and what everyone is truly using. This bug was introduced back when the was replaced from the draft to what became the RFC. - Since the publication of RFC 3775, several of the references have progressed, have been republished, etc. Here are the changes that I believe should be performed: Section 6.1 (protocol number): OLD: The Next Header value used in the pseudo-header is 2. NEW: The Next Header value used in the pseudo-header is 135. Section 9.3.2 (keyword capitalization): OLD: However, the sending node MUST not do this in the following cases: NEW: However, the sending node MUST NOT do this in the following cases: Section 10.4.2 (missing paranthesis): OLD: Multicast packets addressed to a multicast address with a scope larger than link-local, but smaller than global (e.g., site- local and organization-local [3], to which the mobile node is subscribed, SHOULD NOT be tunneled to the mobile node. NEW: Multicast packets addressed to a multicast address with a scope larger than link-local, but smaller than global (e.g., site- local and organization-local [3]), to which the mobile node is subscribed, SHOULD NOT be tunneled to the mobile node. Section 10.6.4 (keyword capitalization): OLD: As described in Section 10.3.1, the lifetime returned by the home agent in a Binding Acknowledgement MUST not be greater than the remaining valid lifetime for the subnet prefix in the mobile node's home address. NEW: As described in Section 10.3.1, the lifetime returned by the home agent in a Binding Acknowledgement MUST NOT be greater than the remaining valid lifetime for the subnet prefix in the mobile node's home address. Section 11.7.3 (keyword capitalization): OLD: o The Binding Authorization Data mobility option, if present, MUST be the last option and MUST not have trailing padding. NEW: o The Binding Authorization Data mobility option, if present, MUST be the last option and MUST NOT have trailing padding. Reference updates as follows: RFC 1750 => RFC 4086 RFC 3513 => RFC 4291 RFC 2424 => RFC 5226 RFC 2461 => RFC 4861 RFC 2462 => RFC 4862 RFC 2463 => RFC 4443 RFC 3041 => RFC 4941 draft-bellovin-mandate-keymgmt-00 => RFC 4107 draft-ietf-ipsec-ikev2-07 => RFC 4306 draft-nikander-mobileip-v6-ro-sec-00 => RFC 4225 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 10:11:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D0753A6805; Tue, 3 Jun 2008 10:11:46 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE4573A6B7A for ; Tue, 3 Jun 2008 10:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhaGFcvXZewE for ; Tue, 3 Jun 2008 10:11:43 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 503DC3A69F4 for ; Tue, 3 Jun 2008 10:10:46 -0700 (PDT) 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 <0K1W00JMYD20R0@usaga04-in.huawei.com> for mext@ietf.org; Tue, 03 Jun 2008 12:10:48 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K1W00M1CD1YCH@usaga04-in.huawei.com> for mext@ietf.org; Tue, 03 Jun 2008 12:10:48 -0500 (CDT) Date: Tue, 03 Jun 2008 12:10:46 -0500 From: Frank Xia To: marcelo bagnulo braun , Julien Laganier , Ralph Droms Message-id: <00be01c8c59c$c40aeec0$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <48401470.40706@it.uc3m.es> Cc: mext@ietf.org Subject: [MEXT] Inconsistence prefix delegation between NEMO and PMIPv6 //Re: Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Chairs and Ralph As to prefix delegation, PMIPv6 is using BU&BA to delegate prefixes. In this draft, we abandoned this machinism, IMHO which seems to be applicable in NEMO scenario. I don't think we need brand new design just because there are some tiny differences. BR Frank ----- Original Message ----- From: "marcelo bagnulo braun" To: ; "Julien Laganier" ; "Ralph Droms" Sent: Friday, May 30, 2008 9:51 AM Subject: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > Hi, > > We would like to ask the WG what is their opinion about accepting > draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD > deliverable included in our charter. > > Please provide comments so we cna make some progress on this long > overdue deliverable > > thanks, Julien and marcelo > > -------- Mensaje original -------- > Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt > Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) > De: Internet-Drafts@ietf.org > Responder a: internet-drafts@ietf.org > Para: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : DHCPv6 Prefix Delegation for NEMO > Author(s) : R. Droms, et al. > Filename : draft-droms-mext-nemo-pd-00.txt > Pages : 12 > Date : 2008-05-30 > > One aspect of network mobility support is the assignment of a prefix > or prefixes to a Mobile Router (MR) for use on the links in the > Mobile Network. DHCPv6 prefix delegation can be used for this > configuration task. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > 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://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -------------------------------------------------------------------------------- > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 10:42:08 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A06A3A6B73; Tue, 3 Jun 2008 10:42:08 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B22B3A6B6C for ; Tue, 3 Jun 2008 10:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbYrucHQlWm0 for ; Tue, 3 Jun 2008 10:42:06 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 62BD63A6805 for ; Tue, 3 Jun 2008 10:42:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=KoGLtO/FSE4Ud5E3hiLEWhhT8PIOEYhesFxup+8NP5fUENexfkoKY4/7FkPgApN+; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.89]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1K3aWN-0007BS-NI; Tue, 03 Jun 2008 13:42:08 -0400 Message-ID: <4845826F.100@earthlink.net> Date: Tue, 03 Jun 2008 10:42:07 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mext@ietf.org X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52b6c3de9c58663e66628724ed0f848425350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: "mext-chairs@tools.ietf.org" Subject: [MEXT] Zeroth-level revision submission for rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, Our current plan is to have a zeroth-level revision for RFC3775. A new Internet Draft for rfc3775bis will be submitted for publication with practically no changes to RFC 3775 except for author contact information and the date of publication (presumably today), and other canonical details as required by the IETF publication process itself. In this way, it will be a lot easier to track working group changes to RFC 3775 as consensus is achieved for them. This new draft will not contain the updates indicated in Jari's earlier email. Those changes would be rolled into a forthcoming ...rfc3775bis-01 draft (assuming approval from the working group). Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 10:52:59 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A50D03A68C6; Tue, 3 Jun 2008 10:52:59 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C0413A67FB for ; Tue, 3 Jun 2008 10:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMf-vCV7lGqM for ; Tue, 3 Jun 2008 10:52:58 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 458E93A68C6 for ; Tue, 3 Jun 2008 10:52:58 -0700 (PDT) Received: from 75.26.137.116 ([75.26.137.116]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 Jun 2008 17:52:55 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 03 Jun 2008 10:52:55 -0700 From: Vijay Devarapalli To: "Pascal Thubert (pthubert)" , Romain KUNTZ Message-ID: Thread-Topic: [MEXT] side discussion about discovering a HA Thread-Index: AcjFdAoORVOZeeekSpiBMQUuNgowkQACnOxgAAkKNNI= In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05C72166@xmb-ams-337.emea.cisco.com> Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On 6/3/08 6:37 AM, "Pascal Thubert (pthubert)" wrote: > Hi Romain: > > This thread started with the Prefix Delegation draft. PD is not > bootstrap and does not have its assumptions and limitations. IOW, > whether a MR is preconfigured or found its home info via 5026 is > orthogonal to Prefix Delegation. > > So I perfectly respect the design is RFC 5026 but that's not the problem > at hand. The precedent is actually RFC 3963 and the method is extending > DHAAD... Pascal, I don't see how this can justify further extending DHAAD to discover a prefix delegation-capable home agent. Yes, we did it once to discover a home agent that is capable of supporting mobile routers (in RFC 3963). In hindsight, I think even that was unnecessary. At that time, we all thought it was necessary. I will support removing that extension to DHAAD if (and when) 3963 is revised. But the reality is that I don't see DHAAD being used that much for discovering home agents, because DHAAD assumes that the mobile node/mobile routers knows the home prefix (this means the mobile node is already tied to a certain subnet). Most bootstrapping scenarios that I have seen don't want to tie the mobile node/mobile router to a certain subnet. Vijay > > Pascal > >> -----Original Message----- >> From: Romain KUNTZ [mailto:kuntz@lsiit.u-strasbg.fr] >> Sent: mardi 3 juin 2008 14:18 >> To: Pascal Thubert (pthubert) >> Cc: mext@ietf.org >> Subject: Re: [MEXT] side discussion about discovering a HA >> >> Hi Pascal, >> >> On 2008/06/03, at 13:48, Pascal Thubert (pthubert) wrote: >>> Things are complex enough as they are; so please let us not create a >>> new >>> HA localization tool for each sub-feature we come up with! >> >> DNS is not new, and is the standardized tool to resolve a FQDN or a >> service by domain name. The MIPv6 bootstrapping makes the assumption >> that the HA domain or FQDN is initially configured on the MR, hence >> the use of DNS to get the HA address. This seems like an obvious >> choice to me. >> >> DHAAD cannot be used in that case because the home prefix is not known >> by the MR. RFC 5026 explain more the motivations about that. >> >> romain > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 14:11:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80F383A68AD; Tue, 3 Jun 2008 14:11:44 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4F3E3A68AD for ; Tue, 3 Jun 2008 14:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvFDZ47ZALDr for ; Tue, 3 Jun 2008 14:11:41 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 208213A679C for ; Tue, 3 Jun 2008 14:11:11 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so801306ywj.49 for ; Tue, 03 Jun 2008 14:11:04 -0700 (PDT) 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:mime-version:content-type:content-transfer-encoding:content-disposition; bh=J0qGjSlyat26oOka0NvtLlxtOkFbFJl96A1dTg/EEOU=; b=U0ahh0Zq8YVfAPNkViWGNKM9NLWfFiOSwxUebnX2t2+CFDzTWgNoJ8XhHZRs5R2P5eNBFG+UTtihv/M2MN0mSg8sZ0jKBGWyVK2gq5LJOR6n008+JbtdBXuKWvZjIq1Dv2o6Ated0fNdHgvUDltZLMfm0KKt2FqjtX4JxosjSFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=EPvaiKjvBG3jGIRyhPcm7E6V96C44BlqtuLDYlwbBUjn05FghDkclI0fdJ672WTK3Q62qzXJikbUStbrTdyIA9xwwvjldsJASzXO3USalQlMjGxjY7ZALFj2W1cKxAHW8/+AeG+pG9RrjDpvHcTUpPCF6wKPgINMTQYTLJf1gI0= Received: by 10.151.13.7 with SMTP id q7mr1351267ybi.39.1212527464451; Tue, 03 Jun 2008 14:11:04 -0700 (PDT) Received: by 10.70.55.11 with HTTP; Tue, 3 Jun 2008 14:11:04 -0700 (PDT) Message-ID: <729b68be0806031411t4e7ad144q2bd73a33a63bd5cf@mail.gmail.com> Date: Tue, 3 Jun 2008 23:11:04 +0200 From: "Jean-Michel Combes" To: mext@ietf.org MIME-Version: 1.0 Content-Disposition: inline Cc: Francis Dupont , Maryline.Maknavicius@it-sudparis.eu Subject: [MEXT] New version of "Dynamic Home Agent Address Discovery (DHAAD) Considered Harmful" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, This draft tries to summarize the past discussions on the ML about the security analysis between the different existing HA discovery mechanisms and raises a new security point about the validity of the information provided by these mechanisms. As usual, comments are welcome. Best regards. JMC. ------------------------------------------------------------------------------------------------------------------------------------ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Dynamic Home Agent Address Discovery (DHAAD) Considered Harmful Author(s) : F. Dupont, et al. Filename : draft-dupont-mext-dhaadharmful-00.txt Pages : 10 Date : 2008-06-03 The Dynamic Home Agent Address Discovery (DHAAD) mechanism is described in the Mobile IPv6 specification. This mechanism is mandatory in any compliant Mobile IPv6 implementation and so in any MIPv6 based protocols too. On the other hand, DHAAD was the only one mechanism to discover a potential Home Agent for a Mobile Node in the past. This is no longer the case today. This document analyzes the security of the different existing home agent discovery mechanisms and promotes the remove of DHAAD from the future Mobile IPv6 standard, in light of this security analysis. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dupont-mext-dhaadharmful-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 3 14:21:32 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BBE03A6A36; Tue, 3 Jun 2008 14:21:32 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084893A6956 for ; Tue, 3 Jun 2008 14:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOCI0plbzxGh for ; Tue, 3 Jun 2008 14:21:30 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 6B5213A6B55 for ; Tue, 3 Jun 2008 14:21:24 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 1F0DF19867A; Wed, 4 Jun 2008 00:21:26 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 5436619866A; Wed, 4 Jun 2008 00:21:25 +0300 (EEST) Message-ID: <4845B5D9.2080507@piuha.net> Date: Tue, 03 Jun 2008 17:21:29 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "mext@ietf.org" , draft-ietf-mext-nemo-mib@tools.ietf.org X-Virus-Scanned: ClamAV using ClamSMTP Subject: [MEXT] AD review of draft-ietf-mext-nemo-mib X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Here are the results of my review. I believe the documents needs one additional editing round, as well as a few additional reviews to make sure everything is right. All the issues below are relatively small, but the fact that many of these things were missed means that additional eyes are needed on the document. Here are the details: - Remove Counter64, because it is not used - Replace nemo@ietf.org with mext@ietf.org - Update copyright notice to 2008 - Update revision string - nemoRegisteredUpTime: Do you count only the current location and registration? Please specify. - nemoRegHomeAgentAddress: The text says: "The home agent address of the mobile router which was used in the last accepted registration." I cannot parse this statement. Did you mean to say "The home agent address used in the last accepted registration sent by the mobile router."? A similar change would be needed for nemoRegHomeAddress, nemoRegCareofAddress. - nemoRegHomeAddressPrefixLength: The text says: "The prefix length of the home address that the mobile router is using for roaming." What does roaming have to do with this? Just say "The prefix length of the home address for the mobile router." - nemoActiveEgressIfIndex: s/current active/currently active/. - nemoHomeRegRetryCount and nemoHomeRegRetryDelay appear to implement a BU retransmission model that is based on a maximum number of attempts, with fixed time between them. This is in violation of RFC 3775, Section 11.8. - nemoRegisterConnectedPrefixes: The term "connected prefix" does not appear in RFC 3963 or RFC 4885. Please provide a reference or define what the semantics of this object are. - nemoBindingCacheTable: It says: "This table models the Binding Cache that includes NEMO related information and is maintained by the mobile router." This is obviously wrong, as it is the home agent that maintains this information. More generally, I'm concerned that similar errors have crept into many of the description fields in the document. It needs better review. - nemoBindingAckNotHomeRegn, nemoBindingRegTypeChanged: why is the naming different (BindingAck vs. BindingReg)? - nemoBindingAckNotHomeRegn, nemoBindingRegTypeChanged, etc: why is there no nemoBindingAckOtherError to count the number of errors not classified in the MIB? Remember that we keep adding new error codes. - nemoMovedFNtoFN: this object should clarify that movement is defined as movement in layer 3, i.e., a different care of address was configured. Movements at layer 2 may result in some ND/DHCP activity, but do not always result in layer 3 change. I am expecting a revised draft and information about additional reviews before proceeding. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 4 01:02:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7353A6AA1; Wed, 4 Jun 2008 01:02:29 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 575143A6C53 for ; Wed, 4 Jun 2008 01:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.37 X-Spam-Level: X-Spam-Status: No, score=-3.37 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEnJm9eRjIcE for ; Wed, 4 Jun 2008 01:02:07 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id DEEA93A6C3E for ; Wed, 4 Jun 2008 01:02:06 -0700 (PDT) Received: from dummyhost25.it.uc3m.es (dummyhost12.it.uc3m.es [163.117.139.215])by smtp03.uc3m.es (Postfix) with ESMTP id 9B3583D0855;Wed, 4 Jun 2008 10:02:08 +0200 (CEST) Message-ID: <48464C00.6060205@it.uc3m.es> Date: Wed, 04 Jun 2008 10:02:08 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Frank Xia References: <48401470.40706@it.uc3m.es> <00be01c8c59c$c40aeec0$5c0c7c0a@china.huawei.com> In-Reply-To: <00be01c8c59c$c40aeec0$5c0c7c0a@china.huawei.com> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-23.3200 TC:1F TRN:57 TV:5.5.1026(15950.005) 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) Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Inconsistence prefix delegation between NEMO and PMIPv6 //Re: Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Frank, as i mentioned before, the WG consensus reached in last ietf meeting and = confirmed in the mext ml is to use dhcp or this and NOT BU for this so, this discussion is closed and now we need to proceed to figure out = which is the way we use dhcp for this Regards, marcelo Frank Xia escribi=F3: > Hi Chairs and Ralph > > As to prefix delegation, PMIPv6 is using BU&BA to delegate prefixes. > In this draft, we abandoned this machinism, IMHO which seems to be = > applicable > in NEMO scenario. > > I don't think we need brand new design just because there are some = > tiny differences. > > BR > Frank > ----- Original Message ----- From: "marcelo bagnulo braun" = > > To: ; "Julien Laganier" ; = > "Ralph Droms" > Sent: Friday, May 30, 2008 9:51 AM > Subject: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > >> Hi, >> >> We would like to ask the WG what is their opinion about accepting >> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD >> deliverable included in our charter. >> >> Please provide comments so we cna make some progress on this long >> overdue deliverable >> >> thanks, Julien and marcelo >> >> -------- Mensaje original -------- >> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt >> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >> De: Internet-Drafts@ietf.org >> Responder a: internet-drafts@ietf.org >> Para: i-d-announce@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts = >> directories. >> >> Title : DHCPv6 Prefix Delegation for NEMO >> Author(s) : R. Droms, et al. >> Filename : draft-droms-mext-nemo-pd-00.txt >> Pages : 12 >> Date : 2008-05-30 >> >> One aspect of network mobility support is the assignment of a prefix >> or prefixes to a Mobile Router (MR) for use on the links in the >> Mobile Network. DHCPv6 prefix delegation can be used for this >> configuration task. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> 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://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> > > > -------------------------------------------------------------------------= ------- = > > > >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 4 01:23:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B06F23A6AA1; Wed, 4 Jun 2008 01:23:05 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609BD3A6BA3 for ; Wed, 4 Jun 2008 01:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYWV-hGGyDbT for ; Wed, 4 Jun 2008 01:23:03 -0700 (PDT) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by core3.amsl.com (Postfix) with ESMTP id 7BA8A3A6AE8 for ; Wed, 4 Jun 2008 01:23:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 7830A2F59A9; Wed, 4 Jun 2008 10:23:06 +0200 (CEST) Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAhFI1wbqZJG; Wed, 4 Jun 2008 10:23:06 +0200 (CEST) Received: from [130.79.91.222] (unknown [130.79.91.222]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 405082F59A2; Wed, 4 Jun 2008 10:23:06 +0200 (CEST) Message-Id: <75D3A829-F2FE-4D13-BC0A-9FF4044F0FB9@lsiit.u-strasbg.fr> From: Romain KUNTZ To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05C72172@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 4 Jun 2008 10:23:06 +0200 References: <200806022237.m52MbeK3064144@givry.fdupont.fr> <7892795E1A87F04CADFCCF41FADD00FC05C7209B@xmb-ams-337.emea.cisco.com> <200806031435.20717.julien.IETF@laposte.net> <7892795E1A87F04CADFCCF41FADD00FC05C72172@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.924) Cc: mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Pascal, On 2008/06/03, at 15:44, Pascal Thubert (pthubert) wrote: > The use of DHAAD in the PD draft is being challenged and we have reach > an agreement whether it's justified or not. There is a confusion that > since PD might occur right after bootstrap it could be considered as > bootstrap and thus use the bootstrap discovery method. > > I'm claiming it's not bootstrap but runtime and that at the time the > PD > process starts, the home prefix is known one way or another, > regardless > on whether config or RFC 5026 was used or not to get there. I'm not sure I understood what you suggest here: you seem to say that, even though RFC 5026 was used at the bootstrap phase, one can still use DHAAD after to find a suitable (= which is DHCPv6PD-capable) HA? In that case, what happens if the dhaad reply returns a different HA than the one that was configured at bootstrap time? regards, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr Louis Pasteur University - Networks and Protocols Team _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 4 01:43:06 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06F5C3A6BA3; Wed, 4 Jun 2008 01:43:06 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6F03A6B97 for ; Wed, 4 Jun 2008 01:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DA8Dp7cDfYvC for ; Wed, 4 Jun 2008 01:43:03 -0700 (PDT) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by core3.amsl.com (Postfix) with ESMTP id 382923A6812 for ; Wed, 4 Jun 2008 01:43:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id BE8E02F5BB5; Wed, 4 Jun 2008 10:43:06 +0200 (CEST) Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J371X59Hi6g1; Wed, 4 Jun 2008 10:43:06 +0200 (CEST) Received: from [130.79.91.222] (unknown [130.79.91.222]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 315182F5BAE; Wed, 4 Jun 2008 10:43:06 +0200 (CEST) Message-Id: <4FF89D28-A373-46EC-AEB6-2282F1E36B71@lsiit.u-strasbg.fr> From: Romain KUNTZ To: Behcet Sarikaya In-Reply-To: <176437.79827.qm@web84301.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 4 Jun 2008 10:43:05 +0200 References: <176437.79827.qm@web84301.mail.re1.yahoo.com> X-Mailer: Apple Mail (2.924) Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Behcet, On 2008/06/03, at 17:53, Behcet Sarikaya wrote: > [behcet] This is good point. We will find a solution for this in a > separate third draft > (just a joke). > I think the same problem exists in Ralph's draft and they need to > deal with that as well. I don't think this is a problem in Ralph's draft. When the MR is at home, it just operates DHCP as usual. Messages are not exchanged via the MR-HA a tunnel but directly on the home link. > Ok, what was their opinion on that? > > [behcet] I would let Marcelo answer this. I think his answer to Frank Xia makes it clear. Regards, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr Louis Pasteur University - Networks and Protocols Team _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 4 07:33:17 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E739628C1E0; Wed, 4 Jun 2008 07:33:16 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930C23A67A7 for ; Wed, 4 Jun 2008 07:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kK6lQBZVETLg for ; Wed, 4 Jun 2008 07:33:14 -0700 (PDT) Received: from web84310.mail.re1.yahoo.com (web84310.mail.re1.yahoo.com [69.147.74.189]) by core3.amsl.com (Postfix) with SMTP id C1EC228C1B2 for ; Wed, 4 Jun 2008 07:32:42 -0700 (PDT) Received: (qmail 45924 invoked by uid 60001); 4 Jun 2008 14:32:46 -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=vre2bKaWgKiKgBEk/uXJua8TubV2cxkub4v2jqZdhNwKNdBAy1SANhvCKXl/qoX2bxw60/t1MIOnIXuqRcL8aPuctzk2xSInvEyCf21c32g5WjBcTwP6094ptuInZpmt70UwhNZJsgLznbETEaDMdE8msfxhpBmeHQsqj6YCZMk=; X-YMail-OSG: ulpgrXgVM1kopoHQ5qV9v1wtnmGvwwgzov4r4TmdEfWBTQhIJKHvgRXaGkPAW9zPFZVBFD2k5800Z1n7I4QsEboFIQHhyAR_9xjIctDozRlsN6qh7P6T6NVtkzs- Received: from [206.16.17.212] by web84310.mail.re1.yahoo.com via HTTP; Wed, 04 Jun 2008 07:32:45 PDT X-Mailer: YahooMailRC/975.41 YahooMailWebService/0.7.185 Date: Wed, 4 Jun 2008 07:32:45 -0700 (PDT) From: Behcet Sarikaya To: Romain KUNTZ MIME-Version: 1.0 Message-ID: <144795.45786.qm@web84310.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 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="===============1903927158==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1903927158== Content-Type: multipart/alternative; boundary="0-682318277-1212589965=:45786" --0-682318277-1212589965=:45786 Content-Type: text/plain; charset=us-ascii Hi Romain, ----- Original Message ---- From: Romain KUNTZ To: Behcet Sarikaya Cc: mext@ietf.org Sent: Wednesday, June 4, 2008 3:43:05 AM Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Hi Behcet, On 2008/06/03, at 17:53, Behcet Sarikaya wrote: > [behcet] This is good point. We will find a solution for this in a > separate third draft > (just a joke). > I think the same problem exists in Ralph's draft and they need to > deal with that as well. I don't think this is a problem in Ralph's draft. When the MR is at home, it just operates DHCP as usual. Messages are not exchanged via the MR-HA a tunnel but directly on the home link. > Ok, what was their opinion on that? [behcet] I don't want to get into the details but the architecture in Ralph's draft would not work as is on the home link. As I said before, I don't think that we can ignore the possibility of having no home registration at the MR for DHCPv6 PD interactions, I don't agree this is an implementation issue. > [behcet] I would let Marcelo answer this. I think his answer to Frank Xia makes it clear. [behcet] It is clear that DHCPv6 PD can be used in different ways. MR as RR IS NOT the only way, draft-sarikaya-mext-prefix-delegation shows this clearly. Let HA be RR and let MR get prefixes using BU/BA (PBU/PBA in PMIPv6 which also has extensions to carry prefixes), just like in PMIPv6 where the first part has not been discussed yet in netlmm. Regards, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr Louis Pasteur University - Networks and Protocols Team --0-682318277-1212589965=:45786 Content-Type: text/html; charset=us-ascii
Hi Romain,

----- Original Message ----
From: Romain KUNTZ <kuntz@lsiit.u-strasbg.fr>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: mext@ietf.org
Sent: Wednesday, June 4, 2008 3:43:05 AM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

Hi Behcet,

On 2008/06/03, at 17:53, Behcet Sarikaya wrote:
> [behcet] This is good point. We will find a solution for this in a 
> separate third draft
> (just a joke).
> I think the same problem exists in Ralph's draft and they need to 
> deal with that as well.

I don't think this is a problem in Ralph's draft. When the MR is at 
home, it just operates DHCP as usual. Messages are not exchanged via 
the MR-HA a tunnel but directly on the home link.


> Ok, what was their opinion on that?
[behcet] I don't want to get into the details but the architecture in Ralph's draft would not work as is on the home link.
As I said before, I don't think that we can ignore the possibility of having no home registration at the MR for DHCPv6 PD interactions, I don't agree this is an implementation issue.
> [behcet] I would let Marcelo answer this.

I think his answer to Frank Xia makes it clear.
[behcet] It is clear that DHCPv6 PD can be used in different ways. MR as RR IS NOT the only way, draft-sarikaya-mext-prefix-delegation shows this clearly. Let HA be RR and let MR get prefixes using BU/BA (PBU/PBA in PMIPv6 which also has extensions to carry prefixes), just like in PMIPv6 where the first part has not been discussed yet in netlmm.


Regards,

--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team


--0-682318277-1212589965=:45786-- --===============1903927158== 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://www.ietf.org/mailman/listinfo/mext --===============1903927158==-- From mext-bounces@ietf.org Wed Jun 4 17:37:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FCFA3A689B; Wed, 4 Jun 2008 17:37:46 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26AB23A688B for ; Wed, 4 Jun 2008 17:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[AWL=1.413, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcAiAi2n-Zfi for ; Wed, 4 Jun 2008 17:37:44 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by core3.amsl.com (Postfix) with ESMTP id 314A83A689B for ; Wed, 4 Jun 2008 17:37:43 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id k34so262158wah.25 for ; Wed, 04 Jun 2008 17:37:44 -0700 (PDT) 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=zSIRaO6LklxPLiUD7UCM2QS+zyG8cS9+AmgYqt3I3dU=; b=FXZ+Hb3qSkNaU2NNkAudcWMjSD+oubScmR5YTaSqRwcoA8lwj7Sg2OdkfWWr6JIq1h xBEUKE/Fv6P8mKAVQiFQpvDsxVN4UXiiYDLZiDBYjWek+cz6gVOwDN8wt4nb+LOYov+Q F8RD4Shm3ja7bulgZUMTsop7nUidjc90Nady4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=xgEwXB1pOpX8UU/b26oCYR2SZoUR3wqEXPSz1rZwgCB4pkGIQmOzEKThG/BkzrUaPA deu1JF0yXLNejZyAKmFj7oAcJyOFjvHY6y0Jq8OkPfnEU+EOf6HsDSeJXtAJ0FpWwsiW o6lY+Z+w2z4BWvSyfIeec8kp3E1lxadZXeLNo= Received: by 10.114.113.1 with SMTP id l1mr793692wac.226.1212626264109; Wed, 04 Jun 2008 17:37:44 -0700 (PDT) Received: from EM60-254-226-34.pool.e-mobile.ne.jp ( [60.254.226.34]) by mx.google.com with ESMTPS id g25sm3338295wag.4.2008.06.04.17.37.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Jun 2008 17:37:43 -0700 (PDT) From: Ryuji Wakikawa To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05C0F044@xmb-ams-337.emea.cisco.com> References: <48401470.40706@it.uc3m.es> <7892795E1A87F04CADFCCF41FADD00FC05C0F044@xmb-ams-337.emea.cisco.com> Message-Id: Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 5 Jun 2008 09:37:34 +0900 X-Mailer: Apple Mail (2.924) Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Pascal, Sorry for late response. We have interop event in Tokyo and tested HAHA there;-) On 2008/06/03, at 17:08, Pascal Thubert (pthubert) wrote: > Hi Ryuji: > > I agree that PD should not impact bootstrap. These are and should be > kept unrelated. > > We must be able to extend a RFC 3963 MR with PD without forcing the > bootstrap process in the picture. So I agree not to bring DHAAD back > into the bootstrap... we agree then.. > But I think that PD is NOT a bootstrap process. It is post bootstrap > and > can reoccur many times in the life of the MR. > > Until we define a new process and rev 3775 and 3963, we should stay > consistent and simple in what we are doing. DHCP-PD can surely impact to the bootstrap process. Let's say MR boots up as a MN with RFC5026 first. Then, it tries to get a MNP for NEMO. If the current HA is not PD-enabled and DHAAD returns different HA, MR must de-register the binding from the current HA and tries to start all the registration process to the new HA. This seems very redundant operation.. I want to make the PD spec simple. regards ryuji > > > Pascal > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of > Ryuji Wakikawa >> Sent: mardi 3 juin 2008 09:54 >> To: marcelo bagnulo braun >> Cc: Julien Laganier; mext@ietf.org >> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> >> Hi Marcelo, >> >> I agree to accept this as WG doc. >> >> I also agree with Romain and Vijay. >> We don't need extension to DHAAD. >> Since MR can act as MN, MR should be able to bootstrap with the same >> mechanism of MIP (except for PD). >> We should not bring DHAAD back in the bootstrap process only for PD. >> >> regards, >> ryuji >> >> >> On 2008/05/30, at 23:51, marcelo bagnulo braun wrote: >> >>> Hi, >>> >>> We would like to ask the WG what is their opinion about accepting >>> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD >>> deliverable included in our charter. >>> >>> Please provide comments so we cna make some progress on this long >>> overdue deliverable >>> >>> thanks, Julien and marcelo >>> -------- Mensaje original -------- >>> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt >>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >>> De: Internet-Drafts@ietf.org >>> Responder a: internet-drafts@ietf.org >>> Para: i-d-announce@ietf.org >>> >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : DHCPv6 Prefix Delegation for NEMO >>> Author(s) : R. Droms, et al. >>> Filename : draft-droms-mext-nemo-pd-00.txt >>> Pages : 12 >>> Date : 2008-05-30 >>> >>> One aspect of network mobility support is the assignment of a prefix >>> or prefixes to a Mobile Router (MR) for use on the links in the >>> Mobile Network. DHCPv6 prefix delegation can be used for this >>> configuration task. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> >>> Content-Type: text/plain >>> Content-ID: <2008-05-30054232.I-D@ietf.org> >>> >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 4 17:40:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BA453A69CE; Wed, 4 Jun 2008 17:40:05 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D693C3A689B for ; Wed, 4 Jun 2008 17:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olssiPgI58XZ for ; Wed, 4 Jun 2008 17:40:03 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by core3.amsl.com (Postfix) with ESMTP id B1B8C3A6B08 for ; Wed, 4 Jun 2008 17:39:04 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id k34so262539wah.25 for ; Wed, 04 Jun 2008 17:39:09 -0700 (PDT) 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=I7r/KAvCq/MquxKPdDdhpJnGDZUIeXnhiTlAr8cUsUo=; b=BQktSncVSVz8LH5oyTjLrQpZpEyIV+q5MCvprCOzkDi9fjKm4AtNE0N3+qVRU7cVwj Y7nK4OrWZPkd+hdRanKgO63IKMrZ9g0V5cJroHRK1Fg6BMF1gnyQEIy7U1fanyQIOTaf 6eYrzVXcLKbgu18t3uq6V3KIdIctHZUEgVnD4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=mkuTIfs+5CGFsm0BjfUZXalS0qmljAJTdaU717k71QL60agCjgbW4biQiDhQbQVoHq aTUuNFQFps4eAQM8s1G79hVWh3KmbzKKkr6a32av8m2R5rpZojcKfZVaseqW43dj55oe yIgLWy7pL2F7KTah2SYzgmX6UG8bUTC/RS9bI= Received: by 10.114.154.1 with SMTP id b1mr897830wae.4.1212626349512; Wed, 04 Jun 2008 17:39:09 -0700 (PDT) Received: from EM60-254-226-34.pool.e-mobile.ne.jp ( [60.254.226.34]) by mx.google.com with ESMTPS id m31sm3333305wag.21.2008.06.04.17.39.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Jun 2008 17:39:08 -0700 (PDT) From: Ryuji Wakikawa To: Vijay Devarapalli In-Reply-To: References: Message-Id: <1170D554-4A78-40A6-A6D0-B1E4EA61717E@gmail.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 5 Jun 2008 09:38:59 +0900 X-Mailer: Apple Mail (2.924) Cc: mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi On 2008/06/04, at 2:52, Vijay Devarapalli wrote: > > On 6/3/08 6:37 AM, "Pascal Thubert (pthubert)" > wrote: > >> Hi Romain: >> >> This thread started with the Prefix Delegation draft. PD is not >> bootstrap and does not have its assumptions and limitations. IOW, >> whether a MR is preconfigured or found its home info via 5026 is >> orthogonal to Prefix Delegation. >> >> So I perfectly respect the design is RFC 5026 but that's not the >> problem >> at hand. The precedent is actually RFC 3963 and the method is >> extending >> DHAAD... > > Pascal, I don't see how this can justify further extending DHAAD to > discover > a prefix delegation-capable home agent. Yes, we did it once to > discover a > home agent that is capable of supporting mobile routers (in RFC > 3963). In > hindsight, I think even that was unnecessary. At that time, we all > thought > it was necessary. I will support removing that extension to DHAAD if > (and > when) 3963 is revised. +1 We should not use DHAAD for discovering a HA supporting particular extension. We had DHAAD extension to discovery a HA supporting Multiple Care-of Address Registration, but we removed it from the spec. ryuji > > > But the reality is that I don't see DHAAD being used that much for > discovering home agents, because DHAAD assumes that the mobile node/ > mobile > routers knows the home prefix (this means the mobile node is already > tied to > a certain subnet). Most bootstrapping scenarios that I have seen > don't want > to tie the mobile node/mobile router to a certain subnet. > > Vijay > >> >> Pascal >> >>> -----Original Message----- >>> From: Romain KUNTZ [mailto:kuntz@lsiit.u-strasbg.fr] >>> Sent: mardi 3 juin 2008 14:18 >>> To: Pascal Thubert (pthubert) >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] side discussion about discovering a HA >>> >>> Hi Pascal, >>> >>> On 2008/06/03, at 13:48, Pascal Thubert (pthubert) wrote: >>>> Things are complex enough as they are; so please let us not >>>> create a >>>> new >>>> HA localization tool for each sub-feature we come up with! >>> >>> DNS is not new, and is the standardized tool to resolve a FQDN or a >>> service by domain name. The MIPv6 bootstrapping makes the assumption >>> that the HA domain or FQDN is initially configured on the MR, hence >>> the use of DNS to get the HA address. This seems like an obvious >>> choice to me. >>> >>> DHAAD cannot be used in that case because the home prefix is not >>> known >>> by the MR. RFC 5026 explain more the motivations about that. >>> >>> romain >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 4 23:13:13 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 768143A6BB8; Wed, 4 Jun 2008 23:13:13 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D37B3A6BCC for ; Wed, 4 Jun 2008 23:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.445 X-Spam-Level: X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ix4J8FUqHCu for ; Wed, 4 Jun 2008 23:13:11 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 405FE3A6BB8 for ; Wed, 4 Jun 2008 23:13:11 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m556Bhk14499; Thu, 5 Jun 2008 06:11:43 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Jun 2008 01:03:16 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjCl/BRsleE2MpJRDuYDRHS09jxaAEM0gyA References: <483D5A50.1000208@it.uc3m.es> <000401c8c277$11d556f0$d2f6200a@amer.cisco.com> <48405020.8030404@it.uc3m.es> From: "Ahmad Muhanna" To: "Sri Gundavelli" , "marcelo bagnulo braun" Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > Hi Marcelo, > > Yes. It should provide all the general semantics required for > mobility entities to exchange events associated with the > established mobility session. > > Regards > Sri [Ahmad] It is worth the time to take a snap shot of the your "moving target" definition of the scope of the generic notification message: 1. During Prague MIP6 meeting, you were specifically asked about the scope of the Generic Notification Message and your answer was as follows: From the IETF-68, MIP6 meeting minutes: " Alper; what is the scope of the message. Sri: Opaque load, HA is going down after 1 hr or something? " 2. Despite that you were a co-author on the Generic Notification message draft, you joined as a co-author for the draft-muhanna-mip6-binding-revocation- which, from day one, uses new MH types for BRI and BRA. You did not seem to have any concern at the time! 3. During the MIP6 mailing list discussion, you defended the draft for using new MH types. 4. In the latest Generic Notification Message draft, it says: " RFC 3775 [RFC3775] contains no provision for Mobile IPv6 entities, such as a home agent or mobile node, to send and receive asynchronous notification messages during a mobility session. " More over, it says: " This document describes a generic notification message protocol that can be used by Mobile IPv6 entities for sending and receiving simple notification events. " 5. During the discussion round before the last on MEXT you defined the Notification as "It does not require semantics beyond a simple request/reply message format" Ironically, that the scope of all mobility protocol messages. 6. Finally, you just announced that Generic Notification Message is all of the above and beyond! Wow; it is quite a journey of change/modification/development that is very interesting. The only thing I can say here that it is a function of TIME! Cheers! > > On Fri, 30 May 2008, marcelo bagnulo braun wrote: > > > Hi Sri, > > > > So, your view is that the generic notification should be as > general as > > possible and should be able to support reliable delivery, message > > exchange from the HA and from the MN or for any other party > involved, > > with different type of security (IPSec protected and non IPSec > > protected), for critical and for non critical things and so on? > > > > Regards, marcelo > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 00:18:23 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8166B3A68E0; Thu, 5 Jun 2008 00:18:23 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C948B3A6B89 for ; Thu, 5 Jun 2008 00:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wOrs1fUoDvm for ; Thu, 5 Jun 2008 00:18:19 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 34DEF3A68E0 for ; Thu, 5 Jun 2008 00:17:53 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so288789fga.41 for ; Thu, 05 Jun 2008 00:17:58 -0700 (PDT) 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=IpWScumYjoh9y2mGtjFZQxy0Uw5f89BwDzNSjtU7aYk=; b=QmqnKnavIg1hCxmq/niPqtwBYH2GTciDrzFvifDraH+Ukr6zajN47H272jODZF+yc+ PQRtea028S+G0hJqB92+lcb2GFILTeKq/P2ziyk6MJF7W/uhPBqsZby6R8cUvUPc18dn fWDUAox0gne8guxTZ/PQLeMeHlrYMg/A5hzMM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:sender; b=VtmevQOsBJ9lv1iA25w3RS6DicYPtJoYqUUoDHtsTbMdm0cQC7vhYVPPz44yH+DxcR cS0ck4Eof3Jc30uCq5EnV8LO0XXG+fjy14K8PYLM5gVzYlKvr5ELOc+uuxDwNP+mw/7h coKXezVPSMRx1uPniu3lFxGRQPqJWvvfoWd2k= Received: by 10.86.58.3 with SMTP id g3mr1515519fga.21.1212650278147; Thu, 05 Jun 2008 00:17:58 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id b17sm5727215fka.6.2008.06.05.00.17.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Jun 2008 00:17:55 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Thu, 5 Jun 2008 09:18:04 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806050918.05372.julien.IETF@laposte.net> Subject: [MEXT] [rfc3775] Application using the care-of address X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, I'd like to propose an additional change to RFC3775. The change is minor, and informative only: Reason for change: RFC3775 mentions two times the possibility to use the care-of address as a source address in outgoing packets. In the first occurence, RFC3775 says that APIs to control this use are out-of-scope, but since an API that allows an application to require the care-of address to be used in outgoing packets has been specified since then in RFC5014, RFC3775bis could mention RFC5014 as an example of such an API. In the second occurence, RFC3775 says that a multicast application could use the care-of address as a source address in outgoing packets if it know the care-of address, but since RFC5014 allows to use the care-of address as a source address without requiring the application to knows the address itself that should be corrected in RFC3775bis. See below the two slights modifications, plus the additional informative reference. Please let me know what you think. Thanks, --julien ------------------------------------------------------------------------- OLD: o The mobile node MAY choose to directly use one of its care-of addresses as the source of the packet, not requiring the use of a Home Address option in the packet. This is particularly useful for short-term communication that may easily be retried if it fails. Using the mobile node's care-of address as the source for such queries will generally have a lower overhead than using the mobile node's home address, since no extra options need be used in either the query or its reply. Such packets can be routed normally, directly between their source and destination without relying on Mobile IPv6. If application running on the mobile node has no particular knowledge that the communication being sent fits within this general type of communication, however, the mobile node should not use its care-of address as the source of the packet in this way. The choice of the most efficient communications method is application specific, and outside the scope of this specification. The APIs necessary for controlling the choice are also out of scope. NEW: o The mobile node MAY choose to directly use one of its care-of addresses as the source of the packet, not requiring the use of a Home Address option in the packet. This is particularly useful for short-term communication that may easily be retried if it fails. Using the mobile node's care-of address as the source for such queries will generally have a lower overhead than using the mobile node's home address, since no extra options need be used in either the query or its reply. Such packets can be routed normally, directly between their source and destination without relying on Mobile IPv6. If application running on the mobile node has no particular knowledge that the communication being sent fits within this general type of communication, however, the mobile node should not use its care-of address as the source of the packet in this way. The choice of the most efficient communications method is application specific, and outside the scope of this specification. The APIs necessary for controlling the choice are also out of | scope. One example of such an API is described in the IPv6 Socket | API for Source Address Selection specification [RFC5014]. -------------------------------------------------------------------------- OLD: A mobile node that wishes to send packets to a multicast group also has two options: 1. Send directly on the foreign link being visited. The application is aware of the care-of address and uses it as a source address for multicast traffic, just like it would use a stationary address. The mobile node MUST NOT use Home Address destination option in such traffic. NEW: A mobile node that wishes to send packets to a multicast group also has two options: 1. Send directly on the foreign link being visited. | The application uses the care-of address as a source address for | multicast traffic, just like it would use a stationary address. | This requires that the application either knows the care-of | address, or uses an API such as the IPv6 Socket API for Source | Address Selection specification [RFC5014] to request the stack to | use the care-of address as a source address in sent packets. The mobile node MUST NOT use Home Address destination option in such traffic. -------------------------------------------------------------------------- NEW: 18.2. Informative References | [RFC5014] Nordmark, E., Chakrabarti, S., and Laganier, J., "IPv6 | Socket API for Source Address Selection", RFC 5014, | September 2007. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 00:25:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7225D3A6BCC; Thu, 5 Jun 2008 00:25:50 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D78328C10F for ; Thu, 5 Jun 2008 00:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTw0JNGqNXht for ; Thu, 5 Jun 2008 00:25:47 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 6A03D3A6B89 for ; Thu, 5 Jun 2008 00:25:45 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so290702fga.41 for ; Thu, 05 Jun 2008 00:25:50 -0700 (PDT) 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=Y3W3BC1cjUe8n436UO+1ZsIEq3NNRHmaeb4dZh3HhuY=; b=ifAkF1h1FB2jyisjoldUA9s/aJdWnkPBiIhQrNNnumnpn4rnvuIQOXJqILk+UMxda7 1hBaC1RpS6WFfvZMhCDKYIfGI56O2xc/1kwPz5dLXOTylOr3gWefxxeKq1INKkfw+0jD FfDPywMRMONmCbq6ZfPJDoWUI7AW+msTnL5LY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:sender; b=T41TiIw+8gRYumgigMViXLjVV8a1RE/qyQqda0f8zEpkL4hsmPDRQA6lD+zc/mrAcw pe6gTWnsRjSyjLJpM8cwy8sP3b0ufCAMi6zYzgFzZJH4wx52ylk8WeLo0LHnIpRtvbl2 wviZpoun4H80ABI8Xsl7GjpoNPrMjccoCPLqc= Received: by 10.86.57.9 with SMTP id f9mr1477161fga.66.1212650750373; Thu, 05 Jun 2008 00:25:50 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 28sm5722219fkx.8.2008.06.05.00.25.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Jun 2008 00:25:48 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Thu, 5 Jun 2008 09:26:02 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <483D5A50.1000208@it.uc3m.es> <483EBC71.70102@it.uc3m.es> <483ECF89.1040806@levkowetz.com> In-Reply-To: <483ECF89.1040806@levkowetz.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806050926.04103.julien.IETF@laposte.net> Cc: Henrik Levkowetz Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, With my WG chair hat firmly off, I'd like to say that I agree with = everything Henrik said on this topic (Scope of generic notification). Thanks. --julien On Thursday 29 May 2008, Henrik Levkowetz wrote: > Hi Marcelo, > > On 2008-05-29 16:23 marcelo bagnulo braun said the following: > > Henrik Levkowetz escribi=F3: > >> Umm... Yes. But if we have to use a new MH type for a > >> communication between > >> peers where the generic notification mechanism is available, that > >> would likely > >> indicate a failure in designing the generic notification > >> mechanism, no? > > > > well, it depends on what do you think it is scope for generic > > notification hence this discussion. > > > > You can envisage that generic notification is only for non reliable > > delivery of information. So, you can scope it that way, and the it > > is very clear: any information flowing from the HA that needs no > > reliable ddelivery, you should use generic notification. Else you > > should use a new MH type. (that is merely an example) > > > > OTOH, you can define the scope being much broader, that i think is > > what you have in mind i.e. any information cnoveyed from the HA to > > the MN should use the generic notification. New MH types are > > reserved for information sent from the MN i guess then. We should > > then define the generic notification format in a much more general > > way, that can accomodate all kind of message exchange initiated by > > the HA and all king of security and so on. > > > > I understand that your preference is that the generic notiication > > emssage should be able to accomodate any information exchange > > initiated by the HA, is that correct? > > No, I think I've still not quite managed to get across what I'm > trying to say. I'm not advocating any specific property of the > generic notification mechanism, except that it should be generic. = > I'm advocating that it should (in addition to being somewhat generic) > be *useful* for the use case (or cases) we know about today. More > below. > > > I am perfectly ok with any of these or other options. My only point > > is that the WG should define what the scope of the generic > > notification is > > > >>> My question is then when to use the generic notification (with > >>> the MH type assigned to the generic notification) and when to use > >>> a new MH type, makes sese now or am i still missing something? > >> > >> No, I think I got you now. But to me that would mean that if you > >> have to use a new MH type because the generic notification > >> mechanism won't work, then you have failed to define the generic > >> notification mechanism appropriately. > >> > >> If you wish to use a new MH type because the semantics is > >> fundamentally different than what's been envisaged for the generic > >> notification, that's fine. I have a hard time seeing that > >> applying to binding revocation, though... > > > > I would leave the binding revocation discussion out of this for > > now. Once we agreed on what the scope of the generic notification > > should be, it should be fairly easy to understand if the binding > > revocation should use it or not i guess > > No no no. This is the point. We can define a beautiful mechanism > which could be useless, or only useful for things which isn't really > needed by anybody. I don't think that's what we should do, though. > > How many specific examples do we have of proposed messages with real > deployment needs behind them? > > Discussing the properties of a message mechanism out of context of > the specific examples which we know are needed today may lead to a > beautiful but useless design. Discussing the properties of the > message mechanism in the context of known use cases is vital, in > order to get something with a reasonable chance of actually being > appropriate and useful. Divorcing the generic notification mechanism > from the most obvious potential use case for the mechanism doesn't > make sense to me. > > > Regards, > > Henrik > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 00:50:27 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AC313A6BBB; Thu, 5 Jun 2008 00:50:27 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A32B3A6BB3 for ; Thu, 5 Jun 2008 00:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIXhUvXpCP3w for ; Thu, 5 Jun 2008 00:50:23 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id D896D3A6D4B for ; Thu, 5 Jun 2008 00:49:03 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so295557fga.41 for ; Thu, 05 Jun 2008 00:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:user-agent:cc :references:in-reply-to:mime-version:content-disposition:date :content-type:content-transfer-encoding:message-id:sender; bh=F6Mnayf11sdMY4Fl6J63ercS/YE8PtD1ujxlSNoFYVQ=; b=S54cvrK+RlaC1az1KYDD6ToXI3MgCi9Fy+Axbr+xv7Nmduj2iY1hIKynhPEkbNgtMF OgiABVDrDZp2duiB98+BxWMuzcd5IsyIYcaoQaEt2PUPmUXxym05TrEeUUTbDzCwIcT6 yIYQQFYzmOnxIwZEGfL4KMLXh3u2sTfI470V4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:user-agent:cc:references:in-reply-to:mime-version :content-disposition:date:content-type:content-transfer-encoding :message-id:sender; b=sNVOMBOzUcufHSznJTI3LOyeAS2cvh17Bj4EahDk7Iq1qfCXE/oqvM0DooZmbNP6c5 xlIRCCPyKu6UwV1Fl6wVchxH0FTAfD4mv2+oTNUsWJVG9HIW0V54sNcedvm1LPvXvNIm RTRRvHUfu/kHntEuMdgZ8yxOrFiasJxAcV+KU= Received: by 10.86.49.13 with SMTP id w13mr1511275fgw.65.1212652143510; Thu, 05 Jun 2008 00:49:03 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id g28sm5812456fkg.1.2008.06.05.00.49.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Jun 2008 00:49:02 -0700 (PDT) From: Julien Laganier To: "Ahmad Muhanna" , mext@ietf.org User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <483D5A50.1000208@it.uc3m.es> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Date: Thu, 5 Jun 2008 09:49:17 +0200 Message-Id: <200806050949.18503.julien.IETF@laposte.net> Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Ahmad, On Thursday 05 June 2008, Ahmad Muhanna wrote: > > Hi Marcelo, > > > > Yes. It should provide all the general semantics required for > > mobility entities to exchange events associated with the > > established mobility session. > > > > Regards > > Sri > > [Ahmad] > It is worth the time to take a snap shot of the your "moving target" > definition of the scope of the generic notification message: > > 1. During Prague MIP6 meeting, you were specifically asked about the > scope of the Generic Notification Message and your answer was as > follows: From the IETF-68, MIP6 meeting minutes: [...] > 6. Finally, you just announced that Generic Notification Message is > all of the above and beyond! > > Wow; it is quite a journey of change/modification/development that is > very interesting. The only thing I can say here that it is a function > of TIME! FWIW: I don't think someone changing its opinion over time is an issue. Actually, I firmly claim the right to change my opinion over time, as I sometimes don't understand all implications of an issue in the beginning. Let me also note that if all of us would always stick to our first opinion and never change them, it could make discussion useless in case everybody has an opinion from the start :) Finally, and as a funny note only (no offense intended), the French language has this saying (maybe other languages have it too) : "Only imbeciles never change their mind". Maybe we should all learn from that :-P Best regards, --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 01:25:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EFEB3A6CC9; Thu, 5 Jun 2008 01:25:39 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56D7A3A6C6C for ; Thu, 5 Jun 2008 01:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfkskrUSc9g4 for ; Thu, 5 Jun 2008 01:25:25 -0700 (PDT) Received: from moog.chdir.org (unknown [IPv6:2002:58bf:2aa0:339b:f654:e10e:317f:e6fa]) by core3.amsl.com (Postfix) with ESMTP id 084853A6D43 for ; Thu, 5 Jun 2008 01:22:50 -0700 (PDT) Received: from dy022034.etu.univ-rennes1.fr ([148.60.22.34] helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1K4AkH-0000vh-Up; Thu, 05 Jun 2008 10:22:54 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Julien Laganier References: <200806050918.05372.julien.IETF@laposte.net> X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080605:julien.ietf@laposte.net::SuWnBk9SyfQTu1dO:000000000000000000000000000000000000001ulh X-Hashcash: 1:20:080605:mext@ietf.org::re5/AzZR40lBJZUh:00006Vuh Date: Thu, 05 Jun 2008 10:22:52 +0200 In-Reply-To: <200806050918.05372.julien.IETF@laposte.net> (Julien Laganier's message of "Thu, 5 Jun 2008 09:18:04 +0200") Message-ID: <87ve0othnn.fsf@natisbad.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] [rfc3775] Application using the care-of address X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Julien Laganier writes: > I'd like to propose an additional change to RFC3775. The change is > minor, and informative only: > > Reason for change: RFC3775 mentions two times the possibility to use the > care-of address as a source address in outgoing packets. In the first > occurence, RFC3775 says that APIs to control this use are out-of-scope, > but since an API that allows an application to require the care-of > address to be used in outgoing packets has been specified since then in > RFC5014, RFC3775bis could mention RFC5014 as an example of such an > API. As a side note (I do not think this fits in the scope of RFC3775bis), there is also a need to control the use of the CoA by the IKE daemon during the negotiation of SA protecting BU/BA because the HoA is not yet available (so not usable). AFAIK, This is not *explicitly* covered by RFC 3775 and RFC 3776 and this specific case cannot be handled using the documents you point. For more details on that, see draft-sugimoto-mip-pfkey-migrate-04. Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 02:27:30 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 131A13A6C12; Thu, 5 Jun 2008 02:27:30 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4B303A6BD2 for ; Thu, 5 Jun 2008 02:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYGtb3TwLA7A for ; Thu, 5 Jun 2008 02:27:28 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id 9282C3A6C5D for ; Thu, 5 Jun 2008 02:27:27 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so315316fga.41 for ; Thu, 05 Jun 2008 02:27:32 -0700 (PDT) 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=YvB5hKHhVTacS3ja0RFfZdzw5IdnsxtBK6jtShbC7ik=; b=DHZkBNr/u1Jv3r85j/2obS/O2wKE2ossxbdd7Fvcp22kIhHlvzNjjBif4ZUtDj5C3t N4+gwgEXaOhX/Z0hsSMp+RXUOYdPYHi1b4GYvz4tlnszEkhkfTYNM9AIN8wkwwfywiQz Ij3LcHWiI+N7tRMygvilD9jxVh+S4a4+mdDKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:sender; b=P9xO7C4H11/VIP2lPdFcyWlKKTq+kxVInvQolT00PZHpv/onnNqQ7bTgvICyKNMBK2 PSmR25ZdhLpMv9wmDXkpqmGai4P9ivsiNAoSFTzUUhIdjcNwCVSOfVyZfHt8FGXZ8sF3 sc8cnKnRkCyaYndorUH+XCoplVhYJnHqSlsWo= Received: by 10.86.99.9 with SMTP id w9mr1657760fgb.70.1212658052343; Thu, 05 Jun 2008 02:27:32 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id f19sm6067468fka.3.2008.06.05.02.27.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Jun 2008 02:27:30 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Thu, 5 Jun 2008 11:27:38 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200806050918.05372.julien.IETF@laposte.net> <87ve0othnn.fsf@natisbad.org> In-Reply-To: <87ve0othnn.fsf@natisbad.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806051127.40178.julien.IETF@laposte.net> Subject: Re: [MEXT] [rfc3775] Application using the care-of address X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Arnaud, On Thursday 05 June 2008, Arnaud Ebalard wrote: > Hi, > > Julien Laganier writes: > > I'd like to propose an additional change to RFC3775. The change is > > minor, and informative only: > > > > Reason for change: RFC3775 mentions two times the possibility to > > use the care-of address as a source address in outgoing packets. In > > the first occurence, RFC3775 says that APIs to control this use are > > out-of-scope, but since an API that allows an application to > > require the care-of address to be used in outgoing packets has been > > specified since then in RFC5014, RFC3775bis could mention RFC5014 > > as an example of such an API. > > As a side note (I do not think this fits in the scope of RFC3775bis), > there is also a need to control the use of the CoA by the IKE daemon > during the negotiation of SA protecting BU/BA because the HoA is not > yet available (so not usable). AFAIK, This is not *explicitly* > covered by RFC 3775 and RFC 3776 and this specific case cannot be > handled using the documents you point. Why couldn't the IKE process use RFC5014 to ask the IP stack to put the CoA in packets it sends? --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 05:00:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 241F63A6B45; Thu, 5 Jun 2008 05:00:47 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D35EB3A6920 for ; Thu, 5 Jun 2008 05:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXYQA4rMmRuX for ; Thu, 5 Jun 2008 05:00:42 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id A0CEC3A6BD9 for ; Thu, 5 Jun 2008 05:00:42 -0700 (PDT) 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 m55C0eV03253; Thu, 5 Jun 2008 12:00:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Jun 2008 07:00:25 -0500 Message-ID: In-Reply-To: <200806050937.23548.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjG3vpPPTOxlFpEReSyG1T32dd6IAAH+76g References: <483D5A50.1000208@it.uc3m.es> <200806050937.23548.julien.IETF@laposte.net> From: "Ahmad Muhanna" To: "Julien Laganier" , Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > Hello Ahmad, > > On Thursday 05 June 2008, Ahmad Muhanna wrote: > > > Hi Marcelo, > > > > > > Yes. It should provide all the general semantics required for > > > mobility entities to exchange events associated with the > established > > > mobility session. > > > > > > Regards > > > Sri > > > > [Ahmad] > > It is worth the time to take a snap shot of the your "moving target" > > definition of the scope of the generic notification message: > > > > 1. During Prague MIP6 meeting, you were specifically asked > about the > > scope of the Generic Notification Message and your answer was as > > follows: From the IETF-68, MIP6 meeting minutes: > > [...] > > > 6. Finally, you just announced that Generic Notification Message is > > all of the above and beyond! > > > > Wow; it is quite a journey of > change/modification/development that is > > very interesting. The only thing I can say here that it is > a function > > of TIME! > > FWIW: > > I don't think someone changing its opinion over time is an issue. > > Actually, I firmly claim the right to change my opinion over > time, as I sometimes don't understand all implications of an > issue in the beginning. > > Let me also note that if all of us would always stick to our > first opinion and never change them, it could make discussion > useless in case everybody has an opinion from the start. > > Finally, and as a funny note only (no offense intended), the > French language has this saying (maybe other languages have > it too) : "Only imbeciles never change their mind". Maybe we > should all learn from that :-P [Ahmad] Hello Julien, Heheh .. sure that is in many other languages:-P I may as well quote you what a famous professor of engineering said in the court of law, when he was faced with a quotation from his own book, he said: "I am not a vegetable; I learn something new every day". Bottom line, did I say learning new stuff is a bad thing? ... As long as we swing within reasonable range;) Best Regards, Ahmad > > Best regards, > > --julien > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 05:07:33 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 140543A6C38; Thu, 5 Jun 2008 05:07:33 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC91C3A6BDC for ; Thu, 5 Jun 2008 05:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckvoKHR01vm3 for ; Thu, 5 Jun 2008 05:07:31 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.245.51]) by core3.amsl.com (Postfix) with SMTP id BE6123A6C38 for ; Thu, 5 Jun 2008 05:07:30 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1212667655!26180884!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 1784 invoked from network); 5 Jun 2008 12:07:35 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-4.tower-119.messagelabs.com with SMTP; 5 Jun 2008 12:07:35 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id m55C7ZsY005371 for ; Thu, 5 Jun 2008 05:07:35 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id m55C7Yrj010557 for ; Thu, 5 Jun 2008 07:07:35 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id m55C7XFM010532 for ; Thu, 5 Jun 2008 07:07:34 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Jun 2008 13:07:29 +0100 Message-ID: <4847D706.6080406@gmail.com> Date: Thu, 05 Jun 2008 14:07:34 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mext Content-Type: multipart/mixed; boundary="------------040901020005010506000908" X-Antivirus: avast! (VPS 080604-1, 04/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 05 Jun 2008 12:07:30.0146 (UTC) FILETIME=[BA6B7420:01C8C704] X-CFilter-Loop: Reflected Subject: [MEXT] [Fwd: Re: [Mip6] [rfc3775] Application using the care-of address] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --------------040901020005010506000908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ --------------040901020005010506000908 Content-Type: message/rfc822; name="Re: [Mip6] [MEXT] [rfc3775] Application using the care-of address.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Re: [Mip6] [MEXT] [rfc3775] Application using the care-of ad"; filename*1="dress.eml" Received: from zuk35exm63.ds.mot.com ([10.178.4.20]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Jun 2008 11:35:31 +0100 Received: from il06exr02.mot.com ([129.188.137.132]) by zuk35exm63.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Jun 2008 11:35:33 +0100 Received: from motgate7.mot.com (motgate7.mot.com [129.188.136.7]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id m55AZW8Y026419 for ; Thu, 5 Jun 2008 05:35:32 -0500 (CDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by motgate7.mot.com (8.12.11/Motorola) with SMTP id m55AZVdN011978 for ; Thu, 5 Jun 2008 03:35:31 -0700 (MST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu+caf_=alexandru.petrescu=motorola.com@gma il.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1212662129!17281748!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.85.128.188] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_MATCH_4,RCVD_BY_IP Received: (qmail 3142 invoked from network); 5 Jun 2008 10:35:30 -0000 Received: from fk-out-0910.google.com (HELO fk-out-0910.google.com) (209.85.128.188) by server-14.tower-128.messagelabs.com with SMTP; 5 Jun 2008 10:35:30 -0000 Received: by fk-out-0910.google.com with SMTP id 19so414728fkr.8 for ; Thu, 05 Jun 2008 03:35:29 -0700 (PDT) Received: by 10.82.188.15 with SMTP id l15mr83360buf.74.1212662129046; Thu, 05 Jun 2008 03:35:29 -0700 (PDT) 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.6 with SMTP id x6cs36487bub; Thu, 5 Jun 2008 03:35:28 -0700 (PDT) Received: by 10.143.162.3 with SMTP id p3mr439813wfo.313.1212662127499; Thu, 05 Jun 2008 03:35:27 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx.google.com with ESMTP id 22si5791051wfg.13.2008.06.05.03.35.11; Thu, 05 Jun 2008 03:35:27 -0700 (PDT) Received-SPF: pass (google.com: domain of mip6-bounces@ietf.org designates 64.170.98.32 as permitted sender) client-ip=64.170.98.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of mip6-bounces@ietf.org designates 64.170.98.32 as permitted sender) smtp.mail=mip6-bounces@ietf.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EAE028C19E; Thu, 5 Jun 2008 03:35:01 -0700 (PDT) X-Original-To: mip6@core3.amsl.com Delivered-To: mip6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D2B528C16F for ; Thu, 5 Jun 2008 03:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMjoXrOU38rz for ; Thu, 5 Jun 2008 03:34:59 -0700 (PDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by core3.amsl.com (Postfix) with ESMTP id 9F6FE28C19E for ; Thu, 5 Jun 2008 03:34:59 -0700 (PDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1K4CoA-0001qT-6T for mip6@ietf.org; Thu, 05 Jun 2008 10:35:02 +0000 Received: from moog.chdir.org ([88.191.42.160]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Jun 2008 10:35:02 +0000 Received: from arno by moog.chdir.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Jun 2008 10:35:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: From: arno@natisbad.org (Arnaud Ebalard) Date: Thu, 05 Jun 2008 12:18:16 +0200 Message-ID: References: <200806050918.05372.julien.IETF@laposte.net> <87ve0othnn.fsf@natisbad.org> <200806051127.40178.julien.IETF__18347.5074278705$1212658152$gmane$org@laposte.net> Mime-Version: 1.0 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: moog.chdir.org User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) X-GnuPG-Key: 0x047A5026 Cancel-Lock: sha1:IooGq8+YlrKNhqRxS34YuVstQdo= Subject: Re: [Mip6] [MEXT] [rfc3775] Application using the care-of address X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Return-Path: alexandru.petrescu+caf_=alexandru.petrescu=motorola.com@gmail.com X-OriginalArrivalTime: 05 Jun 2008 10:35:33.0562 (UTC) FILETIME=[E24789A0:01C8C6F7] X-Antivirus: avast! (VPS 080604-1, 04/06/2008), Inbound message X-Antivirus-Status: Clean Hello, Julien Laganier writes: >> > Reason for change: RFC3775 mentions two times the possibility to >> > use the care-of address as a source address in outgoing packets. In >> > the first occurence, RFC3775 says that APIs to control this use are >> > out-of-scope, but since an API that allows an application to >> > require the care-of address to be used in outgoing packets has been >> > specified since then in RFC5014, RFC3775bis could mention RFC5014 >> > as an example of such an API. >> >> As a side note (I do not think this fits in the scope of RFC3775bis), >> there is also a need to control the use of the CoA by the IKE daemon >> during the negotiation of SA protecting BU/BA because the HoA is not >> yet available (so not usable). AFAIK, This is not *explicitly* >> covered by RFC 3775 and RFC 3776 and this specific case cannot be >> handled using the documents you point. > > Why couldn't the IKE process use RFC5014 to ask the IP stack to put the > CoA in packets it sends? This is not the issue; Here is how things happen: the BU created by the MIPv6 process, uses the CoA as source address in the end (when leaving the MN) but the packet matches the SP protecting the signaling traffic. This SP uses the HoA and not the CoA. If no SA is available, a key manager will handle the negotiation of the SA. The SA being negotiated also use the HoA. The point is that the key manager usually selects the source address of the SA being negotiated to perform the negotiation: in *that* specific case, this cannot be done and the IKE daemon needs to be told to use the CoA. This is decribed in details in the pointer I sent in my previous post. Cheers, a+ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 --------------040901020005010506000908 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://www.ietf.org/mailman/listinfo/mext --------------040901020005010506000908-- From mext-bounces@ietf.org Thu Jun 5 07:31:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F2DF28C205; Thu, 5 Jun 2008 07:31:03 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A45D28C210 for ; Thu, 5 Jun 2008 07:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3zzIj7XqMVk for ; Thu, 5 Jun 2008 07:31:01 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1BF8E28C205 for ; Thu, 5 Jun 2008 07:30:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,595,1204531200"; d="scan'208";a="108901399" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 05 Jun 2008 07:31:00 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m55EUx1u014932; Thu, 5 Jun 2008 07:30:59 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m55EUxhN021000; Thu, 5 Jun 2008 14:30:59 GMT Date: Thu, 5 Jun 2008 07:30:59 -0700 (PDT) From: Sri Gundavelli To: Ahmad Muhanna In-Reply-To: Message-ID: References: <483D5A50.1000208@it.uc3m.es> <000401c8c277$11d556f0$d2f6200a@amer.cisco.com> <48405020.8030404@it.uc3m.es> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4285; t=1212676260; x=1213540260; 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]=20Scope=20of=20generic=20notific ation |Sender:=20; bh=wceWKqw7ym6aI3EzwZPM85GVeNA1F8qxWgW5OxeIJt8=; b=jd54U9nhtWLGGg+/JkJBNoTRkWFCMtxUYgGe8dgi8zP6dH/vWPCgdJGCAR wpOFEmeXkGnXS72kxszjS/x2KsJEdRmE/2JCJa3yRwF6ZRfjnaySuhif5Gxq x1E+BaFZqR; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I will repeat one last time. You are wasting your time, you are stuck on using a new MH type for revocation message and nothing else works for you. Just go and use it, define transport, DSMIP considerations, security and firewall considerations. Fine, just that the document will have more pages. Myself or Brian is not going to argue against this. I think, we already said this twice. Now, to accomodate this, dont say the scope of Generic Notification is for saving MH types. The draft is written with a purpose and the use cases as listed in the earlier versions even included Revocation message (atleast a year before the -00 version of the revocation draft was published). Go and check. W.r.t my changing opinions, as you put it, go and check the meeting minutes for the last 2 IETF's. In both the occassions when I was presenting the Generic Notification draft, a question was asked, "Does revocation use this Generic Notification message" and I said "Yes". Agreeing to work together on Revocation does not imply, I agreed to the use of a new MH type. I'm really baffled as why this is such a big deal. I simply dont understand how it impacts the revocation draft. Its one line stating, "these messages use the Generic Notification format". I will not try to understand that, its a waste of time. Botton line, I gave my opinion on the scope of notification draft. I'm not interested or have the time to argue against the use of new MH type in revocation message. Its a procedural issue as Raj put it and is not a technical issue. Dont drag me into this argument. Do what you want or convince the WG, not me. Sri On Thu, 5 Jun 2008, Ahmad Muhanna wrote: >> >> Hi Marcelo, >> >> Yes. It should provide all the general semantics required for >> mobility entities to exchange events associated with the >> established mobility session. >> >> Regards >> Sri > > [Ahmad] > It is worth the time to take a snap shot of the your "moving target" > definition of the scope of the generic notification message: > > 1. During Prague MIP6 meeting, you were specifically asked about the > scope of the Generic Notification Message and your answer was as > follows: From the IETF-68, MIP6 meeting minutes: > > " > Alper; what is the scope of the message. > Sri: Opaque load, HA is going down after 1 hr or something? > " > > 2. Despite that you were a co-author on the Generic Notification message > draft, you joined as a co-author for the > draft-muhanna-mip6-binding-revocation- which, from day one, uses new MH > types for BRI and BRA. You did not seem to have any concern at the time! > > 3. During the MIP6 mailing list discussion, you defended the draft for > using new MH types. > > 4. In the latest Generic Notification Message draft, it says: > > " > RFC 3775 [RFC3775] contains no provision for Mobile IPv6 entities, > such as a home agent or mobile node, to send and receive asynchronous > notification messages during a mobility session. > " > > More over, it says: > > " > This document describes a generic notification message protocol that > can be used by Mobile IPv6 entities for sending and receiving simple > notification events. > " > > 5. During the discussion round before the last on MEXT you defined the > Notification as "It does not require semantics beyond a simple > request/reply message format" Ironically, that the scope of all mobility > protocol messages. > > 6. Finally, you just announced that Generic Notification Message is all > of the above and beyond! > > Wow; it is quite a journey of change/modification/development that is > very interesting. The only thing I can say here that it is a function of > TIME! > > Cheers! > > >> >> On Fri, 30 May 2008, marcelo bagnulo braun wrote: >> >>> Hi Sri, >>> >>> So, your view is that the generic notification should be as >> general as >>> possible and should be able to support reliable delivery, message >>> exchange from the HA and from the MN or for any other party >> involved, >>> with different type of security (IPSec protected and non IPSec >>> protected), for critical and for non critical things and so on? >>> >>> Regards, marcelo >>> >>> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 07:49:02 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9444328C2A0; Thu, 5 Jun 2008 07:49:02 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FCDB3A68FF for ; Tue, 3 Jun 2008 03:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drf4OT9X+nM9 for ; Tue, 3 Jun 2008 03:03:28 -0700 (PDT) Received: from kafka.verkstad.net (kafka.verkstad.net [192.71.20.153]) by core3.amsl.com (Postfix) with ESMTP id E9D693A683F for ; Tue, 3 Jun 2008 03:03:27 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id 66E1F710A7A; Tue, 3 Jun 2008 12:03:29 +0200 (CEST) Date: Tue, 3 Jun 2008 12:03:29 +0200 From: Michael Eriksson To: marcelo bagnulo braun Message-ID: <20080603100329.GA22769@kafka.verkstad.net> References: <483D5A50.1000208@it.uc3m.es> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <483D5A50.1000208@it.uc3m.es> X-Mailman-Approved-At: Thu, 05 Jun 2008 07:49:01 -0700 Cc: mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Wed, May 28, 2008 at 15:12:48 +0200, marcelo bagnulo braun wrote: > In our new charter we have a new item on a generic notification mechanism. > During discussion over the last weeks, it seems to me that the WG needs to > make a decision about what is the scope of the generic notification > > In summary, we need to decide which is the scope of the generic > notification and what is the scope of the existing MH types. > Essentially, what need to be as clear as possible are the criteria > for using the generic notification and which is the criteria for > using a MH type. I think that a generic notification mechanism should be used for all in-session signaling for MIPv6, i.e., when there is a BCE for the MN at the HA (or CN). It should be bidirectional, and thus allow signaling both to and from a MN. Having one single in-session signaling mechanism means that we don't have to redesign/respecify message transport, protection, retransmission, sequence numbering etc for each new signaling message. This will make both the specifications and implementations less complex. The Generic Notification Message (GNM), as described in draft-haley-mext-generic-notification-message-00.txt, is a good start for such a mechanism (but see below for enhancements). For a real-life use case, the GNM is spot-on for transmitting flow distribution rules; see http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-00 We are planning to soon write a short draft on how to transmit the rules, both MN->HA and HA->MN, using the GNM. Currently, I see two areas for GNM extension/improvement: - The GNM should support protected signaling also between MN and CN, and not only between MN and HA as seems to be the case right now. - I don't particularly like the "notification" part of GNM's name, as I think it will should be used for more than notifications. Regards, Michael _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 08:04:01 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8C528C200; Thu, 5 Jun 2008 08:04:01 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0E628C190 for ; Thu, 5 Jun 2008 08:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cy0hb5H2Oj4 for ; Thu, 5 Jun 2008 08:03:54 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by core3.amsl.com (Postfix) with ESMTP id 8812128C172 for ; Thu, 5 Jun 2008 08:03:43 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so291904tib.25 for ; Thu, 05 Jun 2008 08:03:47 -0700 (PDT) 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=NnNj+VUHtuZc9TYjl9erzYjpI/uvjrvV8xk3vQbuLHA=; b=lHrmF4s2F6qFw9dbjGGxz13Yf4REy27RpR5ZZ16rFoFgw3AE5jNGLZ3k3Z+LgTtQS7 U1x0eIG9Shh9/VU4tIyYhnDmOUEzjIU1oCYLVQlzz6jV1JqZNuBdt2GkV04erBI6CmJ3 /XOi0Ghs9Bnlgxyo5l/hJZG0TsUfO/AdUe4to= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=v/k3/yJfkS6YdQj9iD6V8gyvvccrewgvQLf8JWrcHQ7rZmT3ueKAXlSKrEIcgxw9E+ qLs8EcH2SaRCzqWZe5M4MaLJnPNIBDKmg+UAaUOOQuQjCFZli6iYDbvJ20jEkXY0pqBM 2RuOIqnMtrZ+nU2Ifk6ZekD+SYdl7kYaer7hA= Received: by 10.110.8.5 with SMTP id 5mr428758tih.3.1212678227159; Thu, 05 Jun 2008 08:03:47 -0700 (PDT) Received: by 10.110.53.11 with HTTP; Thu, 5 Jun 2008 08:03:47 -0700 (PDT) Message-ID: <1d38a3350806050803r31140bf6r5ed39646d5088ec4@mail.gmail.com> Date: Thu, 5 Jun 2008 23:03:47 +0800 From: "Hui Deng" To: "Arnaud Ebalard" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <200806050918.05372.julien.IETF@laposte.net> <87ve0othnn.fsf@natisbad.org> <200806051127.40178.julien.IETF__18347.5074278705$1212658152$gmane$org@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] [Mip6] [rfc3775] Application using the care-of address X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org absolutely correct, Hope more working group people will be awared of this, thanks for the explanation -Hui 2008/6/5 Arnaud Ebalard : > Hello, > > Julien Laganier writes: > >>> > Reason for change: RFC3775 mentions two times the possibility to >>> > use the care-of address as a source address in outgoing packets. In >>> > the first occurence, RFC3775 says that APIs to control this use are >>> > out-of-scope, but since an API that allows an application to >>> > require the care-of address to be used in outgoing packets has been >>> > specified since then in RFC5014, RFC3775bis could mention RFC5014 >>> > as an example of such an API. >>> >>> As a side note (I do not think this fits in the scope of RFC3775bis), >>> there is also a need to control the use of the CoA by the IKE daemon >>> during the negotiation of SA protecting BU/BA because the HoA is not >>> yet available (so not usable). AFAIK, This is not *explicitly* >>> covered by RFC 3775 and RFC 3776 and this specific case cannot be >>> handled using the documents you point. >> >> Why couldn't the IKE process use RFC5014 to ask the IP stack to put the >> CoA in packets it sends? > > This is not the issue; Here is how things happen: the BU created by the > MIPv6 process, uses the CoA as source address in the end (when leaving > the MN) but the packet matches the SP protecting the signaling > traffic. This SP uses the HoA and not the CoA. If no SA is available, a > key manager will handle the negotiation of the SA. The SA being > negotiated also use the HoA. The point is that the key manager usually > selects the source address of the SA being negotiated to perform the > negotiation: in *that* specific case, this cannot be done and the IKE > daemon needs to be told to use the CoA. > > This is decribed in details in the pointer I sent in my previous post. > > Cheers, > > a+ > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 08:42:27 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77B963A6935; Thu, 5 Jun 2008 08:42:27 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524253A6935 for ; Thu, 5 Jun 2008 08:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcdn2XxMcpFV for ; Thu, 5 Jun 2008 08:42:20 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 715623A6846 for ; Thu, 5 Jun 2008 08:42:20 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so399137fga.41 for ; Thu, 05 Jun 2008 08:42:26 -0700 (PDT) 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=8ENq0Ee1KRxH+9acWC23A4AQkThcobUQE7EjsZlUyds=; b=tP1DGx/krk9KQsDtoeP4QvJzE9nfU6msyCd7beFjbXkAOiISMVlemcFHb9kiWXNsP5 v6j+wwWMcWNjhg2UfGpyXe1mTEBX9PI3c4u0Tma6SoZMhIirSiicwKtPjLy7Mu1LEnb1 X2WR5rEMURlq0hYxKGWhLI6LXGNG7qzISAryY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:sender; b=Bvn9E46DfKZ2tnEeLppZm2w5fnIruGQw5OFE3E175DXd5HeO1BQTY1+Qquj+uGBoyY Zx+bntmkHfEZHO7SyXLmxnqmeWghi7/IKmzfyQSA6bmiTwKy8CE8f9+GWR+CyDytxVgq /K3ZCVOf77lPVBgDEBtV8taqjo9kCVMKRVanQ= Received: by 10.86.52.6 with SMTP id z6mr2333892fgz.48.1212680545304; Thu, 05 Jun 2008 08:42:25 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 12sm7086912fks.13.2008.06.05.08.42.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Jun 2008 08:42:24 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Thu, 5 Jun 2008 17:42:38 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <483D5A50.1000208@it.uc3m.es> <20080603104511.GA3314@kafka.verkstad.net> In-Reply-To: <20080603104511.GA3314@kafka.verkstad.net> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806051742.39799.julien.IETF@laposte.net> Subject: [MEXT] Generic Signaling Message / Name of generic "notification" (Was: Scope of generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Tuesday 03 June 2008, Michael Eriksson wrote: > - I don't particularly like the "notification" part of GNM's name, as > =A0 I think it will should be used for more than notifications. Folks, What Michael said above rang a bell :) How about calling the new framework "MIPv6 Generic Signaling Message = (MGSM), and defines two MH types, one requiring IPsec, the other not. Then we would distinguish different types of messages (Revocation, Flow = Distribution Rules, Heartbeat, etc.) based on a subtype inside the = Generic Signaling Message. I think that should satisfy everybody: - the IPsec SPD needs only one set of rules for each of the MH types = (bypass, and protect). - a MGSM consumer (e.g. Revocation, Distribution Rules) simply specify = the MH type it chooses depending on whether or not it requires IPsec = protection. - a MGSM consumer allocates one or more MGSM subtypes for each new = message necessary to implement the consumer's functionality. - a MGSM consumer specifies processing (sending, receiving, state = machines...) for these subtyped messages. What do you think? --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 08:45:34 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1A7B3A68C9; Thu, 5 Jun 2008 08:45:34 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37A503A68C9 for ; Thu, 5 Jun 2008 08:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdnWx5lArljh for ; Thu, 5 Jun 2008 08:45:31 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id BEA7D3A6846 for ; Thu, 5 Jun 2008 08:45:30 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m55FjT412753; Thu, 5 Jun 2008 15:45:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Jun 2008 10:45:26 -0500 Message-ID: In-Reply-To: <200806051742.39799.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Generic Signaling Message / Name of generic "notification" (Was: [MEXT] Scope of generic notification) Thread-Index: AcjHIsManrp5xPEkQBOyf6GZJRN2kwAAAZeg References: <483D5A50.1000208@it.uc3m.es> <20080603104511.GA3314@kafka.verkstad.net> <200806051742.39799.julien.IETF@laposte.net> From: "Ahmad Muhanna" To: "Julien Laganier" , Subject: Re: [MEXT] Generic Signaling Message / Name of generic "notification" (Was: Scope of generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Thanks Julien. = This a good framework which address all concerns and flexible enough! Regards, Ahmad = > -----Original Message----- > From: julien laganier [mailto:julien.laganier@gmail.com] On = > Behalf Of Julien Laganier > Sent: Thursday, June 05, 2008 10:43 AM > To: mext@ietf.org > Cc: Michael Eriksson; marcelo bagnulo braun; Muhanna, Ahmad = > (RICH1:2H10) > Subject: Generic Signaling Message / Name of generic = > "notification" (Was: [MEXT] Scope of generic notification) > = > On Tuesday 03 June 2008, Michael Eriksson wrote: > > - I don't particularly like the "notification" part of = > GNM's name, as > > =A0 I think it will should be used for more than notifications. > = > Folks, > = > > = > What Michael said above rang a bell :) > = > How about calling the new framework "MIPv6 Generic Signaling = > Message (MGSM), and defines two MH types, one requiring = > IPsec, the other not. > = > Then we would distinguish different types of messages = > (Revocation, Flow Distribution Rules, Heartbeat, etc.) based = > on a subtype inside the Generic Signaling Message. > = > I think that should satisfy everybody: > - the IPsec SPD needs only one set of rules for each of the = > MH types (bypass, and protect). > - a MGSM consumer (e.g. Revocation, Distribution Rules) = > simply specify the MH type it chooses depending on whether or = > not it requires IPsec protection. > - a MGSM consumer allocates one or more MGSM subtypes for = > each new message necessary to implement the consumer's functionality. > - a MGSM consumer specifies processing (sending, receiving, state > machines...) for these subtyped messages. > = > What do you think? > = > --julien > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 08:53:31 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271E13A698C; Thu, 5 Jun 2008 08:53:31 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BF9A3A693D for ; Thu, 5 Jun 2008 08:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZQGu0sftnQz for ; Thu, 5 Jun 2008 08:53:28 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8499B3A6846 for ; Thu, 5 Jun 2008 08:53:28 -0700 (PDT) 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 m55FrS425240; Thu, 5 Jun 2008 15:53:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Jun 2008 10:53:14 -0500 Message-ID: In-Reply-To: <200806051742.39799.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Generic Signaling Message / Name of generic "notification" (Was: Scope of generic notification) Thread-Index: AcjHItK4WSWwOUapRxO+JETmEFcuPQAAWTEw From: "Mohamed Khalil" To: "Julien Laganier" , Subject: Re: [MEXT] Generic Signaling Message / Name of generic "notification" (Was: Scope of generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org agree Mohamed -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Jul= ien Laganier Sent: Thursday, June 05, 2008 10:43 AM To: mext@ietf.org Subject: [MEXT] Generic Signaling Message / Name of generic "notification" = (Was: Scope of generic notification) On Tuesday 03 June 2008, Michael Eriksson wrote: > - I don't particularly like the "notification" part of GNM's name, as > =A0 I think it will should be used for more than notifications. Folks, What Michael said above rang a bell :) How about calling the new framework "MIPv6 Generic Signaling Message = (MGSM), and defines two MH types, one requiring IPsec, the other not. Then we would distinguish different types of messages (Revocation, Flow = Distribution Rules, Heartbeat, etc.) based on a subtype inside the = Generic Signaling Message. I think that should satisfy everybody: - the IPsec SPD needs only one set of rules for each of the MH types = (bypass, and protect). - a MGSM consumer (e.g. Revocation, Distribution Rules) simply specify = the MH type it chooses depending on whether or not it requires IPsec = protection. - a MGSM consumer allocates one or more MGSM subtypes for each new = message necessary to implement the consumer's functionality. - a MGSM consumer specifies processing (sending, receiving, state = machines...) for these subtyped messages. What do you think? --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 09:04:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4D673A69FF; Thu, 5 Jun 2008 09:04:51 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1B43A69FF for ; Thu, 5 Jun 2008 09:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlIXdvOXff0k for ; Thu, 5 Jun 2008 09:04:49 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.245.51]) by core3.amsl.com (Postfix) with SMTP id 632A83A6935 for ; Thu, 5 Jun 2008 09:04:49 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-119.messagelabs.com!1212681891!25858603!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9018 invoked from network); 5 Jun 2008 16:04:51 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-119.messagelabs.com with SMTP; 5 Jun 2008 16:04:51 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m55G4ovo000294 for ; Thu, 5 Jun 2008 09:04:50 -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 m55G4ocx004986 for ; Thu, 5 Jun 2008 11:04:50 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id m55G4nWc004958 for ; Thu, 5 Jun 2008 11:04:49 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Jun 2008 17:04:48 +0100 Message-ID: <48480E9B.3030709@gmail.com> Date: Thu, 05 Jun 2008 18:04:43 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Julien Laganier References: <483D5A50.1000208@it.uc3m.es> <20080603104511.GA3314@kafka.verkstad.net> <200806051742.39799.julien.IETF@laposte.net> In-Reply-To: <200806051742.39799.julien.IETF@laposte.net> X-Antivirus: avast! (VPS 080604-1, 04/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 05 Jun 2008 16:04:48.0822 (UTC) FILETIME=[E154FD60:01C8C725] X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] Generic Signaling Message / Name of generic "notification" (Was: Scope of generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien Laganier wrote: > On Tuesday 03 June 2008, Michael Eriksson wrote: >> - I don't particularly like the "notification" part of GNM's name, >> as I think it will should be used for more than notifications. > > Folks, > > > > What Michael said above rang a bell :) > > How about calling the new framework "MIPv6 Generic Signaling Message > (MGSM), and defines two MH types, one requiring IPsec, the other > not. > > Then we would distinguish different types of messages (Revocation, > Flow Distribution Rules, Heartbeat, etc.) based on a subtype inside > the Generic Signaling Message. > > I think that should satisfy everybody: - the IPsec SPD needs only one > set of rules for each of the MH types (bypass, and protect). - a MGSM > consumer (e.g. Revocation, Distribution Rules) simply specify the MH > type it chooses depending on whether or not it requires IPsec > protection. - a MGSM consumer allocates one or more MGSM subtypes for > each new message necessary to implement the consumer's functionality. > - a MGSM consumer specifies processing (sending, receiving, state > machines...) for these subtyped messages. > > What do you think? Huh? Doesn't MIPv6 already have signaling? BU/BAck/BErr/BRR/RR/etc are _not_ signaling? Revocation can be done by sending BAck lifetime 0. Flow Distribution rules can be sent by UDP (much higher level than MIP6) payloads encoding flow labels and traffic classes, or with http payloads containing XML descriptions of these flows. Heartbeats are periodic messages, which BUs are. Or is it that 3GPP requires this? If 3GPP requires this framework then it may make sense to call it "3GPP MIPv6 Generic Signaling Message (3MGSM)", no? Sorry if it sounds way off the current understanding, I may miss something. Alex > > --julien _______________________________________________ MEXT mailing > list MEXT@ietf.org https://www.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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 09:17:13 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A71B3A6866; Thu, 5 Jun 2008 09:17:13 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E68DA3A685B for ; Thu, 5 Jun 2008 09:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSwoaojBFH9c for ; Thu, 5 Jun 2008 09:17:08 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id DD2A73A6866 for ; Thu, 5 Jun 2008 09:17:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ILnIcaowfK8CVo90mnmtlEy1GnbZpeAx+pOgCGNOdw6y8PFqB3SbIzg9Q9dgB8PD; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.89]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1K4I9K-00014i-5d; Thu, 05 Jun 2008 12:17:14 -0400 Message-ID: <48481187.3010206@earthlink.net> Date: Thu, 05 Jun 2008 09:17:11 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Julien Laganier References: <483D5A50.1000208@it.uc3m.es> <20080603104511.GA3314@kafka.verkstad.net> <200806051742.39799.julien.IETF@laposte.net> In-Reply-To: <200806051742.39799.julien.IETF@laposte.net> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f523e230d8c41cf3f182358e010e10f74e1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: mext@ietf.org Subject: Re: [MEXT] Generic Signaling Message / Name of generic "notification" (Was: Scope of generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Julien, Could you provide some examples of messages that would NOT fit as subtypes of the proposed generic signaling message? Regards, Charlie P. Julien Laganier wrote: > On Tuesday 03 June 2008, Michael Eriksson wrote: > >> - I don't particularly like the "notification" part of GNM's name, as >> I think it will should be used for more than notifications. >> > > Folks, > > > > What Michael said above rang a bell :) > > How about calling the new framework "MIPv6 Generic Signaling Message > (MGSM), and defines two MH types, one requiring IPsec, the other not. > > Then we would distinguish different types of messages (Revocation, Flow > Distribution Rules, Heartbeat, etc.) based on a subtype inside the > Generic Signaling Message. > > I think that should satisfy everybody: > - the IPsec SPD needs only one set of rules for each of the MH types > (bypass, and protect). > - a MGSM consumer (e.g. Revocation, Distribution Rules) simply specify > the MH type it chooses depending on whether or not it requires IPsec > protection. > - a MGSM consumer allocates one or more MGSM subtypes for each new > message necessary to implement the consumer's functionality. > - a MGSM consumer specifies processing (sending, receiving, state > machines...) for these subtyped messages. > > What do you think? > > --julien > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 09:55:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6C93A6977; Thu, 5 Jun 2008 09:55:53 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1B73A69FF for ; Thu, 5 Jun 2008 09:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47AV88YDFBts for ; Thu, 5 Jun 2008 09:55:50 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id EDDA53A69D9 for ; Thu, 5 Jun 2008 09:55:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,596,1204531200"; d="scan'208";a="30639883" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 05 Jun 2008 09:55:57 -0700 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 m55Gtvn1027948; Thu, 5 Jun 2008 09:55:57 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m55GtvAO004752; Thu, 5 Jun 2008 16:55:57 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jun 2008 09:55:57 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jun 2008 09:55:56 -0700 From: "Sri Gundavelli" To: "'George Tsirtsis'" , References: Date: Thu, 5 Jun 2008 09:55:53 -0700 Message-ID: <000001c8c72d$063c73e0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciP9P2gydo37mldT4qs073KbK9SkA3N+liw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 05 Jun 2008 16:55:57.0201 (UTC) FILETIME=[063A7810:01C8C72D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2601; t=1212684957; x=1213548957; 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]=20[RFC3775=20changes]=20De-regis tration=20when=20returning=20home(another=20atempt) |Sender:=20; bh=ckROn+LOHYHNEscQEnUmcz2foyUkDbTHz9v+HKa/cOk=; b=GaldhgmBpopB4gSDUk4WiYFxCfl+am54H7Z1yz22ztHO0i/4l4IE1ZeMB8 oWgo4D+VsOTEsTT7+7rCDEMkJXD9s6NYoyCQFpasSpFbMIB+s2DlNHCohdlf 7NdMfm08Ny; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home(another atempt) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org George, To close this issue. I'm ok with the proposed text. Sri > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of George Tsirtsis > Sent: Thursday, March 27, 2008 3:26 AM > To: mext@ietf.org > Subject: [MEXT] [RFC3775 changes] De-registration when > returning home(another atempt) > > Hi all, > > Here is another attempt to resolve this issue. I think the discussion, > although somewhat painful, has been illuminating and now people seem > to at least understand why this is currently a SHOULD. I think there > is also agreement on what the MN needs to do depending on its > connectivity situation and its desire to use the home link or not. > > I think people also understand that this is somewhat related to the > PMIP/MIP interactions discussion in NETLMM WG. In that sense the > following is proposed with the understanding that *connecting* to the > home link, does not automatically invalidate the HA binding pointing > to a foreign link. The HA BCEs for the MN are only removed if a dereg > BU is sent by the MN and received by the HA. It is also, however, > recognized that the MN must indeed send a dereg BU before > sending/receiving traffic over the home link. > > We should now be able to come to some agreement, which of course will > not be possible unless people are flexible and recognize the effort to > capture the discussion in the following: > > OLD TEXT: > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node SHOULD then send a Binding Update to its > home agent, > to instruct its home agent to no longer intercept or tunnel packets > for it. > > NEW TEXT: > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > Although the home link may not be immediately used, e.g., > if the mobile > node still maintains foreign links, the mobile node MUST > send a Binding > Update to its home agent, to instruct its home agent to no > longer intercept > or tunnel packets for it, before sending/receiving traffic on its > home link. > > > Regards > George > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 09:58:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB1DB3A697D; Thu, 5 Jun 2008 09:58:16 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33423A6977 for ; Thu, 5 Jun 2008 09:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnIhSmpDobc3 for ; Thu, 5 Jun 2008 09:58:14 -0700 (PDT) Received: from web84302.mail.re1.yahoo.com (web84302.mail.re1.yahoo.com [69.147.74.181]) by core3.amsl.com (Postfix) with SMTP id 4B2753A6800 for ; Thu, 5 Jun 2008 09:58:14 -0700 (PDT) Received: (qmail 57615 invoked by uid 60001); 5 Jun 2008 16:58:20 -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=B+YR9aWJEy3hAyi7oOLA183kMuLA55aqGravBG1kEBPVMYg0q+Lu9/S8cqnDEw0N59iolcxqPHgtvBAdmE8lYjUCJqn6LGDiBHeRgZ50iHgW40/thf+gvOeZrTcZaH0b5YZFErsxNlG9zF9SxhRXdxppSzs5cuvTHhkgvxUHMy8=; X-YMail-OSG: YreTR2MVM1nAj8NwHMXIDv4YVvq2JgPTXuxJDhfqn0VaJonMLDxx2RI_panV3j1mNgO7lGIo.MzCKvgdvhmAaKF4o8hWS6Wl2KMPdi_pt.WYX3hChhYorgJXuAg- Received: from [206.16.17.212] by web84302.mail.re1.yahoo.com via HTTP; Thu, 05 Jun 2008 09:58:20 PDT X-Mailer: YahooMailRC/975.41 YahooMailWebService/0.7.185 Date: Thu, 5 Jun 2008 09:58:20 -0700 (PDT) From: Behcet Sarikaya To: marcelo bagnulo braun MIME-Version: 1.0 Message-ID: <677175.56762.qm@web84302.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Inconsistence in prefix delegation between NEMO and PMIPv6 //Re: Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 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="===============1368991900==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1368991900== Content-Type: multipart/alternative; boundary="0-1384539999-1212685100=:56762" --0-1384539999-1212685100=:56762 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Marcelo,=0A The technical problem is very similar to what PMIPv6 has. P= MIPv6 draft (which will become RFC soon) is recommending to use PBU/PBA (BU= /BA) in the visited link. =0A This sets a precedence for MR's prefix confi= guration problem. It is interesting to note that this precedence did not ex= ist when draft-droms-mext-nemo-pd was initially written, so we can understa= nd why they sticked to their original solution.=0A The question is, should= WG also?=0A=0ARegards,=0A=0ABehcet=0A=0A=0A----- Original Message ----=0AF= rom: marcelo bagnulo braun =0ATo: Frank Xia =0ACc: mext@ietf.org; Julien Laganier =0ASent: Wednesday, June 4, 2008 3:02:08 AM=0ASubject: Re: [MEXT] Inconsis= tence prefix delegation between NEMO and PMIPv6 //Re: Adoption of draft-dro= ms-mext-nemo-pd-00.txt?=0A=0AHi Frank,=0A=0Aas i mentioned before, the WG c= onsensus reached in last ietf meeting and =0Aconfirmed in the mext ml is to= use dhcp or this and NOT BU for this=0A=0Aso, this discussion is closed an= d now we need to proceed to figure out =0Awhich is the way we use dhcp for = this=0A=0ARegards, marcelo=0A=0A=0AFrank Xia escribi=F3:=0A> Hi Chairs and = Ralph=0A>=0A> As to prefix delegation, PMIPv6 is using BU&BA to delegate pr= efixes.=0A> In this draft, we abandoned this machinism, IMHO which seems to= be =0A> applicable=0A> in NEMO scenario.=0A>=0A> I don't think we need bra= nd new design just because there are some =0A> tiny differences.=0A>=0A> BR= =0A> Frank=0A> ----- Original Message ----- From: "marcelo bagnulo braun" = =0A> =0A> To: ; "Julien Laganier" ; =0A> "Ralph Droms" =0A> Sent: Friday= , May 30, 2008 9:51 AM=0A> Subject: [MEXT] Adoption of draft-droms-mext-nem= o-pd-00.txt?=0A>=0A>=0A>> Hi,=0A>>=0A>> We would like to ask the WG what is= their opinion about accepting=0A>> draft-droms-mext-nemo-pd-00.txt as the = WG document for the Nemo PD=0A>> deliverable included in our charter.=0A>>= =0A>> Please provide comments so we cna make some progress on this long=0A>= > overdue deliverable=0A>>=0A>> thanks, Julien and marcelo=0A>>=0A>> ------= -- Mensaje original --------=0A>> Asunto: I-D Action:draft-droms-mext-nemo-= pd-00.txt=0A>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT)=0A>> De: Intern= et-Drafts@ietf.org=0A>> Responder a: internet-drafts@ietf.org=0A>> Para: i-= d-announce@ietf.org=0A>>=0A>>=0A>>=0A>> A New Internet-Draft is available f= rom the on-line Internet-Drafts =0A>> directories.=0A>>=0A>> Title = : DHCPv6 Prefix Delegation for NEMO=0A>> Author(s) : R. Droms, et a= l.=0A>> Filename : draft-droms-mext-nemo-pd-00.txt=0A>> Pages = : 12=0A>> Date : 2008-05-30=0A>>=0A>> One aspect of network = mobility support is the assignment of a prefix=0A>> or prefixes to a Mobile= Router (MR) for use on the links in the=0A>> Mobile Network. DHCPv6 prefi= x delegation can be used for this=0A>> configuration task.=0A>>=0A>> A URL = for this Internet-Draft is:=0A>> http://www.ietf.org/internet-drafts/draft-= droms-mext-nemo-pd-00.txt=0A>>=0A>> Internet-Drafts are also available by a= nonymous FTP at:=0A>> ftp://ftp.ietf.org/internet-drafts/=0A>>=0A>> Below i= s the data which will enable a MIME compliant mail reader=0A>> implementati= on to automatically retrieve the ASCII version of the=0A>> Internet-Draft.= =0A>>=0A>>=0A>>=0A>=0A>=0A> -----------------------------------------------= --------------------------------- =0A>=0A>=0A>=0A>> _______________________= ________________________=0A>> I-D-Announce mailing list=0A>> I-D-Announce@i= etf.org=0A>> https://www.ietf.org/mailman/listinfo/i-d-announce=0A>> Intern= et-Draft directories: http://www.ietf.org/shadow.html=0A>> or ftp://ftp.iet= f.org/ietf/1shadow-sites.txt=0A>>=0A>>=0A>=0A>=0A> ------------------------= -------------------------------------------------------- =0A>=0A>=0A>=0A>> = _______________________________________________=0A>> MEXT mailing list=0A>>= MEXT@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/mext=0A>>=0A>=0A>= =0A>=0A=0A_______________________________________________=0AMEXT mailing li= st=0AMEXT@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/mext=0A --0-1384539999-1212685100=:56762 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Marcelo,
  The technical problem is very si= milar to what PMIPv6 has. PMIPv6 draft (which will become RFC soon) is reco= mmending to use PBU/PBA (BU/BA) in the visited link.
  This sets a= precedence for MR's prefix configuration problem. It is interesting to not= e that this precedence did not exist when draft-droms-mext-nemo-pd was init= ially written, so we can understand why they sticked to their original solu= tion.
  The question is, should WG also?

Regards,

Beh= cet

----- Original Message ----
From: marcelo bagnulo bra= un <marcelo@it.uc3m.es>
To: Frank Xia <xiayangsong@huawei.com>
Cc: mext@ietf.org; Julien Laganier <j= ulien.IETF@laposte.net>
Sent: Wednesday, June 4, 2008 3:02:08 AM
S= ubject: Re: [MEXT] Inconsistence prefix delegation between NEMO and PMIPv6 = //Re: Adoption of draft-droms-mext-nemo-pd-00.txt?

=0AHi Frank,
<= br>as i mentioned before, the WG consensus reached in last ietf meeting and=
confirmed in the mext ml is to use dhcp or this and NOT BU for this
so, this discussion is closed and now we need to proceed to figure out=
which is the way we use dhcp for this

Regards, marcelo

<= br>Frank Xia escribi=F3:
> Hi Chairs and Ralph
>
> As to = prefix delegation, PMIPv6 is using BU&BA to delegate prefixes.
> = In this draft, we abandoned this machinism, IMHO which seems to be
>= applicable
> in NEMO scenario.
>
> I don't think we need= brand new design just because there are some
> tiny differences.>
> BR
> Frank
> ----- Original Message ----- From: "= marcelo bagnulo braun"
> <marcelo@it.uc3m.es>
> To:= <mext@ietf.org>; "Julien Laganier" <= ;julien.IETF@laposte.net>;
> "Ralph Droms" <rdroms= @cisco.com>
> Sent: Friday, May 30, 2008 9:51 AM
> Subje= ct: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?
>
>
= >> Hi,
>>
>> We would like to ask the WG what is th= eir opinion about accepting
>> draft-droms-mext-nemo-pd-00.txt as = the WG document for the Nemo PD
>> deliverable included in our cha= rter.
>>
>> Please provide comments so we cna make some p= rogress on this long
>> overdue deliverable
>>
>>= ; thanks, Julien and marcelo
>>
>> -------- Mensaje origi= nal --------
>> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt
>> Fecha: Fri, 30 May 2008= 05:45:01 -0700 (PDT)
>> De: Internet-Drafts@ietf.org=
>> Responder a: internet-drafts@ietf.org
= >> Para: i-d-announce@ietf.org
>>
>>
= >>
>> A New Internet-Draft is available from the on-line Int= ernet-Drafts
>> directories.
>>
>> Title  =         : DHCPv6 Prefix Delegation for NEMO
>>= ; Author(s)      : R. Droms, et al.
>> Filename&nb= sp;       : draft-droms-mext-nemo-pd-00.txt
>> Page= s          : 12
>> Date    &nb= sp;       : 2008-05-30
>>
>> One aspect of ne= twork mobility support is the assignment of a prefix
>> or prefixe= s to a Mobile Router (MR) for use on the links in the
>> Mobile Ne= twork.  DHCPv6 prefix delegation can be used for this
>> conf= iguration task.
>>
>> A URL for this Internet-Draft is:>> http://www.ietf.org/internet-drafts/draft= -droms-mext-nemo-pd-00.txt
>>
>> Internet-Drafts are = also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/<= /a>
>>
>> Below is the data which will enable a MIME comp= liant mail reader
>> implementation to automatically retrieve the = ASCII version of the
>> Internet-Draft.
>>
>>
>>
>
>
>= ; -------------------------------------------------------------------------= -------
>
>
>
>> ______________________________= _________________
>> I-D-Announce mailing list
>> = I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/li= stinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shad= ow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
&g= t;>
>>
>
>
> --------------------------------= ------------------------------------------------
>
>
>
>> _____________________________________= __________
>> MEXT mailing list
>> MEXT@ietf.org
>> <= a href=3D"https://www.ietf.org/mailman/listinfo/mext" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/mext
>>
>
>
= >

_______________________________________________
MEXT mailing= list
= MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
=
--0-1384539999-1212685100=:56762-- --===============1368991900== 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://www.ietf.org/mailman/listinfo/mext --===============1368991900==-- From mext-bounces@ietf.org Thu Jun 5 10:02:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 537D43A68E6; Thu, 5 Jun 2008 10:02:51 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC8633A6800 for ; Thu, 5 Jun 2008 10:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMQBhy+bFwTi for ; Thu, 5 Jun 2008 10:02:45 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 5E2B83A6C01 for ; Thu, 5 Jun 2008 10:02:45 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m55H2k426139; Thu, 5 Jun 2008 17:02:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Jun 2008 12:02:43 -0500 Message-ID: In-Reply-To: <48480E9B.3030709@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Generic Signaling Message / Name of generic "notification" (Was: Scope of generic notification) Thread-Index: AcjHJfhHaXQx6ZJEQtuV8px2ZcwmbAAB1ZQg References: <483D5A50.1000208@it.uc3m.es> <20080603104511.GA3314@kafka.verkstad.net> <200806051742.39799.julien.IETF@laposte.net> <48480E9B.3030709@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" , "Julien Laganier" Cc: mext@ietf.org Subject: Re: [MEXT] Generic Signaling Message / Name of generic "notification" (Was: Scope of generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > > > I think that should satisfy everybody: - the IPsec SPD > needs only one > > set of rules for each of the MH types (bypass, and > protect). - a MGSM > > consumer (e.g. Revocation, Distribution Rules) simply > specify the MH > > type it chooses depending on whether or not it requires IPsec > > protection. - a MGSM consumer allocates one or more MGSM > subtypes for > > each new message necessary to implement the consumer's > functionality. > > - a MGSM consumer specifies processing (sending, receiving, state > > machines...) for these subtyped messages. > > > > What do you think? > > Huh? Doesn't MIPv6 already have signaling? > BU/BAck/BErr/BRR/RR/etc are _not_ signaling? > > Revocation can be done by sending BAck lifetime 0. [Ahmad] Hi Alex, Did you mean a BU with lifetime = 0 ? _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 10:38:33 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 212493A6BF9; Thu, 5 Jun 2008 10:38:33 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCD043A6BF9 for ; Thu, 5 Jun 2008 10:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OL93OLShytm for ; Thu, 5 Jun 2008 10:38:31 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id E68803A6AB0 for ; Thu, 5 Jun 2008 10:38:30 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Jun 2008 13:38:26 -0400 Message-ID: In-Reply-To: <87ve0othnn.fsf@natisbad.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [rfc3775] Application using the care-of address Thread-Index: AcjG5dWMRZL839TnSe+lHN6njBh4jAATMs4Q References: <200806050918.05372.julien.IETF@laposte.net> <87ve0othnn.fsf@natisbad.org> From: "Vijay Devarapalli" To: "Arnaud Ebalard" , "Julien Laganier" Cc: mext@ietf.org Subject: Re: [MEXT] [rfc3775] Application using the care-of address X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > As a side note (I do not think this fits in the scope of RFC3775bis), > there is also a need to control the use of the CoA by the IKE daemon > during the negotiation of SA protecting BU/BA because the HoA > is not yet > available (so not usable). AFAIK, This is not *explicitly* covered by > RFC 3775 and RFC 3776 and this specific case cannot be > handled using the > documents you point. Its not clear what is "not explicitly" covered in 3775 and 3776. RFC 3776 says o In addition to the rules above, if dynamic keying is used, the key management protocol MUST use the care-of address as the source address in the protocol exchanges with the mobile node's home agent. Vijay > > For more details on that, see draft-sugimoto-mip-pfkey-migrate-04. > > Cheers, > > a+ > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 11:44:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2853A6AD6; Thu, 5 Jun 2008 11:44:40 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A8E3A6CD4 for ; Thu, 5 Jun 2008 11:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JN3VLDMYlTKR for ; Thu, 5 Jun 2008 11:44:37 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id 9C3FD3A6A2B for ; Thu, 5 Jun 2008 11:44:37 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m53FbXXL068961; Tue, 3 Jun 2008 17:37:33 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200806031537.m53FbXXL068961@givry.fdupont.fr> From: Francis Dupont To: Alexandru Petrescu In-reply-to: Your message of Tue, 03 Jun 2008 16:43:46 +0200. <484558A2.3040004@gmail.com> Date: Tue, 03 Jun 2008 17:37:33 +0200 Cc: mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org In your previous mail you wrote: > => I don't understand: the home link is a part of the mobility > service, do you describe something where all links are home links? YEs, I describe something where all links have hosts attached to them and need to become mobile. => this is far from the default model... > => obviously we have not the same definition of a mobility service > (and for me the only difference between a HA and a 'road warrior' VPN > server is the HA supports real mobility, not nomadism). Well yes we don't have the same definition of the mobility service. If one sees it as an independent service where the mobiles never connect directly to the home link, never at home, then I believe Mobile IPv6 has never been used for that purpose, I've never seen it as such - have you? => this is the operator model where the home link can be virtual but many think more about some kind of extended nomadism: hosts are by default at home but they can become mobile using heterogeneous layer 2 technologies. Why would one bother always encapsulating all packets, especially when many mobile wireless links offer mobility already. => this doesn't work with heterogeneous technologies and with other words the network layer is the first universal layer. Regards Francis.Dupont@fdupont.fr PS: my main concern about DHAAD is it is intrinsically impossible to secure (cf the DHAAD considered harmful I-D which is reviving...). IMHO it should be removed from RFC 3775 (i.e., its status should be more "elective"). _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 11:44:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E503E3A6D25; Thu, 5 Jun 2008 11:44:40 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F88D3A6A2B for ; Thu, 5 Jun 2008 11:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+6u8qArKf0X for ; Thu, 5 Jun 2008 11:44:38 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id 6590B3A6AD6 for ; Thu, 5 Jun 2008 11:44:38 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m53FHoIN068860; Tue, 3 Jun 2008 17:17:50 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200806031517.m53FHoIN068860@givry.fdupont.fr> From: Francis Dupont To: Alexandru Petrescu In-reply-to: Your message of Tue, 03 Jun 2008 16:30:38 +0200. <4845558E.1020206@gmail.com> Date: Tue, 03 Jun 2008 17:17:50 +0200 Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] side discussion about discovering a HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org In your previous mail you wrote: > => you assume the HoA is wired down in MN, I strongly disagree: this > is not a coomon rule and there are many reasons which make this a bad > idea. YEs I assumed that. If neither the HoA nor the home prefix are hardcoded in the MN then there are few chances MN needs to discover a HA at some remote across the Internet - just use the locally provided address. => I believed the boostrapping stuff was just about this and it seems the name of a mobility service/server (note a mobility server is in fact a HA) was enough? > PS: and this doesn't make DNS not usable: some of the addresses bound > to the service/HA name should be in the expected prefix (with 2^64 > addresses per prefix :-). I don't understand, what's an expected prefix? => the prefix where is the HoA and where should be the HA. How is an expected prefix allowing DNS SRV RR for bootstrapping to not require each subnet which may constitute a home link to be assigned a subdomain name? => because DNS resource records come per set. With other words the DNS can provide many HA addresses so if you'd like to provide some HA addresses per home link you can if the number of addresses is still reasonnable. BTW I don't see a reason to use more than a few home links. In the GSM, a HLR or VLR handles millions of users... Regards Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 11:44:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79DCE3A6D3A; Thu, 5 Jun 2008 11:44:45 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B92033A6C82 for ; Thu, 5 Jun 2008 11:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjw+UtO+7Fvb for ; Thu, 5 Jun 2008 11:44:43 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id 9B8B93A6BBC for ; Thu, 5 Jun 2008 11:44:42 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m539mJsx067193; Tue, 3 Jun 2008 11:48:19 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200806030948.m539mJsx067193@givry.fdupont.fr> From: Francis Dupont To: Alexandru Petrescu In-reply-to: Your message of Tue, 03 Jun 2008 10:24:14 +0200. <4844FFAE.3090604@gmail.com> Date: Tue, 03 Jun 2008 11:48:19 +0200 Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] side discussion about discovering a HA (was: Adoption of draft-droms-mext-nemo-pd-00.txt?) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org In your previous mail you wrote: > It's a bad idea to extend DNS for discovering stuff. DNS is not for > discovery. > > => RFC 2782 (aka DNS SRV RR) is enough used to prove you are wrong. Similarly to how a DHCP Client wouldn't DNS to discover a DHCP Server, a MN wouldn't DNS to discover a HA. => I don't but your argument because DHCP is constraint to be link-local (for an obvious reason for address assignment and only by keeping the design for stateless or PD). This is not the case for the mobility service, so the not-local HA discovery (DHAAD) can be replaced by the DNS. (note the local HA discovery is done by the HA info option in RAs and has far less problems than DHAAD). Of course, one _would_ DNS to discover a LDAP, printing, SIP, web service. => (global) mobility service? Regards Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 11:44:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F39EA3A6D43; Thu, 5 Jun 2008 11:44:45 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 916293A6D39 for ; Thu, 5 Jun 2008 11:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbvQD3l766LN for ; Thu, 5 Jun 2008 11:44:43 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id 730F63A68A2 for ; Thu, 5 Jun 2008 11:44:43 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m539TSv8067080; Tue, 3 Jun 2008 11:29:28 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200806030929.m539TSv8067080@givry.fdupont.fr> From: Francis Dupont To: arno@natisbad.org (Arnaud Ebalard) In-reply-to: Your message of Tue, 03 Jun 2008 09:51:43 +0200. <87ej7f3qi8.fsf@natisbad.org> Date: Tue, 03 Jun 2008 11:29:28 +0200 Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org In your previous mail you wrote: > ... BTW there is simple solution if IPsec is applied > to all packets in the MR-HA tunnel. If both protocols interact badly and IPsec is the best way to protect DHCPv6 traffic, then the Security Consideration section definitely needs to clarify that. What do you think? => there is a potential bootstrapping issue because sending packets on the MR-HA tunnel is fine but doesn't work before this tunnel is established... Note when the MR has the relay agent function, we can simply apply RFC 3315 21.1 "Relay agents and servers that exchange messages securely use the IPsec mechanisms for IPv6..." so the only thing to do is to configure IPsec knowing addresses, protocol and ports. Regards Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 11:44:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722F03A6D4B; Thu, 5 Jun 2008 11:44:47 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 501183A6D4B for ; Thu, 5 Jun 2008 11:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBJSuts1G8Cx for ; Thu, 5 Jun 2008 11:44:45 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id 6D51B3A6CD4 for ; Thu, 5 Jun 2008 11:44:44 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m52MP8So064030; Tue, 3 Jun 2008 00:25:08 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200806022225.m52MP8So064030@givry.fdupont.fr> From: Francis Dupont To: arno@natisbad.org (Arnaud Ebalard) In-reply-to: Your message of Fri, 30 May 2008 22:38:17 +0200. <87mym74jeu.fsf@natisbad.org> Date: Tue, 03 Jun 2008 00:25:08 +0200 Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org In your previous mail you wrote: On the other side, I wonder if it is not overkill (complexity, roundtrips, ...) for a use in small devices (phone?, PDA?) that will serve a single subnet with IPv6 stateless @ autoconf=20 => I believe you are talking about MRs so as the DHCPv6 use (and support requirement) is at the initiative of the client/MR there is no issue: simply don't use it (and don't support it) on pico devices. IMHO, this is a bit simplistic to delegate the security of NEMO PD to the Security Considerations sections of DHCPv6 and DHCPv6 PD documents. There are good chances that the environments where MR will operate may be a bit more hostile than those where more common routers are expected to operate (in operators or corporate networks). => in fact I think the opposite: the critical parts will be protected, for instance the MR-HA tunnel protected by ESP for all packets. Some initial thoughts: * What are the hypothesis behind 3315 and 3633 design decisions that do not hold anymore in MIPv6 environments (if any)? => IMHO none. * "HAs and MRs SHOULD use DHCPv6 authentication": Why not a "MUST"? => mainly because there are better ways and when they are used the weak DHCPv6 authentication is useless (or worse). * how do the security mechanisms of both protocols interact? => badly! * In the simple mode (no relay), how will the use of multicast interact with IPsec protection of traffic if it is in place? => this is an IPsec issue. When IPsec protects all packets multicast doesn't matter. * HMAC-MD5-based authentication method is the only one defined in 3315. Is it sufficient? => HMAC-MD5 is not yet proved broken but I agree it is not the best choice (I have a nice reference with comment for the same issue in TSIG). * What is the impact of the assignment of new prefixes in a dynamic fashion w.r.t. the SPD and SADB or IKE daemons? How should that be handled. => irrelevant and BTW there is simple solution if IPsec is applied to all packets in the MR-HA tunnel. Regards Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 11:44:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E94DA3A6D52; Thu, 5 Jun 2008 11:44:48 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6F63A6D52 for ; Thu, 5 Jun 2008 11:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41mKWHsS0SHN for ; Thu, 5 Jun 2008 11:44:46 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id 445F83A68A2 for ; Thu, 5 Jun 2008 11:44:45 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m52MYeoK064127; Tue, 3 Jun 2008 00:34:40 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200806022234.m52MYeoK064127@givry.fdupont.fr> From: Francis Dupont To: "Vijay Devarapalli" In-reply-to: Your message of Sun, 01 Jun 2008 21:45:00 EDT. Date: Tue, 03 Jun 2008 00:34:40 +0200 Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org In your previous mail you wrote: IMO, we should remove the extensions to DHAAD from this document. It's a bad idea to keep extending DHAAD every time we add an extension to MIPv6. => we have to do this (extend DHAAD) until there will be a consensus about phasing out DHAAD (DHAAD considered harmful is reviving :-). We could extend DNS-based HA lookup for discovering a home agent that is capable of NEMO prefix delegation. But I think this is also unnecessary. The mobile router can always try the next home agent in the list of the home agents if the first one does not respond to DHCPv6 messages. If none of the home agents are capable of prefix delegation, then there is nothing the mobile router can do about it, maybe use some static mobile network prefixes. => I agree Thanks Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 5 19:43:13 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D58DA3A680F; Thu, 5 Jun 2008 19:43:13 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1A93A693F for ; Thu, 5 Jun 2008 19:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orfzIBLt3djs for ; Thu, 5 Jun 2008 19:43:05 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 8D31E3A684A for ; Thu, 5 Jun 2008 19:43:00 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id m562h2P5010073; Fri, 6 Jun 2008 11:43:02 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id m562h2l03859; Fri, 6 Jun 2008 11:43:02 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili07) with ESMTP id m562h3X16382; Fri, 6 Jun 2008 11:43:03 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jun 2008 10:41:06 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Fri, 06 Jun 2008 10:41:03 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Fri, 06 Jun 2008 10:41:03 +0800 From: "Benjamin Lim" To: "'Alexandru Petrescu'" , "'Julien Laganier'" References: <483D5A50.1000208@it.uc3m.es> <20080603104511.GA3314@kafka.verkstad.net><200806051742.39799.julien.IETF@laposte.net> <48480E9B.3030709@gmail.com> Date: Fri, 6 Jun 2008 10:41:03 +0800 Message-ID: <005701c8c77e$c36f5800$7471510a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjHJc5d5MWSqrnuRn6E5jJ8AFrguwAVcQHQ In-Reply-To: <48480E9B.3030709@gmail.com> X-OriginalArrivalTime: 06 Jun 2008 02:41:06.0693 (UTC) FILETIME=[C51DCB50:01C8C77E] Cc: mext@ietf.org Subject: Re: [MEXT] Generic Signaling Message / Name of generic "notification" (Was: Scope of generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Allow me to cut in. Pls see below. =8==8<=8== > Huh? Doesn't MIPv6 already have signaling? > BU/BAck/BErr/BRR/RR/etc are _not_ signaling? > > Revocation can be done by sending BAck lifetime 0. Flow [Ben] Out of curiosity, this "revoke" BAck from HA/CN would contain a seq no. that MN has already received a BAck from. I.e MN sends BU with seq no. 5 with lifetime 7 mins. HA/CN respond back with BAck seq no. 5 with status 0 (BU accepted). 3 mins later, HA/CN decide to revoke MN's binding by sending "revoke" BAck with seq no. 5 and lifetime 0. To MN, will it suspect if the "revoke" Back is a replay attack? > Distribution rules can be sent by UDP (much higher level than > MIP6) payloads encoding > flow labels and traffic classes, or with http payloads > containing XML descriptions of these flows. Heartbeats are > periodic messages, which BUs are. > > Or is it that 3GPP requires this? If 3GPP requires this > framework then it may make sense to call it "3GPP MIPv6 > Generic Signaling Message (3MGSM)", no? [Ben] I am not clear if 3GPP requires such notification mechanism, but personally I prefer Julien's title "MIPv6 Generic Signaling Message (MGSM)". Sounds more neutral to me ;p As I mention before on the ML, we have yet utilized around 10% of the MH type, so I see no reason why we want to overload the current signalling to support new notifications. If we want to overload the current signalling, then we must carefully look into how these new changes would impact the current protocol (e.g. the possible replay attack I mention above). Personally, I agree with what Julien proposing to have a main MH type to state that this is a notification message and a sub type to state what kind of notification message it is. IMHO, this looks like the cleanest way to go. Regards, Benjamin Lim > > Sorry if it sounds way off the current understanding, I may > miss something. > > Alex > > > > > > --julien _______________________________________________ > MEXT mailing > > list MEXT@ietf.org https://www.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://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 01:22:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C401928C1C1; Fri, 6 Jun 2008 01:22:46 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A65A23A68F6 for ; Fri, 6 Jun 2008 01:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GduOimDB7oj for ; Fri, 6 Jun 2008 01:22:43 -0700 (PDT) Received: from moog.chdir.org (unknown [IPv6:2002:58bf:2aa0:339b:f654:e10e:317f:e6fa]) by core3.amsl.com (Postfix) with ESMTP id C45783A6892 for ; Fri, 6 Jun 2008 01:22:43 -0700 (PDT) Received: from arno by moog.chdir.org with local (Exim 4.63) (envelope-from ) id 1K4XDl-0002DH-O5; Fri, 06 Jun 2008 10:22:49 +0200 Date: Fri, 6 Jun 2008 10:22:49 +0200 To: Vijay Devarapalli Message-ID: <20080606082249.GA8478@sd-5945.dedibox.fr> References: <200806050918.05372.julien.IETF@laposte.net> <87ve0othnn.fsf@natisbad.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: Arnaud Ebalard Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [rfc3775] Application using the care-of address X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi On Thu, Jun 05, 2008 at 01:38:26PM -0400, Vijay Devarapalli wrote: > > As a side note (I do not think this fits in the scope of RFC3775bis), > > there is also a need to control the use of the CoA by the IKE daemon > > during the negotiation of SA protecting BU/BA because the HoA > > is not yet > > available (so not usable). AFAIK, This is not *explicitly* covered by > > RFC 3775 and RFC 3776 and this specific case cannot be > > handled using the > > documents you point. > > Its not clear what is "not explicitly" covered in 3775 and 3776. RFC > 3776 says > > o In addition to the rules above, if dynamic keying is used, the key > management protocol MUST use the care-of address as the source > address in the protocol exchanges with the mobile node's home > agent. Yes, 3776 requires (MUST) the key manager to use the CoA but provides no clue on how to do that (i.e. find out which address on the system is the CoA). One could say this is an implementation issue but this is a bit simplistic (IMHO) to drop the issue. Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 01:27:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE50728C1B1; Fri, 6 Jun 2008 01:27:06 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D763F28C1B1 for ; Fri, 6 Jun 2008 01:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVWYivrQtm6i for ; Fri, 6 Jun 2008 01:27:05 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id B6F243A6AF8 for ; Fri, 6 Jun 2008 01:27:04 -0700 (PDT) Received: from dummyhost23.it.uc3m.es (dummyhost15.it.uc3m.es [163.117.139.215])by smtp01.uc3m.es (Postfix) with ESMTP id 099046A1F38;Fri, 6 Jun 2008 10:27:12 +0200 (CEST) Message-ID: <4848F4DF.9030807@it.uc3m.es> Date: Fri, 06 Jun 2008 10:27:11 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Alexandru Petrescu References: <483D5A50.1000208@it.uc3m.es> <20080603104511.GA3314@kafka.verks tad.net><200806051742.39799.julien.IETF@laposte.net> <48480E9B.3030709@gmail.com> In-Reply-To: <48480E9B.3030709@gmail.com> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-21.1527 TC:1F TRN:47 TV:5.5.1026(15954.005) 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) Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Generic Signaling Message / Name of generic"notification"(Was: Scope of generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org so Alex, are you suggesting the the work in generic notification is not = needed? Alexandru Petrescu escribi=F3: > Julien Laganier wrote: > = >> On Tuesday 03 June 2008, Michael Eriksson wrote: >> = >>> - I don't particularly like the "notification" part of GNM's name, >>> as I think it will should be used for more than notifications. >>> = >> Folks, >> >> >> >> What Michael said above rang a bell :) >> >> How about calling the new framework "MIPv6 Generic Signaling Message >> (MGSM), and defines two MH types, one requiring IPsec, the other >> not. >> >> Then we would distinguish different types of messages (Revocation, >> Flow Distribution Rules, Heartbeat, etc.) based on a subtype inside >> the Generic Signaling Message. >> >> I think that should satisfy everybody: - the IPsec SPD needs only one >> set of rules for each of the MH types (bypass, and protect). - a MGSM >> consumer (e.g. Revocation, Distribution Rules) simply specify the MH >> type it chooses depending on whether or not it requires IPsec = >> protection. - a MGSM consumer allocates one or more MGSM subtypes for >> each new message necessary to implement the consumer's functionality. >> - a MGSM consumer specifies processing (sending, receiving, state = >> machines...) for these subtyped messages. >> >> What do you think? >> = > > Huh? Doesn't MIPv6 already have signaling? BU/BAck/BErr/BRR/RR/etc are = > _not_ signaling? > > Revocation can be done by sending BAck lifetime 0. Flow Distribution > rules can be sent by UDP (much higher level than MIP6) payloads encoding > flow labels and traffic classes, or with http payloads containing XML > descriptions of these flows. Heartbeats are periodic messages, which > BUs are. > > Or is it that 3GPP requires this? If 3GPP requires this framework then > it may make sense to call it "3GPP MIPv6 Generic Signaling Message = > (3MGSM)", no? > > Sorry if it sounds way off the current understanding, I may miss somethin= g. > > Alex > > > = >> --julien _______________________________________________ MEXT mailing >> list MEXT@ietf.org https://www.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://www.ietf.org/mailman/listinfo/mext > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 02:15:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE36F3A6B8F; Fri, 6 Jun 2008 02:15:48 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE1F13A6B8F for ; Fri, 6 Jun 2008 02:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGlP0i6ABiG7 for ; Fri, 6 Jun 2008 02:15:39 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id D20523A6AC3 for ; Fri, 6 Jun 2008 02:15:38 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so628926fga.41 for ; Fri, 06 Jun 2008 02:15:46 -0700 (PDT) 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=iVGVyP0lWm1W6PRBB2Mrs9utTSeislqfaJE4qv6VGlI=; b=l+yp5BUWitIja5REtGdVpysmqJn8FLhMRx/iZndJMmHkqkHOVIMRBfXkSztlrHNKXD Dnj04pTEBTTFUn1iCvURuEGqX0uM+gF8xrUubXpPG3TirfMj/ZTz0dDRPuTRR5/ufk0c XCDTWD8BsT9OS4aiYZZACAsR5tI0I/rnralsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:sender; b=A8u0USDEoSUC26X/rJnDJC7r9rwnWazi89UhmGx2RG2kfpqqEioiRia9dgbF+gr/17 BvEBN8v/aWX4xSfhmu9De9A3melVUYiyf3GjB34L3MAJ+K4wsoYd5xmMvSio7EmOGkFD 63Xr1B5DRqlXukScll64CTtzqNP9/vaz9sIbs= Received: by 10.86.87.5 with SMTP id k5mr3675266fgb.59.1212743746826; Fri, 06 Jun 2008 02:15:46 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id v23sm9178191fkd.18.2008.06.06.02.15.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 06 Jun 2008 02:15:45 -0700 (PDT) From: Julien Laganier To: Alexandru Petrescu Date: Fri, 6 Jun 2008 11:15:57 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <483D5A50.1000208@it.uc3m.es> <200806051742.39799.julien.IETF@laposte.net> <48480E9B.3030709@gmail.com> In-Reply-To: <48480E9B.3030709@gmail.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806061116.00092.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] Generic Signaling Message / Name of generic "notification" (Was: Scope of generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Thursday 05 June 2008, Alexandru Petrescu wrote: > Julien Laganier wrote: > > On Tuesday 03 June 2008, Michael Eriksson wrote: > >> - I don't particularly like the "notification" part of GNM's name, > >> as I think it will should be used for more than notifications. > > > > Folks, > > > > > > > > What Michael said above rang a bell :) > > > > How about calling the new framework "MIPv6 Generic Signaling > > Message (MGSM), and defines two MH types, one requiring IPsec, the > > other not. > > > > Then we would distinguish different types of messages (Revocation, > > Flow Distribution Rules, Heartbeat, etc.) based on a subtype inside > > the Generic Signaling Message. > > > > I think that should satisfy everybody: - the IPsec SPD needs only > > one set of rules for each of the MH types (bypass, and protect). - > > a MGSM consumer (e.g. Revocation, Distribution Rules) simply > > specify the MH type it chooses depending on whether or not it > > requires IPsec protection. - a MGSM consumer allocates one or more > > MGSM subtypes for each new message necessary to implement the > > consumer's functionality. - a MGSM consumer specifies processing > > (sending, receiving, state machines...) for these subtyped > > messages. > > > > What do you think? > > Huh? Bouh! > Doesn't MIPv6 already have signaling? BU/BAck/BErr/BRR/RR/etc > are _not_ signaling? Alex, IMO we've already spent way too much time on this topic and I'd really like us to move forward. Discussion is good, as long as it's productive. To make a discussion productive, we'd rather all pay great attention to what other people are saying, try as much as possible to understand their view, and uttermost, not misrepresent their opinions. So let's try to get this straight and avoid drifting. Did I ever said that MIPv6 has no signaling? Did I ever said BU/Back/Berr/BRR are not signaling? What I've been proposing is a GENERIC signaling message for MIPv6. Now let's go to your "proposals": > Revocation can be done by sending BAck lifetime 0. I think we all know very well that BAck stands for "Binding Acknowledgment". What you're proposing here is that the HA, on its own initiative, *acknowledge* that a binding has been revoked, without having been asked anything. It's called a semantic overloading, and it's just plainly wrong. Explicitness is one of the top qualities of a protocol design. > Flow Distribution rules can be sent by UDP (much higher level than > MIP6) payloads encoding flow labels and traffic classes, or with http > payloads containing XML descriptions of these flows. Some principles of architecture cleanliness tells us that something manipulating MIPv6 layer concepts belongs to the MIPv6 layer, and thus should be implemented at the MIPv6 layer, as much as possible. > Heartbeats are periodic messages, which BUs are. Not sure what you mean here. Are you proposing to implement heartbeats with BUs? A BU is a "Binding Update", heartbeats are not intended to update a binding, thus that would again be semantic overloading again, wrong. > Or is it that 3GPP requires this? If 3GPP requires this framework > then it may make sense to call it "3GPP MIPv6 Generic Signaling > Message (3MGSM)", no? Let's not start one of the great 3GPP debate, I have no time and no beer right now :) > Sorry if it sounds way off the current understanding, I may miss > something. I guess you do... --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 02:24:54 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB1E028C1C7; Fri, 6 Jun 2008 02:24:54 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AACB28C0D8 for ; Fri, 6 Jun 2008 02:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2l-VcUvUU9G for ; Fri, 6 Jun 2008 02:24:47 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 39BF928C1F2 for ; Fri, 6 Jun 2008 02:24:47 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so631048fga.41 for ; Fri, 06 Jun 2008 02:24:55 -0700 (PDT) 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=LdzJ/emiy33ZhNHwJBtc4AtQGYaqQenPyVbjAhScLU8=; b=RMk4YyTNNrKiuZV/tInmoKod2pdtwwl3EYQZ0lefcAkY8IP/+kZp5tZMl8KODaab9t kab08latWZ2QCLFiKnrVtiQyIJMWmceUx6kDXnpG4XF3/CGkVa2fJy1REtVYClDu5qnx 1KNTPSUEw5Aep5UhiWVXDEu8ALhusciQE4qBI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:sender; b=KN8RLIU+1UgiVo7z9DuwpzCYlM4z1zQLOooQV5nE2ulw7kfq+13hTL4v/mHNB6jdD9 0ouTenuIwTcrhw6Vg6A/3R6PLZyNfbfdkd+TscC0KrGUM+vxsgrRTjLQMbL/kIcCdv9Q XSE56yNqsmh8z7SchZlCSiHwbJPHMUVaCSq6Q= Received: by 10.86.78.4 with SMTP id a4mr3755005fgb.14.1212744295360; Fri, 06 Jun 2008 02:24:55 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id c28sm9210862fka.4.2008.06.06.02.24.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 06 Jun 2008 02:24:54 -0700 (PDT) From: Julien Laganier To: "Charles E. Perkins" Date: Fri, 6 Jun 2008 11:25:10 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <483D5A50.1000208@it.uc3m.es> <200806051742.39799.julien.IETF@laposte.net> <48481187.3010206@earthlink.net> In-Reply-To: <48481187.3010206@earthlink.net> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806061125.11638.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] Generic Signaling Message / Name of generic "notification" (Was: Scope of generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Thursday 05 June 2008, Charles E. Perkins wrote: > Hello Julien, Hello Charlie, > Could you provide some examples of messages that > would NOT fit as subtypes of the proposed generic > signaling message? Not sure how an answer to that question is actually useful, but anyway: Home Test Init, Home Test, Care-of Test Init, Care-of Test, Binding Update, Binding Acknowledgement, Binding Refresh Request, and Binding Error. Cheers, --julien > Julien Laganier wrote: > > On Tuesday 03 June 2008, Michael Eriksson wrote: > >> - I don't particularly like the "notification" part of GNM's name, > >> as I think it will should be used for more than notifications. > > > > Folks, > > > > > > > > What Michael said above rang a bell :) > > > > How about calling the new framework "MIPv6 Generic Signaling > > Message (MGSM), and defines two MH types, one requiring IPsec, the > > other not. > > > > Then we would distinguish different types of messages (Revocation, > > Flow Distribution Rules, Heartbeat, etc.) based on a subtype inside > > the Generic Signaling Message. > > > > I think that should satisfy everybody: > > - the IPsec SPD needs only one set of rules for each of the MH > > types (bypass, and protect). > > - a MGSM consumer (e.g. Revocation, Distribution Rules) simply > > specify the MH type it chooses depending on whether or not it > > requires IPsec protection. > > - a MGSM consumer allocates one or more MGSM subtypes for each new > > message necessary to implement the consumer's functionality. > > - a MGSM consumer specifies processing (sending, receiving, state > > machines...) for these subtyped messages. > > > > What do you think? > > > > --julien > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 02:44:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16AF43A68EC; Fri, 6 Jun 2008 02:44:07 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA123A67B7 for ; Fri, 6 Jun 2008 02:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 tagged_above=-999 required=5 tests=[AWL=-1.986, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5u2rbEUTepPC for ; Fri, 6 Jun 2008 02:44:01 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 07A0B3A6838 for ; Fri, 6 Jun 2008 02:44:00 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so635973fga.41 for ; Fri, 06 Jun 2008 02:44:07 -0700 (PDT) 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=3k/XP1qGpv/jhsaSwPFNLyD627n6SHGghFm3vbTW2bc=; b=H/NN5s9wv684ZD5WW2thVMRV1UdyAoAzPFDk2mzxrQq4Hph8OnWGHzMGyDIO91v+rU 48xma3cM+TyHcUSv3kO9cCe9n/sen1fQv3v1qov0a9QbzCy3votIy3dNkZStURBAlSbQ t/2BIL2JewG+yNG1MwMp7DK2VVDPIvDQfdiIs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:sender; b=DxXB9OKOPotI5by0c6aFXKyAGVQlYX+y4IhY9UcH+aBJFs4RPw7PSDjconzqQipJof DCdcHq33juTjOhwsvqi1nQuPysx/KlPAeQJEEKCq1LfWKeVnhnlg2+Sd87Uts9XG9hQh 18yKcHPOw1AYwCNu7OLRTQXVavG6X5pgY5NjU= Received: by 10.86.84.5 with SMTP id h5mr3741116fgb.58.1212745446864; Fri, 06 Jun 2008 02:44:06 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 31sm9233095fkt.2.2008.06.06.02.44.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 06 Jun 2008 02:44:05 -0700 (PDT) From: Julien Laganier To: Arnaud Ebalard Date: Fri, 6 Jun 2008 11:44:21 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200806050918.05372.julien.IETF@laposte.net> <20080606082249.GA8478@sd-5945.dedibox.fr> In-Reply-To: <20080606082249.GA8478@sd-5945.dedibox.fr> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806061144.23200.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] [rfc3775] Application using the care-of address X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Friday 06 June 2008, Arnaud Ebalard wrote: > Hi > > On Thu, Jun 05, 2008 at 01:38:26PM -0400, Vijay Devarapalli wrote: > > > As a side note (I do not think this fits in the scope of > > > RFC3775bis), there is also a need to control the use of the CoA > > > by the IKE daemon during the negotiation of SA protecting BU/BA > > > because the HoA is not yet > > > available (so not usable). AFAIK, This is not *explicitly* > > > covered by RFC 3775 and RFC 3776 and this specific case cannot be > > > handled using the > > > documents you point. > > > > Its not clear what is "not explicitly" covered in 3775 and 3776. > > RFC 3776 says > > > > o In addition to the rules above, if dynamic keying is used, > > the key management protocol MUST use the care-of address as the > > source address in the protocol exchanges with the mobile node's > > home agent. > > Yes, 3776 requires (MUST) the key manager to use the CoA but provides > no clue on how to do that (i.e. find out which address on the system > is the CoA). One could say this is an implementation issue but this > is a bit simplistic (IMHO) to drop the issue. RFC5014 allows a sending process to express to the IP stack its preference for a CoA to be selected as source address in outbound packets, and then allows the process to verify that the selected source address is indeed a CoA: uint32_t preferences = IPV6_PREFER_SRC_COA; s = socket(AF_INET6,...); setsockopt(s, IPV6_ADDR_PREFERENCES, (void *) &preferences, sizeof (preferences)); connect(s, dst_addr, sizeof(dst_addr)); getsockname(s, src_addr, sizeof(src_addr)); if (inet6_is_srcaddr(src_addr, IPV6_PREFER_SRC_COA) != 1) return -1; --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 03:07:38 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937A43A6BD4; Fri, 6 Jun 2008 03:07:38 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF0553A698E for ; Fri, 6 Jun 2008 03:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.006 X-Spam-Level: X-Spam-Status: No, score=-0.006 tagged_above=-999 required=5 tests=[AWL=-2.594, BAYES_00=-2.599, FRT_STOCK2=3.988, J_CHICKENPOX_101=0.6, J_CHICKENPOX_71=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrYiFV9FJJdM for ; Fri, 6 Jun 2008 03:07:37 -0700 (PDT) Received: from moog.chdir.org (unknown [IPv6:2002:58bf:2aa0:339b:f654:e10e:317f:e6fa]) by core3.amsl.com (Postfix) with ESMTP id C5D233A692A for ; Fri, 6 Jun 2008 03:07:36 -0700 (PDT) Received: from arno by moog.chdir.org with local (Exim 4.63) (envelope-from ) id 1K4YrH-0003dP-KO; Fri, 06 Jun 2008 12:07:43 +0200 Date: Fri, 6 Jun 2008 12:07:43 +0200 To: Julien Laganier Message-ID: <20080606100743.GA12803@sd-5945.dedibox.fr> References: <200806050918.05372.julien.IETF@laposte.net> <20080606082249.GA8478@sd-5945.dedibox.fr> <200806061144.23200.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200806061144.23200.julien.IETF@laposte.net> User-Agent: Mutt/1.5.13 (2006-08-11) From: Arnaud Ebalard Cc: mext@ietf.org Subject: Re: [MEXT] [rfc3775] Application using the care-of address X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, On Fri, Jun 06, 2008 at 11:44:21AM +0200, Julien Laganier wrote: > On Friday 06 June 2008, Arnaud Ebalard wrote: > > Hi > > > > On Thu, Jun 05, 2008 at 01:38:26PM -0400, Vijay Devarapalli wrote: > > > > As a side note (I do not think this fits in the scope of > > > > RFC3775bis), there is also a need to control the use of the CoA > > > > by the IKE daemon during the negotiation of SA protecting BU/BA > > > > because the HoA is not yet > > > > available (so not usable). AFAIK, This is not *explicitly* > > > > covered by RFC 3775 and RFC 3776 and this specific case cannot be > > > > handled using the > > > > documents you point. > > > > > > Its not clear what is "not explicitly" covered in 3775 and 3776. > > > RFC 3776 says > > > > > > o In addition to the rules above, if dynamic keying is used, > > > the key management protocol MUST use the care-of address as the > > > source address in the protocol exchanges with the mobile node's > > > home agent. > > > > Yes, 3776 requires (MUST) the key manager to use the CoA but provides > > no clue on how to do that (i.e. find out which address on the system > > is the CoA). One could say this is an implementation issue but this > > is a bit simplistic (IMHO) to drop the issue. > > RFC5014 allows a sending process to express to the IP stack its > preference for a CoA to be selected as source address in outbound > packets, and then allows the process to verify that the selected source > address is indeed a CoA: > > ... snip ... I think you miss the point. Please, Julien, consider the following question and try to explain how things should happen (sequence of events) with what is on the table at the moment (3775, 3776, 5014, ...): How (from who, using which interface, ...) does the IKE daemon *gets* the address? The code you provide below might have an interest for the source (MIPv6 process), but the IKE daemon is more an indirect helper that gets triggered by the IPsec stack. > uint32_t preferences = IPV6_PREFER_SRC_COA; > > s = socket(AF_INET6,...); > > setsockopt(s, IPV6_ADDR_PREFERENCES, (void *) &preferences, > sizeof (preferences)); > > connect(s, dst_addr, sizeof(dst_addr)); > > getsockname(s, src_addr, sizeof(src_addr)); > > if (inet6_is_srcaddr(src_addr, IPV6_PREFER_SRC_COA) != 1) > return -1; > > --julien Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 03:16:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D80403A6CEB; Fri, 6 Jun 2008 03:16:05 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4326A3A6CD9 for ; Fri, 6 Jun 2008 03:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEdwlSSEdACb for ; Fri, 6 Jun 2008 03:16:03 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id D9B3928C200 for ; Fri, 6 Jun 2008 03:14:05 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-128.messagelabs.com!1212747254!7640320!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 10641 invoked from network); 6 Jun 2008 10:14:14 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-8.tower-128.messagelabs.com with SMTP; 6 Jun 2008 10:14:14 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id m56AEEVt015197 for ; Fri, 6 Jun 2008 03:14:14 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id m56AEDHr026442 for ; Fri, 6 Jun 2008 05:14:13 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id m56AEBUd026429 for ; Fri, 6 Jun 2008 05:14:12 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Jun 2008 11:09:06 +0100 Message-ID: <48490CC5.3040503@gmail.com> Date: Fri, 06 Jun 2008 12:09:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: marcelo bagnulo braun References: <483D5A50.1000208@it.uc3m.es> <20080603104511.GA3314@kafka.verks tad.net><200806051742.39799.julien.IETF@laposte.net> <48480E9B.3030709@gmail.com> <4848F4DF.9030807@it.uc3m.es> In-Reply-To: <4848F4DF.9030807@it.uc3m.es> X-Antivirus: avast! (VPS 080605-1, 05/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 06 Jun 2008 10:09:07.0230 (UTC) FILETIME=[5B2A3BE0:01C8C7BD] X-CFilter-Loop: Reflected Cc: mext Subject: Re: [MEXT] Generic Signaling Message / Name of generic"notification"(Was: Scope of generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org marcelo bagnulo braun wrote: > > so Alex, are you suggesting the the work in generic notification is > not needed? Since you ask, I suppose you have 1000 reasons up the sleeve to counter my arguments. But yes, I believe the generic notification can simply be achieved with simple extensions of MIP6 existing messages. 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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 03:16:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9373A6A6F; Fri, 6 Jun 2008 03:16:50 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94A603A6A46 for ; Fri, 6 Jun 2008 03:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKVqmtnzKUYB for ; Fri, 6 Jun 2008 03:16:48 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 129373A68EA for ; Fri, 6 Jun 2008 03:15:10 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-153.messagelabs.com!1212747313!9271565!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 20346 invoked from network); 6 Jun 2008 10:15:14 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-9.tower-153.messagelabs.com with SMTP; 6 Jun 2008 10:15:14 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m56AFDC1003034 for ; Fri, 6 Jun 2008 03:15:13 -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 m56AFC9X025426 for ; Fri, 6 Jun 2008 05:15:12 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id m56AFB9M025416 for ; Fri, 6 Jun 2008 05:15:11 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Jun 2008 11:09:38 +0100 Message-ID: <48490CE5.60503@gmail.com> Date: Fri, 06 Jun 2008 12:09:41 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ahmad Muhanna References: <483D5A50.1000208@it.uc3m.es> <20080603104511.GA3314@kafka.verkstad.net> <200806051742.39799.julien.IETF@laposte.net> <48480E9B.3030709@gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 080605-1, 05/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 06 Jun 2008 10:09:38.0853 (UTC) FILETIME=[6E038550:01C8C7BD] X-CFilter-Loop: Reflected Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Generic Signaling Message / Name of generic "notification" (Was: Scope of generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ahmad Muhanna wrote: >>> I think that should satisfy everybody: - the IPsec SPD >> needs only one >>> set of rules for each of the MH types (bypass, and >> protect). - a MGSM >>> consumer (e.g. Revocation, Distribution Rules) simply >> specify the MH >>> type it chooses depending on whether or not it requires IPsec >>> protection. - a MGSM consumer allocates one or more MGSM >> subtypes for >>> each new message necessary to implement the consumer's >> functionality. >>> - a MGSM consumer specifies processing (sending, receiving, state >>> machines...) for these subtyped messages. >>> >>> What do you think? >> Huh? Doesn't MIPv6 already have signaling? >> BU/BAck/BErr/BRR/RR/etc are _not_ signaling? >> >> Revocation can be done by sending BAck lifetime 0. > > [Ahmad] > Hi Alex, > Did you mean a BU with lifetime = 0 ? Sorry, I meant BAck with lifetime 0, not BU with lifetime 0. HA would thus tell MN it no longer keeps the BC entry for it. 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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 03:17:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42C123A6838; Fri, 6 Jun 2008 03:17:16 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5A323A6838 for ; Fri, 6 Jun 2008 03:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id af5JNnbE1b+9 for ; Fri, 6 Jun 2008 03:17:13 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.245.51]) by core3.amsl.com (Postfix) with SMTP id 7AC183A6834 for ; Fri, 6 Jun 2008 03:17:13 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1212747441!28576811!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 5647 invoked from network); 6 Jun 2008 10:17:21 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-14.tower-119.messagelabs.com with SMTP; 6 Jun 2008 10:17:21 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id m56AHKcC015814 for ; Fri, 6 Jun 2008 03:17:20 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id m56AHJOW028049 for ; Fri, 6 Jun 2008 05:17:20 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id m56AHIjG028028 for ; Fri, 6 Jun 2008 05:17:18 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Jun 2008 11:09:24 +0100 Message-ID: <48490CD6.4070801@gmail.com> Date: Fri, 06 Jun 2008 12:09:26 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Benjamin Lim References: <483D5A50.1000208@it.uc3m.es> <20080603104511.GA3314@kafka.verkstad.net><200806051742.39799.julien.IETF@laposte.net> <48480E9B.3030709@gmail.com> <005701c8c77e$c36f5800$7471510a@psl.local> In-Reply-To: <005701c8c77e$c36f5800$7471510a@psl.local> X-Antivirus: avast! (VPS 080605-1, 05/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 06 Jun 2008 10:09:24.0472 (UTC) FILETIME=[65712780:01C8C7BD] X-CFilter-Loop: Reflected Cc: mext@ietf.org, 'Julien Laganier' Subject: Re: [MEXT] Generic Signaling Message / Name of generic "notification" (Was: Scope of generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Benjamin Lim wrote: > Hi, > > Allow me to cut in. Pls see below. > > =8==8<=8== >> Huh? Doesn't MIPv6 already have signaling? BU/BAck/BErr/BRR/RR/etc >> are _not_ signaling? >> >> Revocation can be done by sending BAck lifetime 0. Flow > [Ben] Out of curiosity, this "revoke" BAck from HA/CN would contain a > seq no. that MN has already received a BAck from. I.e MN sends BU > with seq no. 5 with lifetime 7 mins. HA/CN respond back with BAck seq > no. 5 with status 0 (BU accepted). 3 mins later, HA/CN decide to > revoke MN's binding by sending "revoke" BAck with seq no. 5 and > lifetime 0. Right, sounds reasonable to me to not send BAck with a seqno already used. Maybe reserver seqno 0 for this purpose? Or maybe HA waits for next BU before sending a revoking BAck? Or maybe use a special BRR? > To MN, will it suspect if the "revoke" Back is a replay attack? That's indeed an issue. Maybe reserve 0 seqno value as special, or other flag in BAck or something. >> Distribution rules can be sent by UDP (much higher level than MIP6) >> payloads encoding flow labels and traffic classes, or with http >> payloads containing XML descriptions of these flows. Heartbeats >> are periodic messages, which BUs are. >> >> Or is it that 3GPP requires this? If 3GPP requires this framework >> then it may make sense to call it "3GPP MIPv6 Generic Signaling >> Message (3MGSM)", no? > [Ben] I am not clear if 3GPP requires such notification mechanism, > but personally I prefer Julien's title "MIPv6 Generic Signaling > Message (MGSM)". Sounds more neutral to me ;p > > As I mention before on the ML, we have yet utilized around 10% of the > MH type, so I see no reason why we want to overload the current > signalling to support new notifications. If one takes a longer term perspective one wouldn't be worried of having used only 10% of MH type space in a couple of years. For example, the version field of IP header has used even less percentage in more years; and similar with ICMP types. > If we want to overload the current signalling, then we must carefully > look into how these new changes would impact the current protocol > (e.g. the possible replay attack I mention above). > > Personally, I agree with what Julien proposing to have a main MH type > to state that this is a notification message and a sub type to state > what kind of notification message it is. IMHO, this looks like the > cleanest way to go. Alex > > Regards, Benjamin Lim > >> Sorry if it sounds way off the current understanding, I may miss >> something. >> >> Alex >> >> >>> --julien _______________________________________________ >> MEXT mailing >>> list MEXT@ietf.org https://www.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://www.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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 03:33:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 640AC3A6A6F; Fri, 6 Jun 2008 03:33:44 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D0B83A6A6F for ; Fri, 6 Jun 2008 03:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD+1Kz6gfKWm for ; Fri, 6 Jun 2008 03:33:42 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 5163F3A6897 for ; Fri, 6 Jun 2008 03:33:42 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-128.messagelabs.com!1212748430!3459445!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 10041 invoked from network); 6 Jun 2008 10:33:51 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-128.messagelabs.com with SMTP; 6 Jun 2008 10:33:51 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m56AXonD004194 for ; Fri, 6 Jun 2008 03:33:50 -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 m56AXoEj000083 for ; Fri, 6 Jun 2008 05:33:50 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id m56AXnWK000076 for ; Fri, 6 Jun 2008 05:33:49 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Jun 2008 11:33:48 +0100 Message-ID: <4849128B.3050700@gmail.com> Date: Fri, 06 Jun 2008 12:33:47 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Julien Laganier References: <483D5A50.1000208@it.uc3m.es> <200806051742.39799.julien.IETF@laposte.net> <48480E9B.3030709@gmail.com> <200806061116.00092.julien.IETF@laposte.net> In-Reply-To: <200806061116.00092.julien.IETF@laposte.net> X-Antivirus: avast! (VPS 080605-1, 05/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 06 Jun 2008 10:33:48.0580 (UTC) FILETIME=[CE1E4E40:01C8C7C0] X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] Generic Signaling Message / Name of generic "notification" (Was: Scope of generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien Laganier wrote: > On Thursday 05 June 2008, Alexandru Petrescu wrote: >> Julien Laganier wrote: >>> On Tuesday 03 June 2008, Michael Eriksson wrote: >>>> - I don't particularly like the "notification" part of GNM's >>>> name, as I think it will should be used for more than >>>> notifications. >>> Folks, >>> >>> >>> >>> What Michael said above rang a bell :) >>> >>> How about calling the new framework "MIPv6 Generic Signaling >>> Message (MGSM), and defines two MH types, one requiring IPsec, >>> the other not. >>> >>> Then we would distinguish different types of messages >>> (Revocation, Flow Distribution Rules, Heartbeat, etc.) based on a >>> subtype inside the Generic Signaling Message. >>> >>> I think that should satisfy everybody: - the IPsec SPD needs only >>> one set of rules for each of the MH types (bypass, and protect). >>> - a MGSM consumer (e.g. Revocation, Distribution Rules) simply >>> specify the MH type it chooses depending on whether or not it >>> requires IPsec protection. - a MGSM consumer allocates one or >>> more MGSM subtypes for each new message necessary to implement >>> the consumer's functionality. - a MGSM consumer specifies >>> processing (sending, receiving, state machines...) for these >>> subtyped messages. >>> >>> What do you think? >> Huh? > > Bouh! > >> Doesn't MIPv6 already have signaling? BU/BAck/BErr/BRR/RR/etc are >> _not_ signaling? > > > > Alex, IMO we've already spent way too much time on this topic and I'd > really like us to move forward. Discussion is good, as long as it's > productive. > > To make a discussion productive, we'd rather all pay great attention > to what other people are saying, try as much as possible to > understand their view, and uttermost, not misrepresent their > opinions. > > So let's try to get this straight and avoid drifting. > > > > Did I ever said that MIPv6 has no signaling? If it does have signaling, why is there a need for a Generic signaling? > Did I ever said BU/Back/Berr/BRR are not signaling? If you didn't say it, I deduce BU/BAck/BErr/BRR are not signaling. IF these are _not_ signaling then what are they? > What I've been proposing is a GENERIC signaling message for MIPv6. > > Now let's go to your "proposals": > >> Revocation can be done by sending BAck lifetime 0. > > I think we all know very well that BAck stands for "Binding > Acknowledgment". What you're proposing here is that the HA, on its > own initiative, *acknowledge* that a binding has been revoked, > without having been asked anything. > > It's called a semantic overloading, and it's just plainly wrong. > Explicitness is one of the top qualities of a protocol design. It would become an explicit revocation by setting a flag in it 'R' - Revoking Binding Ack. >> Flow Distribution rules can be sent by UDP (much higher level than >> MIP6) payloads encoding flow labels and traffic classes, or with >> http payloads containing XML descriptions of these flows. > > Some principles of architecture cleanliness tells us that something > manipulating MIPv6 layer concepts belongs to the MIPv6 layer, and > thus should be implemented at the MIPv6 layer, as much as possible. If people doing QoS with TC/flow label implemented all the QoS features in the IP header then it would be . But we have a very strong divergence with respect to Flows, what they are and how semantically the MIP6 flows are different than the flows labelled in IPv6 base header. WE have such diverging views that I think we couldn't discuss these end results. >> Heartbeats are periodic messages, which BUs are. > > Not sure what you mean here. Are you proposing to implement > heartbeats with BUs? A BU is a "Binding Update", heartbeats are not > intended to update a binding, thus that would again be semantic > overloading again, wrong. Ok, but one would love to have only one heartbeat for MIP6, not two. GEneric Signalling would propose one, DSMIPv6 proposes another one. And on top of that BUs are periodic already. >> Or is it that 3GPP requires this? If 3GPP requires this framework >> then it may make sense to call it "3GPP MIPv6 Generic Signaling >> Message (3MGSM)", no? > > Let's not start one of the great 3GPP debate, I have no time and no > beer right now :) Ok, I simply can't see it as "MIPv6 Generic Signaling", because "MIPv6 Signaling" is BU/BAck/BErr/RR/MPD/DHAAD already. >> Sorry if it sounds way off the current understanding, I may miss >> something. > > I guess you do... Sorry, I'll shut up. 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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 03:53:57 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A90C23A696B; Fri, 6 Jun 2008 03:53:57 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AABD3A696B for ; Fri, 6 Jun 2008 03:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.609 X-Spam-Level: X-Spam-Status: No, score=-3.609 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqOLSaO8kAap for ; Fri, 6 Jun 2008 03:53:48 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id A363A3A6818 for ; Fri, 6 Jun 2008 03:53:48 -0700 (PDT) Received: from dummyhost23.it.uc3m.es (unknown [163.117.139.215])by smtp01.uc3m.es (Postfix) with ESMTP id E80B56A4E2A;Fri, 6 Jun 2008 12:53:55 +0200 (CEST) Message-ID: <48491743.5050202@it.uc3m.es> Date: Fri, 06 Jun 2008 12:53:55 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Alexandru Petrescu References: <483D5A50.1000208@it.uc3m.es> <20080603104511.GA3314@kafka.verks tad.net><200806051742.39799.julien.IETF@laposte.net> <48480E9B.3030709@gmail.com> <4848F4DF.9030807@it.uc3m.es> <48490CC5.3040503@gmail.com> In-Reply-To: <48490CC5.3040503@gmail.com> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-7.4412 TC:1F TRN:26 TV:5.5.1026(15954.006) 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) Cc: mext Subject: Re: [MEXT] Generic Signaling Message / Name of generic"notification"(Was:Scopeof generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org No, i have one very simple reason: There was a discussion about rechartering and we try to keep it as open = as possible. The conclusion from this discussion was to do this work. = So, now it is not a good time to revisit that decision. regards, marcelo Alexandru Petrescu escribi=F3: > marcelo bagnulo braun wrote: >> >> so Alex, are you suggesting the the work in generic notification is = >> not needed? > > Since you ask, I suppose you have 1000 reasons up the sleeve to counter > my arguments. But yes, I believe the generic notification can simply be > achieved with simple extensions of MIP6 existing messages. > > 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://www.ietf.org/mailman/listinfo/mext From c.perdereau@seguin-trucks.com Fri Jun 6 04:34:11 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C793A6CD7; Fri, 6 Jun 2008 04:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -85.472 X-Spam-Level: X-Spam-Status: No, score=-85.472 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_TR=0.935, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYbKdv3SwHRP; Fri, 6 Jun 2008 04:34:10 -0700 (PDT) Received: from dsl88-244-39251.ttnet.net.tr (unknown [88.224.153.83]) by core3.amsl.com (Postfix) with SMTP id C32C53A6CCA; Fri, 6 Jun 2008 04:33:57 -0700 (PDT) X-Originating-IP: 92.107.186.36 by smtp.88.224.153.83; Fri, 06 Jun 2008 07:34:06 -0500 Message-ID: From: "Ila Chase" Reply-To: "Ila Chase" To: nemo-archive@ietf.org Subject: Replica or Original? Date: Fri, 06 Jun 2008 07:34:06 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The new Porsche Design watches originated from the novel Titanium Chronograph from the 1970's, an absolutely unique creation due to the perfection of its workmanship. Based on its design, the Porsche Design Company developed an appealing, stylish, sporty and highly accurate watch. Unfortunately, these timepieces come with a high price tag. http://cururepilik28.blogspot.com/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://cururepilik28.blogspot.com/ From nfsv4-bounces@ietf.org Fri Jun 6 04:34:14 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BFC73A6CDF for ; Fri, 6 Jun 2008 04:34:14 -0700 (PDT) Subject: The results of your email commands From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0839661208==" Message-ID: Date: Fri, 06 Jun 2008 04:34:12 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org --===============0839661208== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://cururepilik28.blogspot.com/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://cururepilik28.blogspot.com/ - Done. --===============0839661208== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nfsv4-request@core3.amsl.com Delivered-To: nfsv4-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C793A6CD7; Fri, 6 Jun 2008 04:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -85.472 X-Spam-Level: X-Spam-Status: No, score=-85.472 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_TR=0.935, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYbKdv3SwHRP; Fri, 6 Jun 2008 04:34:10 -0700 (PDT) Received: from dsl88-244-39251.ttnet.net.tr (unknown [88.224.153.83]) by core3.amsl.com (Postfix) with SMTP id C32C53A6CCA; Fri, 6 Jun 2008 04:33:57 -0700 (PDT) X-Originating-IP: 92.107.186.36 by smtp.88.224.153.83; Fri, 06 Jun 2008 07:34:06 -0500 Message-ID: From: "Ila Chase" Reply-To: "Ila Chase" To: nemo-archive@ietf.org Subject: Replica or Original? Date: Fri, 06 Jun 2008 07:34:06 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The new Porsche Design watches originated from the novel Titanium Chronograph from the 1970's, an absolutely unique creation due to the perfection of its workmanship. Based on its design, the Porsche Design Company developed an appealing, stylish, sporty and highly accurate watch. Unfortunately, these timepieces come with a high price tag. http://cururepilik28.blogspot.com/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://cururepilik28.blogspot.com/ --===============0839661208==-- From nemo-bounces@ietf.org Fri Jun 6 04:34:14 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F4503A6CEB for ; Fri, 6 Jun 2008 04:34:14 -0700 (PDT) Subject: The results of your email commands From: nemo-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1894071433==" Message-ID: Date: Fri, 06 Jun 2008 04:34:12 -0700 Precedence: bulk X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NEMO Working Group X-List-Administrivia: yes Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --===============1894071433== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://cururepilik28.blogspot.com/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://cururepilik28.blogspot.com/ - Done. --===============1894071433== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nemo-request@core3.amsl.com Delivered-To: nemo-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C793A6CD7; Fri, 6 Jun 2008 04:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -85.472 X-Spam-Level: X-Spam-Status: No, score=-85.472 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_TR=0.935, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYbKdv3SwHRP; Fri, 6 Jun 2008 04:34:10 -0700 (PDT) Received: from dsl88-244-39251.ttnet.net.tr (unknown [88.224.153.83]) by core3.amsl.com (Postfix) with SMTP id C32C53A6CCA; Fri, 6 Jun 2008 04:33:57 -0700 (PDT) X-Originating-IP: 92.107.186.36 by smtp.88.224.153.83; Fri, 06 Jun 2008 07:34:06 -0500 Message-ID: From: "Ila Chase" Reply-To: "Ila Chase" To: nemo-archive@ietf.org Subject: Replica or Original? Date: Fri, 06 Jun 2008 07:34:06 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The new Porsche Design watches originated from the novel Titanium Chronograph from the 1970's, an absolutely unique creation due to the perfection of its workmanship. Based on its design, the Porsche Design Company developed an appealing, stylish, sporty and highly accurate watch. Unfortunately, these timepieces come with a high price tag. http://cururepilik28.blogspot.com/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://cururepilik28.blogspot.com/ --===============1894071433==-- From nsis-bounces@ietf.org Fri Jun 6 04:34:14 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 283263A6CEB for ; Fri, 6 Jun 2008 04:34:14 -0700 (PDT) Subject: The results of your email commands From: nsis-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1930619690==" Message-ID: Date: Fri, 06 Jun 2008 04:34:12 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============1930619690== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://cururepilik28.blogspot.com/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://cururepilik28.blogspot.com/ - Done. --===============1930619690== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nsis-request@core3.amsl.com Delivered-To: nsis-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C793A6CD7; Fri, 6 Jun 2008 04:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -85.472 X-Spam-Level: X-Spam-Status: No, score=-85.472 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_TR=0.935, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYbKdv3SwHRP; Fri, 6 Jun 2008 04:34:10 -0700 (PDT) Received: from dsl88-244-39251.ttnet.net.tr (unknown [88.224.153.83]) by core3.amsl.com (Postfix) with SMTP id C32C53A6CCA; Fri, 6 Jun 2008 04:33:57 -0700 (PDT) X-Originating-IP: 92.107.186.36 by smtp.88.224.153.83; Fri, 06 Jun 2008 07:34:06 -0500 Message-ID: From: "Ila Chase" Reply-To: "Ila Chase" To: nemo-archive@ietf.org Subject: Replica or Original? Date: Fri, 06 Jun 2008 07:34:06 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The new Porsche Design watches originated from the novel Titanium Chronograph from the 1970's, an absolutely unique creation due to the perfection of its workmanship. Based on its design, the Porsche Design Company developed an appealing, stylish, sporty and highly accurate watch. Unfortunately, these timepieces come with a high price tag. http://cururepilik28.blogspot.com/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://cururepilik28.blogspot.com/ --===============1930619690==-- From netconf-bounces@ietf.org Fri Jun 6 04:34:14 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C2293A6CF7 for ; Fri, 6 Jun 2008 04:34:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to Netconf awaits moderator approval From: netconf-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 04:34:13 -0700 Precedence: bulk X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 List-Id: Network Configuration WG mailing list X-List-Administrivia: yes Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Your mail to 'Netconf' with the subject Replica or Original? Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netconf/d939c18b6f3a927805c9cfecc71a3003f9207f7c From nsis-imp-bounces@ietf.org Fri Jun 6 04:34:15 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36B243A6CD9 for ; Fri, 6 Jun 2008 04:34:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NSIS-imp awaits moderator approval From: nsis-imp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 04:34:13 -0700 Precedence: bulk X-BeenThere: nsis-imp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for implementation questions for NSIS protocols X-List-Administrivia: yes Sender: nsis-imp-bounces@ietf.org Errors-To: nsis-imp-bounces@ietf.org Your mail to 'NSIS-imp' with the subject Replica or Original? Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis-imp/33a91422e924cb772dec99bc2f5c69343195d3ae From ngo-bounces@ietf.org Fri Jun 6 04:34:15 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F44C3A6CD9 for ; Fri, 6 Jun 2008 04:34:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NGO awaits moderator approval From: ngo-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 04:34:14 -0700 Precedence: bulk X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF X-List-Administrivia: yes Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Your mail to 'NGO' with the subject Replica or Original? Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ngo/cbfadd6968b170b4a365a1fc84b57e67429c44e4 From nfsv4-bounces@ietf.org Fri Jun 6 04:34:15 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 481FF3A6CD9 for ; Fri, 6 Jun 2008 04:34:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nfsv4 awaits moderator approval From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 04:34:14 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org Your mail to 'nfsv4' with the subject Replica or Original? Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nfsv4/dd973953e899fdde12837e97701132413cd6d3e6 From nsis-bounces@ietf.org Fri Jun 6 04:34:15 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56BD03A6CDF for ; Fri, 6 Jun 2008 04:34:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nsis awaits moderator approval From: nsis-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 04:34:14 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Your mail to 'nsis' with the subject Replica or Original? Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis/2bf89d536b0621d37e0f1e7bc3532ef572210eb9 From netlmm-bounces@ietf.org Fri Jun 6 04:34:15 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CB873A6CDF for ; Fri, 6 Jun 2008 04:34:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to netlmm awaits moderator approval From: netlmm-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 04:34:14 -0700 Precedence: bulk X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETLMM working group discussion list X-List-Administrivia: yes Sender: netlmm-bounces@ietf.org Errors-To: netlmm-bounces@ietf.org Your mail to 'netlmm' with the subject Replica or Original? Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netlmm/314f3181024ad036bb6a09e4ddcc4568d68f37e4 From ntdp-bounces@ietf.org Fri Jun 6 04:34:15 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1313A6CFA for ; Fri, 6 Jun 2008 04:34:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NTDP awaits moderator approval From: ntdp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 04:34:14 -0700 Precedence: bulk X-BeenThere: ntdp@ietf.org X-Mailman-Version: 2.1.9 List-Id: define standards for the purpose of scripting of network testing equipment X-List-Administrivia: yes Sender: ntdp-bounces@ietf.org Errors-To: ntdp-bounces@ietf.org Your mail to 'NTDP' with the subject Replica or Original? Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ntdp/476a93fa6942ea81edfe7d9af865aae467cc061a From mext-bounces@ietf.org Fri Jun 6 04:49:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A0483A6CD1; Fri, 6 Jun 2008 04:49:15 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9B5E3A6CD1 for ; Fri, 6 Jun 2008 04:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[AWL=-2.492, BAYES_00=-2.599, FRT_STOCK2=3.988, J_CHICKENPOX_101=0.6, J_CHICKENPOX_71=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RITyVJvKaBvg for ; Fri, 6 Jun 2008 04:49:12 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 3F8363A695E for ; Fri, 6 Jun 2008 04:49:10 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so665472fga.41 for ; Fri, 06 Jun 2008 04:49:19 -0700 (PDT) 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=LAmvNBv6NUjXI8Sa14zxWctC1C3wuoR+09mGer1RAxQ=; b=iDt+BQHURoHuLC9lfGgqUif5lf8GKVVHyNaStqXx+9nCjTC5pSGS3zo0qpc4F2ig1v 4WP9YSSplq1b+DFvQe16upiX1+MijEWrQlEd4+2WpYufQsrcJOcR1LNp3VY7vrGiiAuP +j+OAiIaZZGVOm0BQHRqvgCq1W9iw1927q0kc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:sender; b=eSaUt2xH2d4EudvYHslWoxtB9Dt9w6EV6R+/JvTSdfl7l4dgJEF45ZGfAoCjCLXG5B RaU9FU8nVHBatpEP6LrHWWVI1aCKmqZ9MjP66NzM1DD+Rp36E1m0JsRzYak9zyDeQghM RRcZaxCuyWRwy/KJYcFeR6epGtbQFzK9PTPAo= Received: by 10.86.54.3 with SMTP id c3mr83476fga.55.1212752959295; Fri, 06 Jun 2008 04:49:19 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id e32sm9594930fke.15.2008.06.06.04.49.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 06 Jun 2008 04:49:16 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Fri, 6 Jun 2008 13:49:30 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200806050918.05372.julien.IETF@laposte.net> <200806061144.23200.julien.IETF@laposte.net> <20080606100743.GA12803@sd-5945.dedibox.fr> In-Reply-To: <20080606100743.GA12803@sd-5945.dedibox.fr> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806061349.32192.julien.IETF@laposte.net> Subject: Re: [MEXT] [rfc3775] Application using the care-of address X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Arnaud, On Friday 06 June 2008, Arnaud Ebalard wrote: > On Fri, Jun 06, 2008 at 11:44:21AM +0200, Julien Laganier wrote: > > On Friday 06 June 2008, Arnaud Ebalard wrote: > > > Hi > > > > > > On Thu, Jun 05, 2008 at 01:38:26PM -0400, Vijay Devarapalli wrote: > > > > > As a side note (I do not think this fits in the scope of > > > > > RFC3775bis), there is also a need to control the use of the > > > > > CoA by the IKE daemon during the negotiation of SA protecting > > > > > BU/BA because the HoA is not yet > > > > > available (so not usable). AFAIK, This is not *explicitly* > > > > > covered by RFC 3775 and RFC 3776 and this specific case > > > > > cannot be handled using the > > > > > documents you point. > > > > > > > > Its not clear what is "not explicitly" covered in 3775 and > > > > 3776. RFC 3776 says > > > > > > > > o In addition to the rules above, if dynamic keying is > > > > used, the key management protocol MUST use the care-of address > > > > as the source address in the protocol exchanges with the mobile > > > > node's home agent. > > > > > > Yes, 3776 requires (MUST) the key manager to use the CoA but > > > provides no clue on how to do that (i.e. find out which address > > > on the system is the CoA). One could say this is an > > > implementation issue but this is a bit simplistic (IMHO) to drop > > > the issue. > > > > RFC5014 allows a sending process to express to the IP stack its > > preference for a CoA to be selected as source address in outbound > > packets, and then allows the process to verify that the selected > > source address is indeed a CoA: > > > > ... snip ... > > I think you miss the point. I guess I do... > Please, Julien, consider the following question and try to explain how > things should happen (sequence of events) with what is on the table at > the moment (3775, 3776, 5014, ...): > > How (from who, using which interface, ...) does the IKE daemon *gets* > the address? Ok, I really tried, and I'm sorry but the only answer I find is that the IKE daemon just uses the sample code below. I must really be missing something here... It would really help if you could point out why an IKE daemon using the sample code below would not get the CoA in dst_addr and in packets it sent. > The code you provide below might have an interest for the source > (MIPv6 process), but the IKE daemon is more an indirect helper that > gets triggered by the IPsec stack. > > > uint32_t preferences = IPV6_PREFER_SRC_COA; > > > > s = socket(AF_INET6,...); > > > > setsockopt(s, IPV6_ADDR_PREFERENCES, (void *) &preferences, > > sizeof (preferences)); > > > > connect(s, dst_addr, sizeof(dst_addr)); > > > > getsockname(s, src_addr, sizeof(src_addr)); > > > > if (inet6_is_srcaddr(src_addr, IPV6_PREFER_SRC_COA) != 1) > > return -1; Cheers, --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From c.hammer@economatrix.com Fri Jun 6 06:17:01 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D04D93A6C2A; Fri, 6 Jun 2008 06:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -74.769 X-Spam-Level: X-Spam-Status: No, score=-74.769 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, J_CHICKENPOX_24=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uekG8wVMrEhX; Fri, 6 Jun 2008 06:17:01 -0700 (PDT) Received: from 201-24-11-252.cbace702.dsl.brasiltelecom.net.br (201-24-11-252.cbace702.dsl.brasiltelecom.net.br [201.24.11.252]) by core3.amsl.com (Postfix) with SMTP id A0BAD3A6D55; Fri, 6 Jun 2008 06:16:47 -0700 (PDT) X-Originating-IP: 152.77.196.179 by smtp.201.24.11.252; Fri, 06 Jun 2008 09:16:57 -0500 Message-ID: From: "Mitchell Minor" Reply-To: "Mitchell Minor" To: multi6-archive@ietf.org Subject: Impressive Glashutte timepieces Date: Fri, 06 Jun 2008 09:16:57 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today! http://wuzalisixyd54.blogspot.com/ From mext-bounces@ietf.org Fri Jun 6 10:17:55 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E41A83A68EA; Fri, 6 Jun 2008 10:17:54 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAA283A68EA for ; Fri, 6 Jun 2008 10:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejodSDAgkdow for ; Fri, 6 Jun 2008 10:17:52 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id 75DE73A68D7 for ; Fri, 6 Jun 2008 10:17:52 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1317994rvf.49 for ; Fri, 06 Jun 2008 10:18:00 -0700 (PDT) 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=TOuRRcCqG4dtL6CqAWiN7HpT6Pcy+fEB+tHtxBHnd1g=; b=dOLxIL1Hmynp1K/zn2O3lUNYAXqGZo6x+S3n3eM0BBZHea5CsSYZuQgZBabpR4pV08 XF3nGm2O6p39ara3XAdwVL2Lda1D/n7/pf65P53bpOwsCDpNobxMLAY7ROoL8Eg+9nzi wduYzWwMs0AlGA801w2Z4c21LFSzsh7TECzgs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=g7cB4qFrJwVT5BP7ipSOGTgRpsvlalpPZjjsZRrMUH+gkuOgsNp/HTbb6neR8S89vj zCzzBCAL9kp0Kt/BhcLcIlnR9z1dId2Q6OmwwB3jZJu4oUAaGudFhX3HJFdYt6VyRWHX jBSXlUrvvIh2ZwKCyhbWNYOI3viclAxZ8bbNI= Received: by 10.140.139.3 with SMTP id m3mr213955rvd.244.1212772680337; Fri, 06 Jun 2008 10:18:00 -0700 (PDT) Received: by 10.140.164.11 with HTTP; Fri, 6 Jun 2008 10:18:00 -0700 (PDT) Message-ID: Date: Fri, 6 Jun 2008 10:18:00 -0700 From: "fan zhao" To: "Ryuji Wakikawa" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <48401470.40706@it.uc3m.es> <7892795E1A87F04CADFCCF41FADD00FC05C0F044@xmb-ams-337.emea.cisco.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ryuji and et al, Sorry for jumping in. I agree with Ryuji that the DHCP based PD procedure introduces redundancy. IMHO, the MR can request a MNP together with a HNP/HoA when establishing the IPSec SA with the HA. IMO, this is simpler. Do I miss something? Thanks. Sincerely, fan On Wed, Jun 4, 2008 at 5:37 PM, Ryuji Wakikawa wrote: > Hello Pascal, > > Sorry for late response. We have interop event in Tokyo and tested > HAHA there;-) > > On 2008/06/03, at 17:08, Pascal Thubert (pthubert) wrote: > >> Hi Ryuji: >> >> I agree that PD should not impact bootstrap. These are and should be >> kept unrelated. >> >> We must be able to extend a RFC 3963 MR with PD without forcing the >> bootstrap process in the picture. So I agree not to bring DHAAD back >> into the bootstrap... > > we agree then.. > >> But I think that PD is NOT a bootstrap process. It is post bootstrap >> and >> can reoccur many times in the life of the MR. >> >> Until we define a new process and rev 3775 and 3963, we should stay >> consistent and simple in what we are doing. > > DHCP-PD can surely impact to the bootstrap process. > > Let's say MR boots up as a MN with RFC5026 first. > Then, it tries to get a MNP for NEMO. > > If the current HA is not PD-enabled and DHAAD returns different HA, > MR must de-register the binding from the current HA and tries to start > all the registration process to the new HA. > > This seems very redundant operation.. > I want to make the PD spec simple. > > regards > ryuji > > > >> >> >> Pascal >> >>> -----Original Message----- >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>> Behalf Of >> Ryuji Wakikawa >>> Sent: mardi 3 juin 2008 09:54 >>> To: marcelo bagnulo braun >>> Cc: Julien Laganier; mext@ietf.org >>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >>> >>> Hi Marcelo, >>> >>> I agree to accept this as WG doc. >>> >>> I also agree with Romain and Vijay. >>> We don't need extension to DHAAD. >>> Since MR can act as MN, MR should be able to bootstrap with the same >>> mechanism of MIP (except for PD). >>> We should not bring DHAAD back in the bootstrap process only for PD. >>> >>> regards, >>> ryuji >>> >>> >>> On 2008/05/30, at 23:51, marcelo bagnulo braun wrote: >>> >>>> Hi, >>>> >>>> We would like to ask the WG what is their opinion about accepting >>>> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD >>>> deliverable included in our charter. >>>> >>>> Please provide comments so we cna make some progress on this long >>>> overdue deliverable >>>> >>>> thanks, Julien and marcelo >>>> -------- Mensaje original -------- >>>> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt >>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >>>> De: Internet-Drafts@ietf.org >>>> Responder a: internet-drafts@ietf.org >>>> Para: i-d-announce@ietf.org >>>> >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> Title : DHCPv6 Prefix Delegation for NEMO >>>> Author(s) : R. Droms, et al. >>>> Filename : draft-droms-mext-nemo-pd-00.txt >>>> Pages : 12 >>>> Date : 2008-05-30 >>>> >>>> One aspect of network mobility support is the assignment of a prefix >>>> or prefixes to a Mobile Router (MR) for use on the links in the >>>> Mobile Network. DHCPv6 prefix delegation can be used for this >>>> configuration task. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >>>> >>>> Content-Type: text/plain >>>> Content-ID: <2008-05-30054232.I-D@ietf.org> >>>> >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 10:51:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62D6B3A6B0A; Fri, 6 Jun 2008 10:51:44 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D71A23A69C6 for ; Fri, 6 Jun 2008 10:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtPzpt6agglC for ; Fri, 6 Jun 2008 10:51:40 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 94A863A6BAF for ; Fri, 6 Jun 2008 10:51:33 -0700 (PDT) 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 <0K21002WBYY683@usaga04-in.huawei.com> for mext@ietf.org; Fri, 06 Jun 2008 12:51:43 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K2100E71YY50X@usaga04-in.huawei.com> for mext@ietf.org; Fri, 06 Jun 2008 12:51:42 -0500 (CDT) Date: Fri, 06 Jun 2008 12:51:40 -0500 From: Frank Xia To: fan zhao , Ryuji Wakikawa Message-id: <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <48401470.40706@it.uc3m.es> <7892795E1A87F04CADFCCF41FADD00FC05C0F044@xmb-ams-337.emea.cisco.com> Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Fan, Ryuji and other colleagues. Agreed. IMHO,There are two ways for prefix delegation in Nemo, that is, overlay and integrated modes. DHCP based PD is a overlay solution which introduce redundancy while trying to reduce impact on NEMO itself. I favor the integrated mode in which Prefix Delegation is integrated into NEMO operations because prefix management is an integrated part of NEMO. PMIPv6 follow the same philosophy. BR Frank ----- Original Message ----- From: "fan zhao" To: "Ryuji Wakikawa" Cc: "Julien Laganier" ; Sent: Friday, June 06, 2008 12:18 PM Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > Hi Ryuji and et al, > > Sorry for jumping in. > I agree with Ryuji that the DHCP based PD procedure introduces redundancy. > IMHO, the MR can request a MNP together with a HNP/HoA when establishing > the IPSec SA with the HA. IMO, this is simpler. Do I miss something? > Thanks. > > Sincerely, > fan > > > On Wed, Jun 4, 2008 at 5:37 PM, Ryuji Wakikawa > wrote: >> Hello Pascal, >> >> Sorry for late response. We have interop event in Tokyo and tested >> HAHA there;-) >> >> On 2008/06/03, at 17:08, Pascal Thubert (pthubert) wrote: >> >>> Hi Ryuji: >>> >>> I agree that PD should not impact bootstrap. These are and should be >>> kept unrelated. >>> >>> We must be able to extend a RFC 3963 MR with PD without forcing the >>> bootstrap process in the picture. So I agree not to bring DHAAD back >>> into the bootstrap... >> >> we agree then.. >> >>> But I think that PD is NOT a bootstrap process. It is post bootstrap >>> and >>> can reoccur many times in the life of the MR. >>> >>> Until we define a new process and rev 3775 and 3963, we should stay >>> consistent and simple in what we are doing. >> >> DHCP-PD can surely impact to the bootstrap process. >> >> Let's say MR boots up as a MN with RFC5026 first. >> Then, it tries to get a MNP for NEMO. >> >> If the current HA is not PD-enabled and DHAAD returns different HA, >> MR must de-register the binding from the current HA and tries to start >> all the registration process to the new HA. >> >> This seems very redundant operation.. >> I want to make the PD spec simple. >> >> regards >> ryuji >> >> >> >>> >>> >>> Pascal >>> >>>> -----Original Message----- >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>> Behalf Of >>> Ryuji Wakikawa >>>> Sent: mardi 3 juin 2008 09:54 >>>> To: marcelo bagnulo braun >>>> Cc: Julien Laganier; mext@ietf.org >>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >>>> >>>> Hi Marcelo, >>>> >>>> I agree to accept this as WG doc. >>>> >>>> I also agree with Romain and Vijay. >>>> We don't need extension to DHAAD. >>>> Since MR can act as MN, MR should be able to bootstrap with the same >>>> mechanism of MIP (except for PD). >>>> We should not bring DHAAD back in the bootstrap process only for PD. >>>> >>>> regards, >>>> ryuji >>>> >>>> >>>> On 2008/05/30, at 23:51, marcelo bagnulo braun wrote: >>>> >>>>> Hi, >>>>> >>>>> We would like to ask the WG what is their opinion about accepting >>>>> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD >>>>> deliverable included in our charter. >>>>> >>>>> Please provide comments so we cna make some progress on this long >>>>> overdue deliverable >>>>> >>>>> thanks, Julien and marcelo >>>>> -------- Mensaje original -------- >>>>> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt >>>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >>>>> De: Internet-Drafts@ietf.org >>>>> Responder a: internet-drafts@ietf.org >>>>> Para: i-d-announce@ietf.org >>>>> >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> >>>>> Title : DHCPv6 Prefix Delegation for NEMO >>>>> Author(s) : R. Droms, et al. >>>>> Filename : draft-droms-mext-nemo-pd-00.txt >>>>> Pages : 12 >>>>> Date : 2008-05-30 >>>>> >>>>> One aspect of network mobility support is the assignment of a prefix >>>>> or prefixes to a Mobile Router (MR) for use on the links in the >>>>> Mobile Network. DHCPv6 prefix delegation can be used for this >>>>> configuration task. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> Below is the data which will enable a MIME compliant mail reader >>>>> implementation to automatically retrieve the ASCII version of the >>>>> Internet-Draft. >>>>> >>>>> >>>>> Content-Type: text/plain >>>>> Content-ID: <2008-05-30054232.I-D@ietf.org> >>>>> >>>>> >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From c.maclean@thomasmunro.co.uk Fri Jun 6 13:02:10 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FDEA3A68BA; Fri, 6 Jun 2008 13:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.902 X-Spam-Level: X-Spam-Status: No, score=-90.902 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IAwDmpKlJee; Fri, 6 Jun 2008 13:02:09 -0700 (PDT) Received: from Dynamic-IP-190159115166.cable.net.co (unknown [190.159.115.166]) by core3.amsl.com (Postfix) with SMTP id E70E93A6A55; Fri, 6 Jun 2008 13:02:01 -0700 (PDT) X-Originating-IP: 237.30.100.184 by smtp.190.159.115.166; Fri, 06 Jun 2008 16:02:12 -0500 Message-ID: From: "Karla Elkins" Reply-To: "Karla Elkins" To: nemo-archive@ietf.org Subject: Get 15% off these watches Date: Fri, 06 Jun 2008 16:02:12 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Since 1884 Bvlgari watches have drawn inspiration from the timeless beauty of Greek and Roman art. The time pieces that they produce are as much works of art, as a way to tell time, and now you can possess one of these splendid time pieces for a very affordable price, at Prestige Replicas. http://gecehiduzok01.blogspot.com/ This store has the finest collection of Bvlgari replica watches, and you will be astounded at the difference in price as well as amazed at the quality of their timepieces. Prestige Replicas works hard to make sure that your purchase is shipped as fast as your order is processed, and also that your private information is protected. And with the new redesign of the Prestige Replicas website, we are offering 15% off on your purchase of watches! http://gecehiduzok01.blogspot.com/ From netconf-bounces@ietf.org Fri Jun 6 13:02:11 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9289128C216 for ; Fri, 6 Jun 2008 13:02:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to Netconf awaits moderator approval From: netconf-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 13:02:11 -0700 Precedence: bulk X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 List-Id: Network Configuration WG mailing list X-List-Administrivia: yes Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Your mail to 'Netconf' with the subject Get 15% off these watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netconf/b4cad00dc37c66501c007a5e26fac4cdb05ae899 From netlmm-bounces@ietf.org Fri Jun 6 13:02:11 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C6428C216 for ; Fri, 6 Jun 2008 13:02:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to netlmm awaits moderator approval From: netlmm-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 13:02:11 -0700 Precedence: bulk X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETLMM working group discussion list X-List-Administrivia: yes Sender: netlmm-bounces@ietf.org Errors-To: netlmm-bounces@ietf.org Your mail to 'netlmm' with the subject Get 15% off these watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netlmm/ce728266bf0989837843f76dbd7ce0581def3555 From nsis-imp-bounces@ietf.org Fri Jun 6 13:02:11 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BECD28C216 for ; Fri, 6 Jun 2008 13:02:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NSIS-imp awaits moderator approval From: nsis-imp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 13:02:11 -0700 Precedence: bulk X-BeenThere: nsis-imp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for implementation questions for NSIS protocols X-List-Administrivia: yes Sender: nsis-imp-bounces@ietf.org Errors-To: nsis-imp-bounces@ietf.org Your mail to 'NSIS-imp' with the subject Get 15% off these watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis-imp/e02f09b69ae6527e702eca13749897ed72843c2c From nfsv4-bounces@ietf.org Fri Jun 6 13:02:11 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1A2128C216 for ; Fri, 6 Jun 2008 13:02:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nfsv4 awaits moderator approval From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 13:02:11 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org Your mail to 'nfsv4' with the subject Get 15% off these watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nfsv4/c5c86dca25aaccb006dc4f2df32a0460e9001c4d From nfsv4-bounces@ietf.org Fri Jun 6 13:02:12 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A90A528C207 for ; Fri, 6 Jun 2008 13:02:12 -0700 (PDT) Subject: The results of your email commands From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0882071042==" Message-ID: Date: Fri, 06 Jun 2008 13:02:11 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org --===============0882071042== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://gecehiduzok01.blogspot.com/ This store has the finest collection of Bvlgari replica watches, and you will be astounded at the difference in price as well as amazed at the quality of their timepieces. Prestige Replicas works hard to make sure that your purchase is shipped as fast as your order is processed, and also that your private information is protected. And with the new redesign of the Prestige Replicas website, we are offering 15% off on your purchase of watches! http://gecehiduzok01.blogspot.com/ - Done. --===============0882071042== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nfsv4-request@core3.amsl.com Delivered-To: nfsv4-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FDEA3A68BA; Fri, 6 Jun 2008 13:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.902 X-Spam-Level: X-Spam-Status: No, score=-90.902 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IAwDmpKlJee; Fri, 6 Jun 2008 13:02:09 -0700 (PDT) Received: from Dynamic-IP-190159115166.cable.net.co (unknown [190.159.115.166]) by core3.amsl.com (Postfix) with SMTP id E70E93A6A55; Fri, 6 Jun 2008 13:02:01 -0700 (PDT) X-Originating-IP: 237.30.100.184 by smtp.190.159.115.166; Fri, 06 Jun 2008 16:02:12 -0500 Message-ID: From: "Karla Elkins" Reply-To: "Karla Elkins" To: nemo-archive@ietf.org Subject: Get 15% off these watches Date: Fri, 06 Jun 2008 16:02:12 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Since 1884 Bvlgari watches have drawn inspiration from the timeless beauty of Greek and Roman art. The time pieces that they produce are as much works of art, as a way to tell time, and now you can possess one of these splendid time pieces for a very affordable price, at Prestige Replicas. http://gecehiduzok01.blogspot.com/ This store has the finest collection of Bvlgari replica watches, and you will be astounded at the difference in price as well as amazed at the quality of their timepieces. Prestige Replicas works hard to make sure that your purchase is shipped as fast as your order is processed, and also that your private information is protected. And with the new redesign of the Prestige Replicas website, we are offering 15% off on your purchase of watches! http://gecehiduzok01.blogspot.com/ --===============0882071042==-- From nemo-bounces@ietf.org Fri Jun 6 13:02:12 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1B13A6A55 for ; Fri, 6 Jun 2008 13:02:12 -0700 (PDT) Subject: The results of your email commands From: nemo-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0446176942==" Message-ID: Date: Fri, 06 Jun 2008 13:02:11 -0700 Precedence: bulk X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NEMO Working Group X-List-Administrivia: yes Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --===============0446176942== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://gecehiduzok01.blogspot.com/ This store has the finest collection of Bvlgari replica watches, and you will be astounded at the difference in price as well as amazed at the quality of their timepieces. Prestige Replicas works hard to make sure that your purchase is shipped as fast as your order is processed, and also that your private information is protected. And with the new redesign of the Prestige Replicas website, we are offering 15% off on your purchase of watches! http://gecehiduzok01.blogspot.com/ - Done. --===============0446176942== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nemo-request@core3.amsl.com Delivered-To: nemo-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FDEA3A68BA; Fri, 6 Jun 2008 13:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.902 X-Spam-Level: X-Spam-Status: No, score=-90.902 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IAwDmpKlJee; Fri, 6 Jun 2008 13:02:09 -0700 (PDT) Received: from Dynamic-IP-190159115166.cable.net.co (unknown [190.159.115.166]) by core3.amsl.com (Postfix) with SMTP id E70E93A6A55; Fri, 6 Jun 2008 13:02:01 -0700 (PDT) X-Originating-IP: 237.30.100.184 by smtp.190.159.115.166; Fri, 06 Jun 2008 16:02:12 -0500 Message-ID: From: "Karla Elkins" Reply-To: "Karla Elkins" To: nemo-archive@ietf.org Subject: Get 15% off these watches Date: Fri, 06 Jun 2008 16:02:12 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Since 1884 Bvlgari watches have drawn inspiration from the timeless beauty of Greek and Roman art. The time pieces that they produce are as much works of art, as a way to tell time, and now you can possess one of these splendid time pieces for a very affordable price, at Prestige Replicas. http://gecehiduzok01.blogspot.com/ This store has the finest collection of Bvlgari replica watches, and you will be astounded at the difference in price as well as amazed at the quality of their timepieces. Prestige Replicas works hard to make sure that your purchase is shipped as fast as your order is processed, and also that your private information is protected. And with the new redesign of the Prestige Replicas website, we are offering 15% off on your purchase of watches! http://gecehiduzok01.blogspot.com/ --===============0446176942==-- From nsis-bounces@ietf.org Fri Jun 6 13:02:12 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B30133A6A55 for ; Fri, 6 Jun 2008 13:02:12 -0700 (PDT) Subject: The results of your email commands From: nsis-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0634612717==" Message-ID: Date: Fri, 06 Jun 2008 13:02:11 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============0634612717== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://gecehiduzok01.blogspot.com/ This store has the finest collection of Bvlgari replica watches, and you will be astounded at the difference in price as well as amazed at the quality of their timepieces. Prestige Replicas works hard to make sure that your purchase is shipped as fast as your order is processed, and also that your private information is protected. And with the new redesign of the Prestige Replicas website, we are offering 15% off on your purchase of watches! http://gecehiduzok01.blogspot.com/ - Done. --===============0634612717== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nsis-request@core3.amsl.com Delivered-To: nsis-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FDEA3A68BA; Fri, 6 Jun 2008 13:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.902 X-Spam-Level: X-Spam-Status: No, score=-90.902 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IAwDmpKlJee; Fri, 6 Jun 2008 13:02:09 -0700 (PDT) Received: from Dynamic-IP-190159115166.cable.net.co (unknown [190.159.115.166]) by core3.amsl.com (Postfix) with SMTP id E70E93A6A55; Fri, 6 Jun 2008 13:02:01 -0700 (PDT) X-Originating-IP: 237.30.100.184 by smtp.190.159.115.166; Fri, 06 Jun 2008 16:02:12 -0500 Message-ID: From: "Karla Elkins" Reply-To: "Karla Elkins" To: nemo-archive@ietf.org Subject: Get 15% off these watches Date: Fri, 06 Jun 2008 16:02:12 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Since 1884 Bvlgari watches have drawn inspiration from the timeless beauty of Greek and Roman art. The time pieces that they produce are as much works of art, as a way to tell time, and now you can possess one of these splendid time pieces for a very affordable price, at Prestige Replicas. http://gecehiduzok01.blogspot.com/ This store has the finest collection of Bvlgari replica watches, and you will be astounded at the difference in price as well as amazed at the quality of their timepieces. Prestige Replicas works hard to make sure that your purchase is shipped as fast as your order is processed, and also that your private information is protected. And with the new redesign of the Prestige Replicas website, we are offering 15% off on your purchase of watches! http://gecehiduzok01.blogspot.com/ --===============0634612717==-- From ngo-bounces@ietf.org Fri Jun 6 13:02:12 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B598428C207 for ; Fri, 6 Jun 2008 13:02:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NGO awaits moderator approval From: ngo-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 13:02:11 -0700 Precedence: bulk X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF X-List-Administrivia: yes Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Your mail to 'NGO' with the subject Get 15% off these watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ngo/bb3cbf41e4ca8b5af4ae0e46b6340ef61845439d From nsis-bounces@ietf.org Fri Jun 6 13:02:12 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C935F28C241 for ; Fri, 6 Jun 2008 13:02:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nsis awaits moderator approval From: nsis-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 13:02:11 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Your mail to 'nsis' with the subject Get 15% off these watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis/1eedfe59b3a9f8dc30d6659473a95658eb90e134 From ntdp-bounces@ietf.org Fri Jun 6 13:02:12 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D235428C250 for ; Fri, 6 Jun 2008 13:02:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NTDP awaits moderator approval From: ntdp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 13:02:11 -0700 Precedence: bulk X-BeenThere: ntdp@ietf.org X-Mailman-Version: 2.1.9 List-Id: define standards for the purpose of scripting of network testing equipment X-List-Administrivia: yes Sender: ntdp-bounces@ietf.org Errors-To: ntdp-bounces@ietf.org Your mail to 'NTDP' with the subject Get 15% off these watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ntdp/9b05277bd8af3767afed097035848b4fb15ef3fc From mext-bounces@ietf.org Fri Jun 6 13:33:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D6CA3A6DAB; Fri, 6 Jun 2008 13:33:45 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6830F3A6DA1 for ; Fri, 6 Jun 2008 13:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCbPKTHKSRWb for ; Fri, 6 Jun 2008 13:33:43 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id 1635A3A6DA7 for ; Fri, 6 Jun 2008 13:33:42 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so507390and.122 for ; Fri, 06 Jun 2008 13:33:53 -0700 (PDT) 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=Rb2R3mkAaXY5cpH6qyvL8Mb2C0DL2Y8ikZLqf5owQ+A=; b=Yfr+QNIkZf21jjwkWA1LBQuztrk1k3EarYHaWqGwpvYrVDFeEO3eie/cnwHRiGZ01s b1bep9fdbz16Z67WXYHXHLeBaAU/wOUUiMCsZZY88/B+GLYG3rxpvJHtMAt/5W4RjLFT sZiJPQW1nOUu/pAZ/ySuaWJVD9M4Ln7D40HsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=iMZhSo0CrKJ6a7xEpog1TsZ1D6ds7e3rsyjzdOdbhpp/hFJBKQ10fyU3h/d+3VyUTZ Itg56Cjuq6L0U4LEAGGPIQRb7adPYmcu90dLJRrSf34fr64rfegmpDk2EUhgVYuAuzfw nR+PK9yIAVgBs5jmOOrp/iiKPHqYE2z8n1fdI= Received: by 10.100.212.6 with SMTP id k6mr770260ang.142.1212784432776; Fri, 06 Jun 2008 13:33:52 -0700 (PDT) Received: by 10.100.141.11 with HTTP; Fri, 6 Jun 2008 13:33:51 -0700 (PDT) Message-ID: Date: Fri, 6 Jun 2008 13:33:51 -0700 From: "fan zhao" To: "Frank Xia" In-Reply-To: <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline References: <48401470.40706@it.uc3m.es> <7892795E1A87F04CADFCCF41FADD00FC05C0F044@xmb-ams-337.emea.cisco.com> <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Frank, Please see below. On Fri, Jun 6, 2008 at 10:51 AM, Frank Xia wrote: > Hi Fan, Ryuji and other colleagues. > > Agreed. > > IMHO,There are two ways for prefix delegation in Nemo, > that is, overlay and integrated modes. > > DHCP based PD is a overlay solution which introduce redundancy > while trying to reduce impact on NEMO itself. > > I favor the integrated mode in which Prefix Delegation is integrated into > NEMO operations I agree that signaling overhead can be reduced if multiple _related_ requests/responses are piggybacked together, e.g. during one message exchange. For the MR to work, it needs both a HoA/HNP and a MNP. Besides requesting/registering the MNP, there is no much difference between the operation of the MN and that of the MR. Furthermore, the MR can request the MNP during the establishment of IPSec SA when it is at either home link or foreign link. > because prefix management is an integrated part > of NEMO. > PMIPv6 follow the same philosophy. If I understand correctly, PMIP is a slightly different case from DSMIPv6/NEMO. Because the connection, such as the IPSec SA, between the MAG and the LMA is already in place long before the MN attaches to the MAG, it makes sense for the MAG to request the HNP for the MN during the PBU/PBA exchange. With DSMIPv6, the MN requests the HoA/HNP during the establishment of the IPSec SA, therefore the MR should request the MNP during this procedure as well. What do you think? Sincerely, fan > > BR > Frank > > ----- Original Message ----- From: "fan zhao" > To: "Ryuji Wakikawa" > Cc: "Julien Laganier" ; > Sent: Friday, June 06, 2008 12:18 PM > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > >> Hi Ryuji and et al, >> >> Sorry for jumping in. >> I agree with Ryuji that the DHCP based PD procedure introduces redundancy. >> IMHO, the MR can request a MNP together with a HNP/HoA when establishing >> the IPSec SA with the HA. IMO, this is simpler. Do I miss something? >> Thanks. >> >> Sincerely, >> fan >> >> >> On Wed, Jun 4, 2008 at 5:37 PM, Ryuji Wakikawa >> wrote: >>> >>> Hello Pascal, >>> >>> Sorry for late response. We have interop event in Tokyo and tested >>> HAHA there;-) >>> >>> On 2008/06/03, at 17:08, Pascal Thubert (pthubert) wrote: >>> >>>> Hi Ryuji: >>>> >>>> I agree that PD should not impact bootstrap. These are and should be >>>> kept unrelated. >>>> >>>> We must be able to extend a RFC 3963 MR with PD without forcing the >>>> bootstrap process in the picture. So I agree not to bring DHAAD back >>>> into the bootstrap... >>> >>> we agree then.. >>> >>>> But I think that PD is NOT a bootstrap process. It is post bootstrap >>>> and >>>> can reoccur many times in the life of the MR. >>>> >>>> Until we define a new process and rev 3775 and 3963, we should stay >>>> consistent and simple in what we are doing. >>> >>> DHCP-PD can surely impact to the bootstrap process. >>> >>> Let's say MR boots up as a MN with RFC5026 first. >>> Then, it tries to get a MNP for NEMO. >>> >>> If the current HA is not PD-enabled and DHAAD returns different HA, >>> MR must de-register the binding from the current HA and tries to start >>> all the registration process to the new HA. >>> >>> This seems very redundant operation.. >>> I want to make the PD spec simple. >>> >>> regards >>> ryuji >>> >>> >>> >>>> >>>> >>>> Pascal >>>> >>>>> -----Original Message----- >>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>>> Behalf Of >>>> >>>> Ryuji Wakikawa >>>>> >>>>> Sent: mardi 3 juin 2008 09:54 >>>>> To: marcelo bagnulo braun >>>>> Cc: Julien Laganier; mext@ietf.org >>>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >>>>> >>>>> Hi Marcelo, >>>>> >>>>> I agree to accept this as WG doc. >>>>> >>>>> I also agree with Romain and Vijay. >>>>> We don't need extension to DHAAD. >>>>> Since MR can act as MN, MR should be able to bootstrap with the same >>>>> mechanism of MIP (except for PD). >>>>> We should not bring DHAAD back in the bootstrap process only for PD. >>>>> >>>>> regards, >>>>> ryuji >>>>> >>>>> >>>>> On 2008/05/30, at 23:51, marcelo bagnulo braun wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> We would like to ask the WG what is their opinion about accepting >>>>>> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD >>>>>> deliverable included in our charter. >>>>>> >>>>>> Please provide comments so we cna make some progress on this long >>>>>> overdue deliverable >>>>>> >>>>>> thanks, Julien and marcelo >>>>>> -------- Mensaje original -------- >>>>>> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt >>>>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >>>>>> De: Internet-Drafts@ietf.org >>>>>> Responder a: internet-drafts@ietf.org >>>>>> Para: i-d-announce@ietf.org >>>>>> >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> directories. >>>>>> >>>>>> Title : DHCPv6 Prefix Delegation for NEMO >>>>>> Author(s) : R. Droms, et al. >>>>>> Filename : draft-droms-mext-nemo-pd-00.txt >>>>>> Pages : 12 >>>>>> Date : 2008-05-30 >>>>>> >>>>>> One aspect of network mobility support is the assignment of a prefix >>>>>> or prefixes to a Mobile Router (MR) for use on the links in the >>>>>> Mobile Network. DHCPv6 prefix delegation can be used for this >>>>>> configuration task. >>>>>> >>>>>> A URL for this Internet-Draft is: >>>>>> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> Below is the data which will enable a MIME compliant mail reader >>>>>> implementation to automatically retrieve the ASCII version of the >>>>>> Internet-Draft. >>>>>> >>>>>> >>>>>> Content-Type: text/plain >>>>>> Content-ID: <2008-05-30054232.I-D@ietf.org> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list >>>>>> I-D-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 14:40:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ADAA3A6875; Fri, 6 Jun 2008 14:40:04 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD4A93A6875 for ; Fri, 6 Jun 2008 14:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44W0lo761ab0 for ; Fri, 6 Jun 2008 14:40:01 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 832283A680D for ; Fri, 6 Jun 2008 14:40:01 -0700 (PDT) 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 <0K2200CQN9IZX3@usaga04-in.huawei.com> for mext@ietf.org; Fri, 06 Jun 2008 16:40:11 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K2200FWA9IXXF@usaga04-in.huawei.com> for mext@ietf.org; Fri, 06 Jun 2008 16:40:11 -0500 (CDT) Date: Fri, 06 Jun 2008 16:40:09 -0500 From: Frank Xia To: fan zhao Message-id: <006001c8c81d$e5581160$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <48401470.40706@it.uc3m.es> <7892795E1A87F04CADFCCF41FADD00FC05C0F044@xmb-ams-337.emea.cisco.com> <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Fan Please see my reply... BR Frank ----- Original Message ----- From: "fan zhao" To: "Frank Xia" Cc: "Ryuji Wakikawa" ; "Julien Laganier" ; Sent: Friday, June 06, 2008 3:33 PM Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > Hi Frank, > > Please see below. > > On Fri, Jun 6, 2008 at 10:51 AM, Frank Xia wrote: >> Hi Fan, Ryuji and other colleagues. >> >> Agreed. >> >> IMHO,There are two ways for prefix delegation in Nemo, >> that is, overlay and integrated modes. >> >> DHCP based PD is a overlay solution which introduce redundancy >> while trying to reduce impact on NEMO itself. >> >> I favor the integrated mode in which Prefix Delegation is integrated into >> NEMO operations > > I agree that signaling overhead can be reduced if multiple _related_ > requests/responses > are piggybacked together, e.g. during one message exchange. For the MR > to work, it > needs both a HoA/HNP and a MNP. Besides requesting/registering the > MNP, there is > no much difference between the operation of the MN and that of the MR. > Furthermore, > the MR can request the MNP during the establishment of IPSec SA when > it is at either home link or foreign link. Frank=>For adressing in NEMO, there are two categories nodes for addressing, that is, MRs and hosts behind MRs. IKE can be used for MR's addressing, while it probabaly can't be used for host addressing (PD) without extension of IKE. > >> because prefix management is an integrated part >> of NEMO. >> PMIPv6 follow the same philosophy. > If I understand correctly, PMIP is a slightly different case from > DSMIPv6/NEMO. > Because the connection, such as the IPSec SA, between the MAG and the LMA > is already in place long before the MN attaches to the MAG, it makes sense > for > the MAG to request the HNP for the MN during the PBU/PBA exchange. With > DSMIPv6, the MN requests the HoA/HNP during the establishment of the IPSec > SA, therefore the MR should request the MNP during this procedure as well. Frank=>It is true there is difference between PMIP and NEMO. I just do an analogy. What I want to say is it makes sense if we integrate PD into NEMO. > > What do you think? > > Sincerely, > fan > >> >> BR >> Frank >> >> ----- Original Message ----- From: "fan zhao" >> To: "Ryuji Wakikawa" >> Cc: "Julien Laganier" ; >> Sent: Friday, June 06, 2008 12:18 PM >> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> >> >>> Hi Ryuji and et al, >>> >>> Sorry for jumping in. >>> I agree with Ryuji that the DHCP based PD procedure introduces >>> redundancy. >>> IMHO, the MR can request a MNP together with a HNP/HoA when establishing >>> the IPSec SA with the HA. IMO, this is simpler. Do I miss something? >>> Thanks. >>> >>> Sincerely, >>> fan >>> >>> >>> On Wed, Jun 4, 2008 at 5:37 PM, Ryuji Wakikawa >>> >>> wrote: >>>> >>>> Hello Pascal, >>>> >>>> Sorry for late response. We have interop event in Tokyo and tested >>>> HAHA there;-) >>>> >>>> On 2008/06/03, at 17:08, Pascal Thubert (pthubert) wrote: >>>> >>>>> Hi Ryuji: >>>>> >>>>> I agree that PD should not impact bootstrap. These are and should be >>>>> kept unrelated. >>>>> >>>>> We must be able to extend a RFC 3963 MR with PD without forcing the >>>>> bootstrap process in the picture. So I agree not to bring DHAAD back >>>>> into the bootstrap... >>>> >>>> we agree then.. >>>> >>>>> But I think that PD is NOT a bootstrap process. It is post bootstrap >>>>> and >>>>> can reoccur many times in the life of the MR. >>>>> >>>>> Until we define a new process and rev 3775 and 3963, we should stay >>>>> consistent and simple in what we are doing. >>>> >>>> DHCP-PD can surely impact to the bootstrap process. >>>> >>>> Let's say MR boots up as a MN with RFC5026 first. >>>> Then, it tries to get a MNP for NEMO. >>>> >>>> If the current HA is not PD-enabled and DHAAD returns different HA, >>>> MR must de-register the binding from the current HA and tries to start >>>> all the registration process to the new HA. >>>> >>>> This seems very redundant operation.. >>>> I want to make the PD spec simple. >>>> >>>> regards >>>> ryuji >>>> >>>> >>>> >>>>> >>>>> >>>>> Pascal >>>>> >>>>>> -----Original Message----- >>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>>>> Behalf Of >>>>> >>>>> Ryuji Wakikawa >>>>>> >>>>>> Sent: mardi 3 juin 2008 09:54 >>>>>> To: marcelo bagnulo braun >>>>>> Cc: Julien Laganier; mext@ietf.org >>>>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >>>>>> >>>>>> Hi Marcelo, >>>>>> >>>>>> I agree to accept this as WG doc. >>>>>> >>>>>> I also agree with Romain and Vijay. >>>>>> We don't need extension to DHAAD. >>>>>> Since MR can act as MN, MR should be able to bootstrap with the same >>>>>> mechanism of MIP (except for PD). >>>>>> We should not bring DHAAD back in the bootstrap process only for PD. >>>>>> >>>>>> regards, >>>>>> ryuji >>>>>> >>>>>> >>>>>> On 2008/05/30, at 23:51, marcelo bagnulo braun wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> We would like to ask the WG what is their opinion about accepting >>>>>>> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD >>>>>>> deliverable included in our charter. >>>>>>> >>>>>>> Please provide comments so we cna make some progress on this long >>>>>>> overdue deliverable >>>>>>> >>>>>>> thanks, Julien and marcelo >>>>>>> -------- Mensaje original -------- >>>>>>> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt >>>>>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >>>>>>> De: Internet-Drafts@ietf.org >>>>>>> Responder a: internet-drafts@ietf.org >>>>>>> Para: i-d-announce@ietf.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>>> directories. >>>>>>> >>>>>>> Title : DHCPv6 Prefix Delegation for NEMO >>>>>>> Author(s) : R. Droms, et al. >>>>>>> Filename : draft-droms-mext-nemo-pd-00.txt >>>>>>> Pages : 12 >>>>>>> Date : 2008-05-30 >>>>>>> >>>>>>> One aspect of network mobility support is the assignment of a prefix >>>>>>> or prefixes to a Mobile Router (MR) for use on the links in the >>>>>>> Mobile Network. DHCPv6 prefix delegation can be used for this >>>>>>> configuration task. >>>>>>> >>>>>>> A URL for this Internet-Draft is: >>>>>>> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> Below is the data which will enable a MIME compliant mail reader >>>>>>> implementation to automatically retrieve the ASCII version of the >>>>>>> Internet-Draft. >>>>>>> >>>>>>> >>>>>>> Content-Type: text/plain >>>>>>> Content-ID: <2008-05-30054232.I-D@ietf.org> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> I-D-Announce mailing list >>>>>>> I-D-Announce@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>> >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> >> >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 15:22:54 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0470E3A6C34; Fri, 6 Jun 2008 15:22:54 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCEC13A6BF6 for ; Fri, 6 Jun 2008 15:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1s4eDEboggRe for ; Fri, 6 Jun 2008 15:22:51 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by core3.amsl.com (Postfix) with ESMTP id 2B7503A6C34 for ; Fri, 6 Jun 2008 15:22:51 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so523884and.122 for ; Fri, 06 Jun 2008 15:22:57 -0700 (PDT) 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=XIEre4Q7zBS8+WCjayrAp7VEHfYq4aNcvOakdcTKMGU=; b=eXAnT/3ck+lj1gKtVh7id7jbmYYFg2qabbmuj+ZBASrDqkRygvXIb7APZk9F7rhXLD q6AMBuCCL3jJtcTYJQBOfiTqQZdRWtYn5hC7bf2Hmn+JpRddTR5BSn0KDQnen15JxWbj u9WjVGHgfe1qdTwDm9x/G+2yIQSljO/b19Z48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=FTQOWYkZmKAfhQtVRYS/k9WLHh05amhC3YZSUYp6i8Fuc9qRc3+UPH36uZ7wqtJdcp ke7CL5QzCV9LdAdbe/2343owuX5dzBOzcrE7pQ1wg/kW9rbp98ivydSJATitUV65B43L 8xyVloOXaiVHZq8LGgTrSsA55frVs1UWHbWSI= Received: by 10.100.125.12 with SMTP id x12mr919449anc.159.1212790977488; Fri, 06 Jun 2008 15:22:57 -0700 (PDT) Received: by 10.100.141.11 with HTTP; Fri, 6 Jun 2008 15:22:56 -0700 (PDT) Message-ID: Date: Fri, 6 Jun 2008 15:22:56 -0700 From: "fan zhao" To: "Frank Xia" In-Reply-To: <006001c8c81d$e5581160$5c0c7c0a@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline References: <48401470.40706@it.uc3m.es> <7892795E1A87F04CADFCCF41FADD00FC05C0F044@xmb-ams-337.emea.cisco.com> <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> <006001c8c81d$e5581160$5c0c7c0a@china.huawei.com> Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Frank, Please see below.. On Fri, Jun 6, 2008 at 2:40 PM, Frank Xia wrote: > Hi Fan > > Please see my reply... > > BR > Frank > > ----- Original Message ----- From: "fan zhao" > To: "Frank Xia" > Cc: "Ryuji Wakikawa" ; "Julien Laganier" > ; > Sent: Friday, June 06, 2008 3:33 PM > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > >> Hi Frank, >> >> Please see below. >> >> On Fri, Jun 6, 2008 at 10:51 AM, Frank Xia wrote: >>> >>> Hi Fan, Ryuji and other colleagues. >>> >>> Agreed. >>> >>> IMHO,There are two ways for prefix delegation in Nemo, >>> that is, overlay and integrated modes. >>> >>> DHCP based PD is a overlay solution which introduce redundancy >>> while trying to reduce impact on NEMO itself. >>> >>> I favor the integrated mode in which Prefix Delegation is integrated into >>> NEMO operations >> >> I agree that signaling overhead can be reduced if multiple _related_ >> requests/responses >> are piggybacked together, e.g. during one message exchange. For the MR >> to work, it >> needs both a HoA/HNP and a MNP. Besides requesting/registering the >> MNP, there is >> no much difference between the operation of the MN and that of the MR. >> Furthermore, >> the MR can request the MNP during the establishment of IPSec SA when >> it is at either home link or foreign link. > > Frank=>For adressing in NEMO, there are two categories > nodes for addressing, that is, MRs and hosts behind MRs. > > IKE can be used for MR's addressing, while it probabaly > can't be used for host addressing (PD) without extension of IKE. Fan> We can simply define a new attribute carried in the CFG_REQUEST/CFG_REPLY configuration payload during the IKE_AUTH exchange. > >> >>> because prefix management is an integrated part >>> of NEMO. >>> PMIPv6 follow the same philosophy. >> >> If I understand correctly, PMIP is a slightly different case from >> DSMIPv6/NEMO. >> Because the connection, such as the IPSec SA, between the MAG and the LMA >> is already in place long before the MN attaches to the MAG, it makes sense >> for >> the MAG to request the HNP for the MN during the PBU/PBA exchange. With >> DSMIPv6, the MN requests the HoA/HNP during the establishment of the IPSec >> SA, therefore the MR should request the MNP during this procedure as well. > > Frank=>It is true there is difference between PMIP and NEMO. > I just do an analogy. What I want to say is it makes sense if we integrate > PD > into NEMO. Fan> OK. Sincerely, fan > >> >> What do you think? >> >> Sincerely, >> fan >> >>> >>> BR >>> Frank >>> >>> ----- Original Message ----- From: "fan zhao" >>> To: "Ryuji Wakikawa" >>> Cc: "Julien Laganier" ; >>> Sent: Friday, June 06, 2008 12:18 PM >>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >>> >>> >>>> Hi Ryuji and et al, >>>> >>>> Sorry for jumping in. >>>> I agree with Ryuji that the DHCP based PD procedure introduces >>>> redundancy. >>>> IMHO, the MR can request a MNP together with a HNP/HoA when establishing >>>> the IPSec SA with the HA. IMO, this is simpler. Do I miss something? >>>> Thanks. >>>> >>>> Sincerely, >>>> fan >>>> >>>> >>>> On Wed, Jun 4, 2008 at 5:37 PM, Ryuji Wakikawa >>>> >>>> wrote: >>>>> >>>>> Hello Pascal, >>>>> >>>>> Sorry for late response. We have interop event in Tokyo and tested >>>>> HAHA there;-) >>>>> >>>>> On 2008/06/03, at 17:08, Pascal Thubert (pthubert) wrote: >>>>> >>>>>> Hi Ryuji: >>>>>> >>>>>> I agree that PD should not impact bootstrap. These are and should be >>>>>> kept unrelated. >>>>>> >>>>>> We must be able to extend a RFC 3963 MR with PD without forcing the >>>>>> bootstrap process in the picture. So I agree not to bring DHAAD back >>>>>> into the bootstrap... >>>>> >>>>> we agree then.. >>>>> >>>>>> But I think that PD is NOT a bootstrap process. It is post bootstrap >>>>>> and >>>>>> can reoccur many times in the life of the MR. >>>>>> >>>>>> Until we define a new process and rev 3775 and 3963, we should stay >>>>>> consistent and simple in what we are doing. >>>>> >>>>> DHCP-PD can surely impact to the bootstrap process. >>>>> >>>>> Let's say MR boots up as a MN with RFC5026 first. >>>>> Then, it tries to get a MNP for NEMO. >>>>> >>>>> If the current HA is not PD-enabled and DHAAD returns different HA, >>>>> MR must de-register the binding from the current HA and tries to start >>>>> all the registration process to the new HA. >>>>> >>>>> This seems very redundant operation.. >>>>> I want to make the PD spec simple. >>>>> >>>>> regards >>>>> ryuji >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> Pascal >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>>>>> Behalf Of >>>>>> >>>>>> Ryuji Wakikawa >>>>>>> >>>>>>> Sent: mardi 3 juin 2008 09:54 >>>>>>> To: marcelo bagnulo braun >>>>>>> Cc: Julien Laganier; mext@ietf.org >>>>>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >>>>>>> >>>>>>> Hi Marcelo, >>>>>>> >>>>>>> I agree to accept this as WG doc. >>>>>>> >>>>>>> I also agree with Romain and Vijay. >>>>>>> We don't need extension to DHAAD. >>>>>>> Since MR can act as MN, MR should be able to bootstrap with the same >>>>>>> mechanism of MIP (except for PD). >>>>>>> We should not bring DHAAD back in the bootstrap process only for PD. >>>>>>> >>>>>>> regards, >>>>>>> ryuji >>>>>>> >>>>>>> >>>>>>> On 2008/05/30, at 23:51, marcelo bagnulo braun wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> We would like to ask the WG what is their opinion about accepting >>>>>>>> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD >>>>>>>> deliverable included in our charter. >>>>>>>> >>>>>>>> Please provide comments so we cna make some progress on this long >>>>>>>> overdue deliverable >>>>>>>> >>>>>>>> thanks, Julien and marcelo >>>>>>>> -------- Mensaje original -------- >>>>>>>> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt >>>>>>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >>>>>>>> De: Internet-Drafts@ietf.org >>>>>>>> Responder a: internet-drafts@ietf.org >>>>>>>> Para: i-d-announce@ietf.org >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>>>> directories. >>>>>>>> >>>>>>>> Title : DHCPv6 Prefix Delegation for NEMO >>>>>>>> Author(s) : R. Droms, et al. >>>>>>>> Filename : draft-droms-mext-nemo-pd-00.txt >>>>>>>> Pages : 12 >>>>>>>> Date : 2008-05-30 >>>>>>>> >>>>>>>> One aspect of network mobility support is the assignment of a prefix >>>>>>>> or prefixes to a Mobile Router (MR) for use on the links in the >>>>>>>> Mobile Network. DHCPv6 prefix delegation can be used for this >>>>>>>> configuration task. >>>>>>>> >>>>>>>> A URL for this Internet-Draft is: >>>>>>>> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt >>>>>>>> >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>> >>>>>>>> Below is the data which will enable a MIME compliant mail reader >>>>>>>> implementation to automatically retrieve the ASCII version of the >>>>>>>> Internet-Draft. >>>>>>>> >>>>>>>> >>>>>>>> Content-Type: text/plain >>>>>>>> Content-ID: <2008-05-30054232.I-D@ietf.org> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> I-D-Announce mailing list >>>>>>>> I-D-Announce@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>> >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>> >>> >>> >> > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 15:35:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 374103A68B2; Fri, 6 Jun 2008 15:35:40 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D8F23A68B2 for ; Fri, 6 Jun 2008 15:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAp7xXSVy6ur for ; Fri, 6 Jun 2008 15:35:37 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id DB19B3A681D for ; Fri, 6 Jun 2008 15:35:36 -0700 (PDT) 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 <0K2200CTGC3NX3@usaga04-in.huawei.com> for mext@ietf.org; Fri, 06 Jun 2008 17:35:47 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K2200AC5C3L9H@usaga04-in.huawei.com> for mext@ietf.org; Fri, 06 Jun 2008 17:35:47 -0500 (CDT) Date: Fri, 06 Jun 2008 17:35:45 -0500 From: Frank Xia To: fan zhao Message-id: <004901c8c825$a9ad9650$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <48401470.40706@it.uc3m.es> <7892795E1A87F04CADFCCF41FADD00FC05C0F044@xmb-ams-337.emea.cisco.com> <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> <006001c8c81d$e5581160$5c0c7c0a@china.huawei.com> Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Fan Please check my reply... BR Frank ----- Original Message ----- From: "fan zhao" To: "Frank Xia" Cc: "Ryuji Wakikawa" ; "Julien Laganier" ; Sent: Friday, June 06, 2008 5:22 PM Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > Hi Frank, > > Please see below.. > > On Fri, Jun 6, 2008 at 2:40 PM, Frank Xia wrote: >> Hi Fan >> >> Please see my reply... >> >> BR >> Frank >> >> ----- Original Message ----- From: "fan zhao" >> To: "Frank Xia" >> Cc: "Ryuji Wakikawa" ; "Julien Laganier" >> ; >> Sent: Friday, June 06, 2008 3:33 PM >> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> >> >>> Hi Frank, >>> >>> Please see below. >>> >>> On Fri, Jun 6, 2008 at 10:51 AM, Frank Xia >>> wrote: >>>> >>>> Hi Fan, Ryuji and other colleagues. >>>> >>>> Agreed. >>>> >>>> IMHO,There are two ways for prefix delegation in Nemo, >>>> that is, overlay and integrated modes. >>>> >>>> DHCP based PD is a overlay solution which introduce redundancy >>>> while trying to reduce impact on NEMO itself. >>>> >>>> I favor the integrated mode in which Prefix Delegation is integrated >>>> into >>>> NEMO operations >>> >>> I agree that signaling overhead can be reduced if multiple _related_ >>> requests/responses >>> are piggybacked together, e.g. during one message exchange. For the MR >>> to work, it >>> needs both a HoA/HNP and a MNP. Besides requesting/registering the >>> MNP, there is >>> no much difference between the operation of the MN and that of the MR. >>> Furthermore, >>> the MR can request the MNP during the establishment of IPSec SA when >>> it is at either home link or foreign link. >> >> Frank=>For adressing in NEMO, there are two categories >> nodes for addressing, that is, MRs and hosts behind MRs. >> >> IKE can be used for MR's addressing, while it probabaly >> can't be used for host addressing (PD) without extension of IKE. > > Fan> We can simply define a new attribute carried in the > CFG_REQUEST/CFG_REPLY > configuration payload during the IKE_AUTH exchange. Frank=>It couples PD with IKE procedure. How does the MR renew/release/renumber the prefixes after IKE_AUTH exchange? Anyway, IKE is not solely for MIP, IMHO, it is not proper to extend for this purpose. IMO, the compromised way is to use BA/BU which is in line with PMIP thoughtway. > > >> >>> >>>> because prefix management is an integrated part >>>> of NEMO. >>>> PMIPv6 follow the same philosophy. >>> >>> If I understand correctly, PMIP is a slightly different case from >>> DSMIPv6/NEMO. >>> Because the connection, such as the IPSec SA, between the MAG and the >>> LMA >>> is already in place long before the MN attaches to the MAG, it makes >>> sense >>> for >>> the MAG to request the HNP for the MN during the PBU/PBA exchange. With >>> DSMIPv6, the MN requests the HoA/HNP during the establishment of the >>> IPSec >>> SA, therefore the MR should request the MNP during this procedure as >>> well. >> >> Frank=>It is true there is difference between PMIP and NEMO. >> I just do an analogy. What I want to say is it makes sense if we >> integrate >> PD >> into NEMO. > > Fan> OK. > > Sincerely, > fan > >> >>> >>> What do you think? >>> >>> Sincerely, >>> fan >>> >>>> >>>> BR >>>> Frank >>>> >>>> ----- Original Message ----- From: "fan zhao" >>>> To: "Ryuji Wakikawa" >>>> Cc: "Julien Laganier" ; >>>> Sent: Friday, June 06, 2008 12:18 PM >>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >>>> >>>> >>>>> Hi Ryuji and et al, >>>>> >>>>> Sorry for jumping in. >>>>> I agree with Ryuji that the DHCP based PD procedure introduces >>>>> redundancy. >>>>> IMHO, the MR can request a MNP together with a HNP/HoA when >>>>> establishing >>>>> the IPSec SA with the HA. IMO, this is simpler. Do I miss something? >>>>> Thanks. >>>>> >>>>> Sincerely, >>>>> fan >>>>> >>>>> >>>>> On Wed, Jun 4, 2008 at 5:37 PM, Ryuji Wakikawa >>>>> >>>>> wrote: >>>>>> >>>>>> Hello Pascal, >>>>>> >>>>>> Sorry for late response. We have interop event in Tokyo and tested >>>>>> HAHA there;-) >>>>>> >>>>>> On 2008/06/03, at 17:08, Pascal Thubert (pthubert) wrote: >>>>>> >>>>>>> Hi Ryuji: >>>>>>> >>>>>>> I agree that PD should not impact bootstrap. These are and should be >>>>>>> kept unrelated. >>>>>>> >>>>>>> We must be able to extend a RFC 3963 MR with PD without forcing the >>>>>>> bootstrap process in the picture. So I agree not to bring DHAAD back >>>>>>> into the bootstrap... >>>>>> >>>>>> we agree then.. >>>>>> >>>>>>> But I think that PD is NOT a bootstrap process. It is post bootstrap >>>>>>> and >>>>>>> can reoccur many times in the life of the MR. >>>>>>> >>>>>>> Until we define a new process and rev 3775 and 3963, we should stay >>>>>>> consistent and simple in what we are doing. >>>>>> >>>>>> DHCP-PD can surely impact to the bootstrap process. >>>>>> >>>>>> Let's say MR boots up as a MN with RFC5026 first. >>>>>> Then, it tries to get a MNP for NEMO. >>>>>> >>>>>> If the current HA is not PD-enabled and DHAAD returns different HA, >>>>>> MR must de-register the binding from the current HA and tries to >>>>>> start >>>>>> all the registration process to the new HA. >>>>>> >>>>>> This seems very redundant operation.. >>>>>> I want to make the PD spec simple. >>>>>> >>>>>> regards >>>>>> ryuji >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Pascal >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>>>>>> Behalf Of >>>>>>> >>>>>>> Ryuji Wakikawa >>>>>>>> >>>>>>>> Sent: mardi 3 juin 2008 09:54 >>>>>>>> To: marcelo bagnulo braun >>>>>>>> Cc: Julien Laganier; mext@ietf.org >>>>>>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >>>>>>>> >>>>>>>> Hi Marcelo, >>>>>>>> >>>>>>>> I agree to accept this as WG doc. >>>>>>>> >>>>>>>> I also agree with Romain and Vijay. >>>>>>>> We don't need extension to DHAAD. >>>>>>>> Since MR can act as MN, MR should be able to bootstrap with the >>>>>>>> same >>>>>>>> mechanism of MIP (except for PD). >>>>>>>> We should not bring DHAAD back in the bootstrap process only for >>>>>>>> PD. >>>>>>>> >>>>>>>> regards, >>>>>>>> ryuji >>>>>>>> >>>>>>>> >>>>>>>> On 2008/05/30, at 23:51, marcelo bagnulo braun wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> We would like to ask the WG what is their opinion about accepting >>>>>>>>> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD >>>>>>>>> deliverable included in our charter. >>>>>>>>> >>>>>>>>> Please provide comments so we cna make some progress on this long >>>>>>>>> overdue deliverable >>>>>>>>> >>>>>>>>> thanks, Julien and marcelo >>>>>>>>> -------- Mensaje original -------- >>>>>>>>> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt >>>>>>>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >>>>>>>>> De: Internet-Drafts@ietf.org >>>>>>>>> Responder a: internet-drafts@ietf.org >>>>>>>>> Para: i-d-announce@ietf.org >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>>>>> directories. >>>>>>>>> >>>>>>>>> Title : DHCPv6 Prefix Delegation for NEMO >>>>>>>>> Author(s) : R. Droms, et al. >>>>>>>>> Filename : draft-droms-mext-nemo-pd-00.txt >>>>>>>>> Pages : 12 >>>>>>>>> Date : 2008-05-30 >>>>>>>>> >>>>>>>>> One aspect of network mobility support is the assignment of a >>>>>>>>> prefix >>>>>>>>> or prefixes to a Mobile Router (MR) for use on the links in the >>>>>>>>> Mobile Network. DHCPv6 prefix delegation can be used for this >>>>>>>>> configuration task. >>>>>>>>> >>>>>>>>> A URL for this Internet-Draft is: >>>>>>>>> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt >>>>>>>>> >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>> >>>>>>>>> Below is the data which will enable a MIME compliant mail reader >>>>>>>>> implementation to automatically retrieve the ASCII version of the >>>>>>>>> Internet-Draft. >>>>>>>>> >>>>>>>>> >>>>>>>>> Content-Type: text/plain >>>>>>>>> Content-ID: <2008-05-30054232.I-D@ietf.org> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> I-D-Announce mailing list >>>>>>>>> I-D-Announce@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> MEXT mailing list >>>>>>>>> MEXT@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>> >>>> >>>> >>> >> >> >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 16:30:36 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26CBE3A6B6C; Fri, 6 Jun 2008 16:30:36 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45F513A6875 for ; Fri, 6 Jun 2008 16:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyVTyzIUMOhy for ; Fri, 6 Jun 2008 16:30:29 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 2E71E3A6BCA for ; Fri, 6 Jun 2008 16:30:29 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1460647rvf.49 for ; Fri, 06 Jun 2008 16:30:39 -0700 (PDT) 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=MyTDKldNgG2tacJiVeY7lJmY6lAHu6JAdokN4uveVFw=; b=fIqfzOP5pFKybIhlNqLwobGLsotE4XmOiG6ugYC0vcng5kDSfygDLE4wLumHGtfr1E +i+GxhCQsCZvE03QQsVlBNPkY23UX2Xt+niYEZCEDR9FkMPTfXPdCVFbSLv6VzTz5KzV ngT1bUiE9rhRaLBHBbVtv5pREz0zu8dAv/R5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=DJU62PG0gapEn7Bb9JmSGY/OExbNwvcDV0cvRgjHO3bOQDbq4lRBdooqPdwYq6/Y3M Ldiwvyqqwnmyzimu/2FcgF8jsFDnLjUok+07eq+fpef8TtLZucxOZfDSifWVXqWIL5QL VGTLFvUqct94jPeVQzl4VbM6M85q04Fp5c99w= Received: by 10.141.162.16 with SMTP id p16mr423789rvo.243.1212795039763; Fri, 06 Jun 2008 16:30:39 -0700 (PDT) Received: by 10.141.189.15 with HTTP; Fri, 6 Jun 2008 16:30:39 -0700 (PDT) Message-ID: <729b68be0806061630i7d88afa2w235dad4bafe74daa@mail.gmail.com> Date: Sat, 7 Jun 2008 01:30:39 +0200 From: "Jean-Michel Combes" To: "Frank Xia" In-Reply-To: <004901c8c825$a9ad9650$5c0c7c0a@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline References: <48401470.40706@it.uc3m.es> <7892795E1A87F04CADFCCF41FADD00FC05C0F044@xmb-ams-337.emea.cisco.com> <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> <006001c8c81d$e5581160$5c0c7c0a@china.huawei.com> <004901c8c825$a9ad9650$5c0c7c0a@china.huawei.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Don't forget that people may want to deploy SEND and so you will have to provide Router Authorization Certificate too in that case. AFAIK, for the moment, there is no proposal to provide such certificates with PBU/PBA and so you will have another mechanism. The consequence is that you will loose the advantage in time you gained in piggybacking the delegated prefixes in the PBU/PBA ... This is not the case with PMIP because the LMA is aware of the prefixes assigned to the MAGs and during the set up of 2008/6/7, Frank Xia : > Hi Fan > > Please check my reply... > > > BR > Frank > > ----- Original Message ----- > From: "fan zhao" > To: "Frank Xia" > Cc: "Ryuji Wakikawa" ; "Julien Laganier" > ; > > Sent: Friday, June 06, 2008 5:22 PM > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > > > Hi Frank, > > > > Please see below.. > > > > On Fri, Jun 6, 2008 at 2:40 PM, Frank Xia wrote: > >> Hi Fan > >> > >> Please see my reply... > >> > >> BR > >> Frank > >> > >> ----- Original Message ----- From: "fan zhao" > >> To: "Frank Xia" > >> Cc: "Ryuji Wakikawa" ; "Julien Laganier" > >> ; > >> Sent: Friday, June 06, 2008 3:33 PM > >> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > >> > >> > >>> Hi Frank, > >>> > >>> Please see below. > >>> > >>> On Fri, Jun 6, 2008 at 10:51 AM, Frank Xia > >>> wrote: > >>>> > >>>> Hi Fan, Ryuji and other colleagues. > >>>> > >>>> Agreed. > >>>> > >>>> IMHO,There are two ways for prefix delegation in Nemo, > >>>> that is, overlay and integrated modes. > >>>> > >>>> DHCP based PD is a overlay solution which introduce redundancy > >>>> while trying to reduce impact on NEMO itself. > >>>> > >>>> I favor the integrated mode in which Prefix Delegation is integrated > >>>> into > >>>> NEMO operations > >>> > >>> I agree that signaling overhead can be reduced if multiple _related_ > >>> requests/responses > >>> are piggybacked together, e.g. during one message exchange. For the MR > >>> to work, it > >>> needs both a HoA/HNP and a MNP. Besides requesting/registering the > >>> MNP, there is > >>> no much difference between the operation of the MN and that of the MR. > >>> Furthermore, > >>> the MR can request the MNP during the establishment of IPSec SA when > >>> it is at either home link or foreign link. > >> > >> Frank=>For adressing in NEMO, there are two categories > >> nodes for addressing, that is, MRs and hosts behind MRs. > >> > >> IKE can be used for MR's addressing, while it probabaly > >> can't be used for host addressing (PD) without extension of IKE. > > > > Fan> We can simply define a new attribute carried in the > > CFG_REQUEST/CFG_REPLY > > configuration payload during the IKE_AUTH exchange. > > Frank=>It couples PD with IKE procedure. How does the > MR renew/release/renumber the prefixes after IKE_AUTH exchange? > Anyway, IKE is not solely for MIP, IMHO, it is not proper to > extend for this purpose. > > IMO, the compromised way is to use BA/BU which > is in line with PMIP thoughtway. > > > > > > > >> > >>> > >>>> because prefix management is an integrated part > >>>> of NEMO. > >>>> PMIPv6 follow the same philosophy. > >>> > >>> If I understand correctly, PMIP is a slightly different case from > >>> DSMIPv6/NEMO. > >>> Because the connection, such as the IPSec SA, between the MAG and the > >>> LMA > >>> is already in place long before the MN attaches to the MAG, it makes > >>> sense > >>> for > >>> the MAG to request the HNP for the MN during the PBU/PBA exchange. With > >>> DSMIPv6, the MN requests the HoA/HNP during the establishment of the > >>> IPSec > >>> SA, therefore the MR should request the MNP during this procedure as > >>> well. > >> > >> Frank=>It is true there is difference between PMIP and NEMO. > >> I just do an analogy. What I want to say is it makes sense if we > >> integrate > >> PD > >> into NEMO. > > > > Fan> OK. > > > > Sincerely, > > fan > > > >> > >>> > >>> What do you think? > >>> > >>> Sincerely, > >>> fan > >>> > >>>> > >>>> BR > >>>> Frank > >>>> > >>>> ----- Original Message ----- From: "fan zhao" > >>>> To: "Ryuji Wakikawa" > >>>> Cc: "Julien Laganier" ; > >>>> Sent: Friday, June 06, 2008 12:18 PM > >>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > >>>> > >>>> > >>>>> Hi Ryuji and et al, > >>>>> > >>>>> Sorry for jumping in. > >>>>> I agree with Ryuji that the DHCP based PD procedure introduces > >>>>> redundancy. > >>>>> IMHO, the MR can request a MNP together with a HNP/HoA when > >>>>> establishing > >>>>> the IPSec SA with the HA. IMO, this is simpler. Do I miss something? > >>>>> Thanks. > >>>>> > >>>>> Sincerely, > >>>>> fan > >>>>> > >>>>> > >>>>> On Wed, Jun 4, 2008 at 5:37 PM, Ryuji Wakikawa > >>>>> > >>>>> wrote: > >>>>>> > >>>>>> Hello Pascal, > >>>>>> > >>>>>> Sorry for late response. We have interop event in Tokyo and tested > >>>>>> HAHA there;-) > >>>>>> > >>>>>> On 2008/06/03, at 17:08, Pascal Thubert (pthubert) wrote: > >>>>>> > >>>>>>> Hi Ryuji: > >>>>>>> > >>>>>>> I agree that PD should not impact bootstrap. These are and should be > >>>>>>> kept unrelated. > >>>>>>> > >>>>>>> We must be able to extend a RFC 3963 MR with PD without forcing the > >>>>>>> bootstrap process in the picture. So I agree not to bring DHAAD back > >>>>>>> into the bootstrap... > >>>>>> > >>>>>> we agree then.. > >>>>>> > >>>>>>> But I think that PD is NOT a bootstrap process. It is post bootstrap > >>>>>>> and > >>>>>>> can reoccur many times in the life of the MR. > >>>>>>> > >>>>>>> Until we define a new process and rev 3775 and 3963, we should stay > >>>>>>> consistent and simple in what we are doing. > >>>>>> > >>>>>> DHCP-PD can surely impact to the bootstrap process. > >>>>>> > >>>>>> Let's say MR boots up as a MN with RFC5026 first. > >>>>>> Then, it tries to get a MNP for NEMO. > >>>>>> > >>>>>> If the current HA is not PD-enabled and DHAAD returns different HA, > >>>>>> MR must de-register the binding from the current HA and tries to > >>>>>> start > >>>>>> all the registration process to the new HA. > >>>>>> > >>>>>> This seems very redundant operation.. > >>>>>> I want to make the PD spec simple. > >>>>>> > >>>>>> regards > >>>>>> ryuji > >>>>>> > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Pascal > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > >>>>>>>> Behalf Of > >>>>>>> > >>>>>>> Ryuji Wakikawa > >>>>>>>> > >>>>>>>> Sent: mardi 3 juin 2008 09:54 > >>>>>>>> To: marcelo bagnulo braun > >>>>>>>> Cc: Julien Laganier; mext@ietf.org > >>>>>>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > >>>>>>>> > >>>>>>>> Hi Marcelo, > >>>>>>>> > >>>>>>>> I agree to accept this as WG doc. > >>>>>>>> > >>>>>>>> I also agree with Romain and Vijay. > >>>>>>>> We don't need extension to DHAAD. > >>>>>>>> Since MR can act as MN, MR should be able to bootstrap with the > >>>>>>>> same > >>>>>>>> mechanism of MIP (except for PD). > >>>>>>>> We should not bring DHAAD back in the bootstrap process only for > >>>>>>>> PD. > >>>>>>>> > >>>>>>>> regards, > >>>>>>>> ryuji > >>>>>>>> > >>>>>>>> > >>>>>>>> On 2008/05/30, at 23:51, marcelo bagnulo braun wrote: > >>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> We would like to ask the WG what is their opinion about accepting > >>>>>>>>> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD > >>>>>>>>> deliverable included in our charter. > >>>>>>>>> > >>>>>>>>> Please provide comments so we cna make some progress on this long > >>>>>>>>> overdue deliverable > >>>>>>>>> > >>>>>>>>> thanks, Julien and marcelo > >>>>>>>>> -------- Mensaje original -------- > >>>>>>>>> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt > >>>>>>>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) > >>>>>>>>> De: Internet-Drafts@ietf.org > >>>>>>>>> Responder a: internet-drafts@ietf.org > >>>>>>>>> Para: i-d-announce@ietf.org > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts > >>>>>>>>> directories. > >>>>>>>>> > >>>>>>>>> Title : DHCPv6 Prefix Delegation for NEMO > >>>>>>>>> Author(s) : R. Droms, et al. > >>>>>>>>> Filename : draft-droms-mext-nemo-pd-00.txt > >>>>>>>>> Pages : 12 > >>>>>>>>> Date : 2008-05-30 > >>>>>>>>> > >>>>>>>>> One aspect of network mobility support is the assignment of a > >>>>>>>>> prefix > >>>>>>>>> or prefixes to a Mobile Router (MR) for use on the links in the > >>>>>>>>> Mobile Network. DHCPv6 prefix delegation can be used for this > >>>>>>>>> configuration task. > >>>>>>>>> > >>>>>>>>> A URL for this Internet-Draft is: > >>>>>>>>> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt > >>>>>>>>> > >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>>>>>> > >>>>>>>>> Below is the data which will enable a MIME compliant mail reader > >>>>>>>>> implementation to automatically retrieve the ASCII version of the > >>>>>>>>> Internet-Draft. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Content-Type: text/plain > >>>>>>>>> Content-ID: <2008-05-30054232.I-D@ietf.org> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> I-D-Announce mailing list > >>>>>>>>> I-D-Announce@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html > >>>>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> MEXT mailing list > >>>>>>>>> MEXT@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> MEXT mailing list > >>>>>>>> MEXT@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>> > >>>>>> _______________________________________________ > >>>>>> MEXT mailing list > >>>>>> MEXT@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>> > >>>>> _______________________________________________ > >>>>> MEXT mailing list > >>>>> MEXT@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>> > >>>> > >>>> > >>>> > >>> > >> > >> > >> > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 16:34:59 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD7DE3A691C; Fri, 6 Jun 2008 16:34:59 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F67E3A691C for ; Fri, 6 Jun 2008 16:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrfE9CMZBzqi for ; Fri, 6 Jun 2008 16:34:53 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id AEE943A6967 for ; Fri, 6 Jun 2008 16:34:53 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1461834rvf.49 for ; Fri, 06 Jun 2008 16:35:02 -0700 (PDT) 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=8eW9jUrrflg96EpY/wxj0bnXsMuur1G6zMf0loZgAY8=; b=WREE114IMFrcbYfb5+5x1kLhJHzMk9QM5oNIfKb/T7RLMgzRpokRlZcEKSPFk0/PWK PSrCsJWsftlzgPNmcG/uLoc9DanBwZ2eo62j5AnLKktViFQDXBCWs53k6QVkouuiKszJ ud4ImBmytMRVZK1bol65rwBYD9BLEilOFEgbQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=NxCGbHKquBT8S6YcSS0wmFSWVmPRqMBWVi8IpHoyvdRrOh9EDInWpANiJFEHuXl7FI BW5z/kMeBTAM9ibFUx2jD1cZkrrMbGzCerl2xtVwq0NcVHb8eR/Y9rswOEHzoMNZsa1h aAjpkr63rwhpx5iAP9JZjpwmBslPb72CPZ8DA= Received: by 10.141.137.16 with SMTP id p16mr430995rvn.192.1212795302560; Fri, 06 Jun 2008 16:35:02 -0700 (PDT) Received: by 10.141.189.15 with HTTP; Fri, 6 Jun 2008 16:35:02 -0700 (PDT) Message-ID: <729b68be0806061635y59088fccqa629c3974d4edf97@mail.gmail.com> Date: Sat, 7 Jun 2008 01:35:02 +0200 From: "Jean-Michel Combes" To: "Frank Xia" In-Reply-To: <729b68be0806061630i7d88afa2w235dad4bafe74daa@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <48401470.40706@it.uc3m.es> <7892795E1A87F04CADFCCF41FADD00FC05C0F044@xmb-ams-337.emea.cisco.com> <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> <006001c8c81d$e5581160$5c0c7c0a@china.huawei.com> <004901c8c825$a9ad9650$5c0c7c0a@china.huawei.com> <729b68be0806061630i7d88afa2w235dad4bafe74daa@mail.gmail.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Sorry, I forgot to finish my email before to send it :) 2008/6/7, Jean-Michel Combes : > Hi, > > Don't forget that people may want to deploy SEND and so you will have > to provide Router Authorization Certificate too in that case. > AFAIK, for the moment, there is no proposal to provide such > certificates with PBU/PBA and so you will have another mechanism. The > consequence is that you will loose the advantage in time you gained in > piggybacking the delegated prefixes in the PBU/PBA ... > > This is not the case with PMIP because the LMA is aware of the > prefixes assigned to the MAGs and during the set up of a MAG, the LMA may provide a Router Authorization Certificate linked to a prefix containing all the future prefixes advertised by this MAG. Best regards. JMC. > > 2008/6/7, Frank Xia : > > > Hi Fan > > > > Please check my reply... > > > > > > BR > > Frank > > > > ----- Original Message ----- > > From: "fan zhao" > > To: "Frank Xia" > > Cc: "Ryuji Wakikawa" ; "Julien Laganier" > > ; > > > > Sent: Friday, June 06, 2008 5:22 PM > > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > > > > > > Hi Frank, > > > > > > Please see below.. > > > > > > On Fri, Jun 6, 2008 at 2:40 PM, Frank Xia wrote: > > >> Hi Fan > > >> > > >> Please see my reply... > > >> > > >> BR > > >> Frank > > >> > > >> ----- Original Message ----- From: "fan zhao" > > >> To: "Frank Xia" > > >> Cc: "Ryuji Wakikawa" ; "Julien Laganier" > > >> ; > > >> Sent: Friday, June 06, 2008 3:33 PM > > >> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > >> > > >> > > >>> Hi Frank, > > >>> > > >>> Please see below. > > >>> > > >>> On Fri, Jun 6, 2008 at 10:51 AM, Frank Xia > > >>> wrote: > > >>>> > > >>>> Hi Fan, Ryuji and other colleagues. > > >>>> > > >>>> Agreed. > > >>>> > > >>>> IMHO,There are two ways for prefix delegation in Nemo, > > >>>> that is, overlay and integrated modes. > > >>>> > > >>>> DHCP based PD is a overlay solution which introduce redundancy > > >>>> while trying to reduce impact on NEMO itself. > > >>>> > > >>>> I favor the integrated mode in which Prefix Delegation is integrated > > >>>> into > > >>>> NEMO operations > > >>> > > >>> I agree that signaling overhead can be reduced if multiple _related_ > > >>> requests/responses > > >>> are piggybacked together, e.g. during one message exchange. For the MR > > >>> to work, it > > >>> needs both a HoA/HNP and a MNP. Besides requesting/registering the > > >>> MNP, there is > > >>> no much difference between the operation of the MN and that of the MR. > > >>> Furthermore, > > >>> the MR can request the MNP during the establishment of IPSec SA when > > >>> it is at either home link or foreign link. > > >> > > >> Frank=>For adressing in NEMO, there are two categories > > >> nodes for addressing, that is, MRs and hosts behind MRs. > > >> > > >> IKE can be used for MR's addressing, while it probabaly > > >> can't be used for host addressing (PD) without extension of IKE. > > > > > > Fan> We can simply define a new attribute carried in the > > > CFG_REQUEST/CFG_REPLY > > > configuration payload during the IKE_AUTH exchange. > > > > Frank=>It couples PD with IKE procedure. How does the > > MR renew/release/renumber the prefixes after IKE_AUTH exchange? > > Anyway, IKE is not solely for MIP, IMHO, it is not proper to > > extend for this purpose. > > > > IMO, the compromised way is to use BA/BU which > > is in line with PMIP thoughtway. > > > > > > > > > > > > >> > > >>> > > >>>> because prefix management is an integrated part > > >>>> of NEMO. > > >>>> PMIPv6 follow the same philosophy. > > >>> > > >>> If I understand correctly, PMIP is a slightly different case from > > >>> DSMIPv6/NEMO. > > >>> Because the connection, such as the IPSec SA, between the MAG and the > > >>> LMA > > >>> is already in place long before the MN attaches to the MAG, it makes > > >>> sense > > >>> for > > >>> the MAG to request the HNP for the MN during the PBU/PBA exchange. With > > >>> DSMIPv6, the MN requests the HoA/HNP during the establishment of the > > >>> IPSec > > >>> SA, therefore the MR should request the MNP during this procedure as > > >>> well. > > >> > > >> Frank=>It is true there is difference between PMIP and NEMO. > > >> I just do an analogy. What I want to say is it makes sense if we > > >> integrate > > >> PD > > >> into NEMO. > > > > > > Fan> OK. > > > > > > Sincerely, > > > fan > > > > > >> > > >>> > > >>> What do you think? > > >>> > > >>> Sincerely, > > >>> fan > > >>> > > >>>> > > >>>> BR > > >>>> Frank > > >>>> > > >>>> ----- Original Message ----- From: "fan zhao" > > >>>> To: "Ryuji Wakikawa" > > >>>> Cc: "Julien Laganier" ; > > >>>> Sent: Friday, June 06, 2008 12:18 PM > > >>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > >>>> > > >>>> > > >>>>> Hi Ryuji and et al, > > >>>>> > > >>>>> Sorry for jumping in. > > >>>>> I agree with Ryuji that the DHCP based PD procedure introduces > > >>>>> redundancy. > > >>>>> IMHO, the MR can request a MNP together with a HNP/HoA when > > >>>>> establishing > > >>>>> the IPSec SA with the HA. IMO, this is simpler. Do I miss something? > > >>>>> Thanks. > > >>>>> > > >>>>> Sincerely, > > >>>>> fan > > >>>>> > > >>>>> > > >>>>> On Wed, Jun 4, 2008 at 5:37 PM, Ryuji Wakikawa > > >>>>> > > >>>>> wrote: > > >>>>>> > > >>>>>> Hello Pascal, > > >>>>>> > > >>>>>> Sorry for late response. We have interop event in Tokyo and tested > > >>>>>> HAHA there;-) > > >>>>>> > > >>>>>> On 2008/06/03, at 17:08, Pascal Thubert (pthubert) wrote: > > >>>>>> > > >>>>>>> Hi Ryuji: > > >>>>>>> > > >>>>>>> I agree that PD should not impact bootstrap. These are and should be > > >>>>>>> kept unrelated. > > >>>>>>> > > >>>>>>> We must be able to extend a RFC 3963 MR with PD without forcing the > > >>>>>>> bootstrap process in the picture. So I agree not to bring DHAAD back > > >>>>>>> into the bootstrap... > > >>>>>> > > >>>>>> we agree then.. > > >>>>>> > > >>>>>>> But I think that PD is NOT a bootstrap process. It is post bootstrap > > >>>>>>> and > > >>>>>>> can reoccur many times in the life of the MR. > > >>>>>>> > > >>>>>>> Until we define a new process and rev 3775 and 3963, we should stay > > >>>>>>> consistent and simple in what we are doing. > > >>>>>> > > >>>>>> DHCP-PD can surely impact to the bootstrap process. > > >>>>>> > > >>>>>> Let's say MR boots up as a MN with RFC5026 first. > > >>>>>> Then, it tries to get a MNP for NEMO. > > >>>>>> > > >>>>>> If the current HA is not PD-enabled and DHAAD returns different HA, > > >>>>>> MR must de-register the binding from the current HA and tries to > > >>>>>> start > > >>>>>> all the registration process to the new HA. > > >>>>>> > > >>>>>> This seems very redundant operation.. > > >>>>>> I want to make the PD spec simple. > > >>>>>> > > >>>>>> regards > > >>>>>> ryuji > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Pascal > > >>>>>>> > > >>>>>>>> -----Original Message----- > > >>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > >>>>>>>> Behalf Of > > >>>>>>> > > >>>>>>> Ryuji Wakikawa > > >>>>>>>> > > >>>>>>>> Sent: mardi 3 juin 2008 09:54 > > >>>>>>>> To: marcelo bagnulo braun > > >>>>>>>> Cc: Julien Laganier; mext@ietf.org > > >>>>>>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > >>>>>>>> > > >>>>>>>> Hi Marcelo, > > >>>>>>>> > > >>>>>>>> I agree to accept this as WG doc. > > >>>>>>>> > > >>>>>>>> I also agree with Romain and Vijay. > > >>>>>>>> We don't need extension to DHAAD. > > >>>>>>>> Since MR can act as MN, MR should be able to bootstrap with the > > >>>>>>>> same > > >>>>>>>> mechanism of MIP (except for PD). > > >>>>>>>> We should not bring DHAAD back in the bootstrap process only for > > >>>>>>>> PD. > > >>>>>>>> > > >>>>>>>> regards, > > >>>>>>>> ryuji > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On 2008/05/30, at 23:51, marcelo bagnulo braun wrote: > > >>>>>>>> > > >>>>>>>>> Hi, > > >>>>>>>>> > > >>>>>>>>> We would like to ask the WG what is their opinion about accepting > > >>>>>>>>> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD > > >>>>>>>>> deliverable included in our charter. > > >>>>>>>>> > > >>>>>>>>> Please provide comments so we cna make some progress on this long > > >>>>>>>>> overdue deliverable > > >>>>>>>>> > > >>>>>>>>> thanks, Julien and marcelo > > >>>>>>>>> -------- Mensaje original -------- > > >>>>>>>>> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt > > >>>>>>>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) > > >>>>>>>>> De: Internet-Drafts@ietf.org > > >>>>>>>>> Responder a: internet-drafts@ietf.org > > >>>>>>>>> Para: i-d-announce@ietf.org > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts > > >>>>>>>>> directories. > > >>>>>>>>> > > >>>>>>>>> Title : DHCPv6 Prefix Delegation for NEMO > > >>>>>>>>> Author(s) : R. Droms, et al. > > >>>>>>>>> Filename : draft-droms-mext-nemo-pd-00.txt > > >>>>>>>>> Pages : 12 > > >>>>>>>>> Date : 2008-05-30 > > >>>>>>>>> > > >>>>>>>>> One aspect of network mobility support is the assignment of a > > >>>>>>>>> prefix > > >>>>>>>>> or prefixes to a Mobile Router (MR) for use on the links in the > > >>>>>>>>> Mobile Network. DHCPv6 prefix delegation can be used for this > > >>>>>>>>> configuration task. > > >>>>>>>>> > > >>>>>>>>> A URL for this Internet-Draft is: > > >>>>>>>>> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt > > >>>>>>>>> > > >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: > > >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ > > >>>>>>>>> > > >>>>>>>>> Below is the data which will enable a MIME compliant mail reader > > >>>>>>>>> implementation to automatically retrieve the ASCII version of the > > >>>>>>>>> Internet-Draft. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Content-Type: text/plain > > >>>>>>>>> Content-ID: <2008-05-30054232.I-D@ietf.org> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> _______________________________________________ > > >>>>>>>>> I-D-Announce mailing list > > >>>>>>>>> I-D-Announce@ietf.org > > >>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce > > >>>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html > > >>>>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >>>>>>>>> > > >>>>>>>>> _______________________________________________ > > >>>>>>>>> MEXT mailing list > > >>>>>>>>> MEXT@ietf.org > > >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext > > >>>>>>>> > > >>>>>>>> _______________________________________________ > > >>>>>>>> MEXT mailing list > > >>>>>>>> MEXT@ietf.org > > >>>>>>>> https://www.ietf.org/mailman/listinfo/mext > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> MEXT mailing list > > >>>>>> MEXT@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/mext > > >>>>>> > > >>>>> _______________________________________________ > > >>>>> MEXT mailing list > > >>>>> MEXT@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/mext > > >>>>> > > >>>> > > >>>> > > >>>> > > >>> > > >> > > >> > > >> > > > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 16:55:24 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCD9F3A6A5C; Fri, 6 Jun 2008 16:55:24 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1680828C0F1 for ; Fri, 6 Jun 2008 16:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4fcfoPqOdWm for ; Fri, 6 Jun 2008 16:55:21 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by core3.amsl.com (Postfix) with ESMTP id 6C5A93A6A5C for ; Fri, 6 Jun 2008 16:55:21 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so534477and.122 for ; Fri, 06 Jun 2008 16:55:27 -0700 (PDT) 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=cErdhJ4NOmhGkZsYI+uM6yRI61sPS0Qsn7xNGOVrgT4=; b=flvR373cBsorAfz7LQG6OBhcqsdkTmZrJC2IV0IgZj29C4HN45H3iQswev4i7aoMCD oQLaMDfDqhmfODtCWlWN0nUdocot/HjkzUljDhr6ly3vc/SCsMtlSWsZ3+gTMTySfTd/ BbW4yJ5t4dBRVmnssJTExorz0vlBxrIG1bNsw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=BHp+405JARG+7SZnvHB6GrHlmZY4KD7WODcr9hENy7tblvR0q8cQkOQoCljLyDOY8W 5d5oHjEn6cNBsAwFVSLx5pwdadah8U1t7kiMO1/3e8/0fUPRGyNqPsmiufuJKOC3oOJY tM8h8Voio/jvnO/76UjZiMONtaNV6boIYSTIY= Received: by 10.100.173.18 with SMTP id v18mr991470ane.122.1212796527350; Fri, 06 Jun 2008 16:55:27 -0700 (PDT) Received: by 10.100.141.11 with HTTP; Fri, 6 Jun 2008 16:55:26 -0700 (PDT) Message-ID: Date: Fri, 6 Jun 2008 16:55:26 -0700 From: "fan zhao" To: "Frank Xia" In-Reply-To: <004901c8c825$a9ad9650$5c0c7c0a@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline References: <48401470.40706@it.uc3m.es> <7892795E1A87F04CADFCCF41FADD00FC05C0F044@xmb-ams-337.emea.cisco.com> <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> <006001c8c81d$e5581160$5c0c7c0a@china.huawei.com> <004901c8c825$a9ad9650$5c0c7c0a@china.huawei.com> Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Frank, <...> >>> Frank=>For adressing in NEMO, there are two categories >>> nodes for addressing, that is, MRs and hosts behind MRs. >>> >>> IKE can be used for MR's addressing, while it probabaly >>> can't be used for host addressing (PD) without extension of IKE. >> >> Fan> We can simply define a new attribute carried in the >> CFG_REQUEST/CFG_REPLY >> configuration payload during the IKE_AUTH exchange. > > Frank=>It couples PD with IKE procedure. Fan> We already agreed in RFC 5026 that the HoA/HNP is assigned to the MN during the IKEv2. I do not see why this is a bad thing. > How does the > MR renew/release/renumber the prefixes after IKE_AUTH exchange? Fan> There are a couple of approaches. I am open to suggestions and inputs, especially those related to NEMO deployment, as which approach is better and what value should be set depend on how often the MNP becomes expired in the real deployment. Releasing: Similar to the Prefix Lifetime field defined in RFC 5026 for the MIP6_HOME_PREFIX Attribute, we can include a lifetime field for the new attribute for MNP. In addition, the lifetime of the MNP may be associated with that of the IKE SA. Or, we can define a new type of the payload. Renewing: This is also related to the lifetime of the MNP. We can extend the lifetime of the assigned MNP by either re-keying the IKE SA, or informational exchange with CFG_REQUEST/CFG_REPLY payload. Renumbering: Informational exchange can do the work. > Anyway, IKE is not solely for MIP, IMHO, it is not proper to > extend for this purpose. Fan> One more advantage that when using the IKEv2 to request a MNP, the security is already provided by IPSec. > > IMO, the compromised way is to use BA/BU which > is in line with PMIP thoughtway. Fan> I would agree that when the MR attaches to a PMIP domain, the PBA and PBU messages are extended to carry the MNP; however not in the case of DSMIPv6/NEMO. Sincerely, fan > >> >> >>> >>>> >>>>> because prefix management is an integrated part >>>>> of NEMO. >>>>> PMIPv6 follow the same philosophy. >>>> >>>> If I understand correctly, PMIP is a slightly different case from >>>> DSMIPv6/NEMO. >>>> Because the connection, such as the IPSec SA, between the MAG and the >>>> LMA >>>> is already in place long before the MN attaches to the MAG, it makes >>>> sense >>>> for >>>> the MAG to request the HNP for the MN during the PBU/PBA exchange. With >>>> DSMIPv6, the MN requests the HoA/HNP during the establishment of the >>>> IPSec >>>> SA, therefore the MR should request the MNP during this procedure as >>>> well. >>> >>> Frank=>It is true there is difference between PMIP and NEMO. >>> I just do an analogy. What I want to say is it makes sense if we >>> integrate >>> PD >>> into NEMO. >> >> Fan> OK. >> >> Sincerely, >> fan >> >>> >>>> >>>> What do you think? >>>> >>>> Sincerely, >>>> fan >>>> >>>>> >>>>> BR >>>>> Frank >>>>> >>>>> ----- Original Message ----- From: "fan zhao" >>>>> To: "Ryuji Wakikawa" >>>>> Cc: "Julien Laganier" ; >>>>> Sent: Friday, June 06, 2008 12:18 PM >>>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >>>>> >>>>> >>>>>> Hi Ryuji and et al, >>>>>> >>>>>> Sorry for jumping in. >>>>>> I agree with Ryuji that the DHCP based PD procedure introduces >>>>>> redundancy. >>>>>> IMHO, the MR can request a MNP together with a HNP/HoA when >>>>>> establishing >>>>>> the IPSec SA with the HA. IMO, this is simpler. Do I miss something? >>>>>> Thanks. >>>>>> >>>>>> Sincerely, >>>>>> fan >>>>>> >>>>>> >>>>>> On Wed, Jun 4, 2008 at 5:37 PM, Ryuji Wakikawa >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> Hello Pascal, >>>>>>> >>>>>>> Sorry for late response. We have interop event in Tokyo and tested >>>>>>> HAHA there;-) >>>>>>> >>>>>>> On 2008/06/03, at 17:08, Pascal Thubert (pthubert) wrote: >>>>>>> >>>>>>>> Hi Ryuji: >>>>>>>> >>>>>>>> I agree that PD should not impact bootstrap. These are and should be >>>>>>>> kept unrelated. >>>>>>>> >>>>>>>> We must be able to extend a RFC 3963 MR with PD without forcing the >>>>>>>> bootstrap process in the picture. So I agree not to bring DHAAD back >>>>>>>> into the bootstrap... >>>>>>> >>>>>>> we agree then.. >>>>>>> >>>>>>>> But I think that PD is NOT a bootstrap process. It is post bootstrap >>>>>>>> and >>>>>>>> can reoccur many times in the life of the MR. >>>>>>>> >>>>>>>> Until we define a new process and rev 3775 and 3963, we should stay >>>>>>>> consistent and simple in what we are doing. >>>>>>> >>>>>>> DHCP-PD can surely impact to the bootstrap process. >>>>>>> >>>>>>> Let's say MR boots up as a MN with RFC5026 first. >>>>>>> Then, it tries to get a MNP for NEMO. >>>>>>> >>>>>>> If the current HA is not PD-enabled and DHAAD returns different HA, >>>>>>> MR must de-register the binding from the current HA and tries to >>>>>>> start >>>>>>> all the registration process to the new HA. >>>>>>> >>>>>>> This seems very redundant operation.. >>>>>>> I want to make the PD spec simple. >>>>>>> >>>>>>> regards >>>>>>> ryuji >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Pascal >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>>>>>>> Behalf Of >>>>>>>> >>>>>>>> Ryuji Wakikawa >>>>>>>>> >>>>>>>>> Sent: mardi 3 juin 2008 09:54 >>>>>>>>> To: marcelo bagnulo braun >>>>>>>>> Cc: Julien Laganier; mext@ietf.org >>>>>>>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >>>>>>>>> >>>>>>>>> Hi Marcelo, >>>>>>>>> >>>>>>>>> I agree to accept this as WG doc. >>>>>>>>> >>>>>>>>> I also agree with Romain and Vijay. >>>>>>>>> We don't need extension to DHAAD. >>>>>>>>> Since MR can act as MN, MR should be able to bootstrap with the >>>>>>>>> same >>>>>>>>> mechanism of MIP (except for PD). >>>>>>>>> We should not bring DHAAD back in the bootstrap process only for >>>>>>>>> PD. >>>>>>>>> >>>>>>>>> regards, >>>>>>>>> ryuji >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2008/05/30, at 23:51, marcelo bagnulo braun wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> We would like to ask the WG what is their opinion about accepting >>>>>>>>>> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD >>>>>>>>>> deliverable included in our charter. >>>>>>>>>> >>>>>>>>>> Please provide comments so we cna make some progress on this long >>>>>>>>>> overdue deliverable >>>>>>>>>> >>>>>>>>>> thanks, Julien and marcelo >>>>>>>>>> -------- Mensaje original -------- >>>>>>>>>> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt >>>>>>>>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >>>>>>>>>> De: Internet-Drafts@ietf.org >>>>>>>>>> Responder a: internet-drafts@ietf.org >>>>>>>>>> Para: i-d-announce@ietf.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>>>>>> directories. >>>>>>>>>> >>>>>>>>>> Title : DHCPv6 Prefix Delegation for NEMO >>>>>>>>>> Author(s) : R. Droms, et al. >>>>>>>>>> Filename : draft-droms-mext-nemo-pd-00.txt >>>>>>>>>> Pages : 12 >>>>>>>>>> Date : 2008-05-30 >>>>>>>>>> >>>>>>>>>> One aspect of network mobility support is the assignment of a >>>>>>>>>> prefix >>>>>>>>>> or prefixes to a Mobile Router (MR) for use on the links in the >>>>>>>>>> Mobile Network. DHCPv6 prefix delegation can be used for this >>>>>>>>>> configuration task. >>>>>>>>>> >>>>>>>>>> A URL for this Internet-Draft is: >>>>>>>>>> >>>>>>>>>> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt >>>>>>>>>> >>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>> >>>>>>>>>> Below is the data which will enable a MIME compliant mail reader >>>>>>>>>> implementation to automatically retrieve the ASCII version of the >>>>>>>>>> Internet-Draft. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Content-Type: text/plain >>>>>>>>>> Content-ID: <2008-05-30054232.I-D@ietf.org> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> I-D-Announce mailing list >>>>>>>>>> I-D-Announce@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> MEXT mailing list >>>>>>>>>> MEXT@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> MEXT mailing list >>>>>>>>> MEXT@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>> >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 17:02:01 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1557F3A6BE9; Fri, 6 Jun 2008 17:02:01 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8984D3A6BE9 for ; Fri, 6 Jun 2008 17:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XntM2zpZS3Zz for ; Fri, 6 Jun 2008 17:01:58 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by core3.amsl.com (Postfix) with ESMTP id DD4E13A6AC7 for ; Fri, 6 Jun 2008 17:01:57 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so535192and.122 for ; Fri, 06 Jun 2008 17:02:08 -0700 (PDT) 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=J9lXoFedybjzrg69AktOMLETT++6jW8g6dmJwnkcy8A=; b=Yun/k8P4zMy/zHfiO3hmD8pq709TTaGr6XS2h1kxn0B4mJk3+eiDkAgBaMwXo42Uy0 To83FkmHI2sE2jkCeMGjLchl1CQHt3Yj1/HW8lwvshPjo66iUOOKU6SKbdzdb+fceqEZ iEJhvhY0N5xRFKaywFkuPwZIubTnIK+wa4C2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=asuC9o6Pv5aWwVYNHD079I7os0UufObd+a2FY/dci60WTSNwsvC7eSTMiIl7bVACi4 GLucz874ez9GnUjoyna2UvS3PkhzyCy5FH3z8ekomd4cy4LpqNWcl8ago1bWytsTF3oT zPmwep8rJVKyCK2TM7q7tnjmY2mS4Ub6+rJMQ= Received: by 10.100.140.10 with SMTP id n10mr992394and.129.1212796928188; Fri, 06 Jun 2008 17:02:08 -0700 (PDT) Received: by 10.100.141.11 with HTTP; Fri, 6 Jun 2008 17:02:08 -0700 (PDT) Message-ID: Date: Fri, 6 Jun 2008 17:02:08 -0700 From: "fan zhao" To: "Jean-Michel Combes" In-Reply-To: <729b68be0806061635y59088fccqa629c3974d4edf97@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <48401470.40706@it.uc3m.es> <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> <006001c8c81d$e5581160$5c0c7c0a@china.huawei.com> <004901c8c825$a9ad9650$5c0c7c0a@china.huawei.com> <729b68be0806061630i7d88afa2w235dad4bafe74daa@mail.gmail.com> <729b68be0806061635y59088fccqa629c3974d4edf97@mail.gmail.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi JMC, I have a doubt, please see below. On Fri, Jun 6, 2008 at 4:35 PM, Jean-Michel Combes wrote: > Sorry, I forgot to finish my email before to send it :) > > 2008/6/7, Jean-Michel Combes : >> Hi, >> >> Don't forget that people may want to deploy SEND and so you will have >> to provide Router Authorization Certificate too in that case. >> AFAIK, for the moment, there is no proposal to provide such >> certificates with PBU/PBA and so you will have another mechanism. The >> consequence is that you will loose the advantage in time you gained in >> piggybacking the delegated prefixes in the PBU/PBA ... >> >> This is not the case with PMIP because the LMA is aware of the >> prefixes assigned to the MAGs and during the set up of > > a MAG, the LMA may provide a Router Authorization Certificate linked > to a prefix containing all the future prefixes advertised by this MAG. What happens if a MR handovers to a PMIP domain? In this case, can the LMA know the MNPs that the MR recevies before handover? Thanks for clarification. Sincerely, fan > > Best regards. > > JMC. > >> >> 2008/6/7, Frank Xia : >> >> > Hi Fan >> > >> > Please check my reply... >> > >> > >> > BR >> > Frank >> > >> > ----- Original Message ----- >> > From: "fan zhao" >> > To: "Frank Xia" >> > Cc: "Ryuji Wakikawa" ; "Julien Laganier" >> > ; >> > >> > Sent: Friday, June 06, 2008 5:22 PM >> > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> > >> > >> > > Hi Frank, >> > > >> > > Please see below.. >> > > >> > > On Fri, Jun 6, 2008 at 2:40 PM, Frank Xia wrote: >> > >> Hi Fan >> > >> >> > >> Please see my reply... >> > >> >> > >> BR >> > >> Frank >> > >> >> > >> ----- Original Message ----- From: "fan zhao" >> > >> To: "Frank Xia" >> > >> Cc: "Ryuji Wakikawa" ; "Julien Laganier" >> > >> ; >> > >> Sent: Friday, June 06, 2008 3:33 PM >> > >> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> > >> >> > >> >> > >>> Hi Frank, >> > >>> >> > >>> Please see below. >> > >>> >> > >>> On Fri, Jun 6, 2008 at 10:51 AM, Frank Xia >> > >>> wrote: >> > >>>> >> > >>>> Hi Fan, Ryuji and other colleagues. >> > >>>> >> > >>>> Agreed. >> > >>>> >> > >>>> IMHO,There are two ways for prefix delegation in Nemo, >> > >>>> that is, overlay and integrated modes. >> > >>>> >> > >>>> DHCP based PD is a overlay solution which introduce redundancy >> > >>>> while trying to reduce impact on NEMO itself. >> > >>>> >> > >>>> I favor the integrated mode in which Prefix Delegation is integrated >> > >>>> into >> > >>>> NEMO operations >> > >>> >> > >>> I agree that signaling overhead can be reduced if multiple _related_ >> > >>> requests/responses >> > >>> are piggybacked together, e.g. during one message exchange. For the MR >> > >>> to work, it >> > >>> needs both a HoA/HNP and a MNP. Besides requesting/registering the >> > >>> MNP, there is >> > >>> no much difference between the operation of the MN and that of the MR. >> > >>> Furthermore, >> > >>> the MR can request the MNP during the establishment of IPSec SA when >> > >>> it is at either home link or foreign link. >> > >> >> > >> Frank=>For adressing in NEMO, there are two categories >> > >> nodes for addressing, that is, MRs and hosts behind MRs. >> > >> >> > >> IKE can be used for MR's addressing, while it probabaly >> > >> can't be used for host addressing (PD) without extension of IKE. >> > > >> > > Fan> We can simply define a new attribute carried in the >> > > CFG_REQUEST/CFG_REPLY >> > > configuration payload during the IKE_AUTH exchange. >> > >> > Frank=>It couples PD with IKE procedure. How does the >> > MR renew/release/renumber the prefixes after IKE_AUTH exchange? >> > Anyway, IKE is not solely for MIP, IMHO, it is not proper to >> > extend for this purpose. >> > >> > IMO, the compromised way is to use BA/BU which >> > is in line with PMIP thoughtway. >> > >> > >> > > >> > > >> > >> >> > >>> >> > >>>> because prefix management is an integrated part >> > >>>> of NEMO. >> > >>>> PMIPv6 follow the same philosophy. >> > >>> >> > >>> If I understand correctly, PMIP is a slightly different case from >> > >>> DSMIPv6/NEMO. >> > >>> Because the connection, such as the IPSec SA, between the MAG and the >> > >>> LMA >> > >>> is already in place long before the MN attaches to the MAG, it makes >> > >>> sense >> > >>> for >> > >>> the MAG to request the HNP for the MN during the PBU/PBA exchange. With >> > >>> DSMIPv6, the MN requests the HoA/HNP during the establishment of the >> > >>> IPSec >> > >>> SA, therefore the MR should request the MNP during this procedure as >> > >>> well. >> > >> >> > >> Frank=>It is true there is difference between PMIP and NEMO. >> > >> I just do an analogy. What I want to say is it makes sense if we >> > >> integrate >> > >> PD >> > >> into NEMO. >> > > >> > > Fan> OK. >> > > >> > > Sincerely, >> > > fan >> > > >> > >> >> > >>> >> > >>> What do you think? >> > >>> >> > >>> Sincerely, >> > >>> fan >> > >>> >> > >>>> >> > >>>> BR >> > >>>> Frank >> > >>>> >> > >>>> ----- Original Message ----- From: "fan zhao" >> > >>>> To: "Ryuji Wakikawa" >> > >>>> Cc: "Julien Laganier" ; >> > >>>> Sent: Friday, June 06, 2008 12:18 PM >> > >>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> > >>>> >> > >>>> >> > >>>>> Hi Ryuji and et al, >> > >>>>> >> > >>>>> Sorry for jumping in. >> > >>>>> I agree with Ryuji that the DHCP based PD procedure introduces >> > >>>>> redundancy. >> > >>>>> IMHO, the MR can request a MNP together with a HNP/HoA when >> > >>>>> establishing >> > >>>>> the IPSec SA with the HA. IMO, this is simpler. Do I miss something? >> > >>>>> Thanks. >> > >>>>> >> > >>>>> Sincerely, >> > >>>>> fan >> > >>>>> >> > >>>>> >> > >>>>> On Wed, Jun 4, 2008 at 5:37 PM, Ryuji Wakikawa >> > >>>>> >> > >>>>> wrote: >> > >>>>>> >> > >>>>>> Hello Pascal, >> > >>>>>> >> > >>>>>> Sorry for late response. We have interop event in Tokyo and tested >> > >>>>>> HAHA there;-) >> > >>>>>> >> > >>>>>> On 2008/06/03, at 17:08, Pascal Thubert (pthubert) wrote: >> > >>>>>> >> > >>>>>>> Hi Ryuji: >> > >>>>>>> >> > >>>>>>> I agree that PD should not impact bootstrap. These are and should be >> > >>>>>>> kept unrelated. >> > >>>>>>> >> > >>>>>>> We must be able to extend a RFC 3963 MR with PD without forcing the >> > >>>>>>> bootstrap process in the picture. So I agree not to bring DHAAD back >> > >>>>>>> into the bootstrap... >> > >>>>>> >> > >>>>>> we agree then.. >> > >>>>>> >> > >>>>>>> But I think that PD is NOT a bootstrap process. It is post bootstrap >> > >>>>>>> and >> > >>>>>>> can reoccur many times in the life of the MR. >> > >>>>>>> >> > >>>>>>> Until we define a new process and rev 3775 and 3963, we should stay >> > >>>>>>> consistent and simple in what we are doing. >> > >>>>>> >> > >>>>>> DHCP-PD can surely impact to the bootstrap process. >> > >>>>>> >> > >>>>>> Let's say MR boots up as a MN with RFC5026 first. >> > >>>>>> Then, it tries to get a MNP for NEMO. >> > >>>>>> >> > >>>>>> If the current HA is not PD-enabled and DHAAD returns different HA, >> > >>>>>> MR must de-register the binding from the current HA and tries to >> > >>>>>> start >> > >>>>>> all the registration process to the new HA. >> > >>>>>> >> > >>>>>> This seems very redundant operation.. >> > >>>>>> I want to make the PD spec simple. >> > >>>>>> >> > >>>>>> regards >> > >>>>>> ryuji >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> Pascal >> > >>>>>>> >> > >>>>>>>> -----Original Message----- >> > >>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> > >>>>>>>> Behalf Of >> > >>>>>>> >> > >>>>>>> Ryuji Wakikawa >> > >>>>>>>> >> > >>>>>>>> Sent: mardi 3 juin 2008 09:54 >> > >>>>>>>> To: marcelo bagnulo braun >> > >>>>>>>> Cc: Julien Laganier; mext@ietf.org >> > >>>>>>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> > >>>>>>>> >> > >>>>>>>> Hi Marcelo, >> > >>>>>>>> >> > >>>>>>>> I agree to accept this as WG doc. >> > >>>>>>>> >> > >>>>>>>> I also agree with Romain and Vijay. >> > >>>>>>>> We don't need extension to DHAAD. >> > >>>>>>>> Since MR can act as MN, MR should be able to bootstrap with the >> > >>>>>>>> same >> > >>>>>>>> mechanism of MIP (except for PD). >> > >>>>>>>> We should not bring DHAAD back in the bootstrap process only for >> > >>>>>>>> PD. >> > >>>>>>>> >> > >>>>>>>> regards, >> > >>>>>>>> ryuji >> > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> On 2008/05/30, at 23:51, marcelo bagnulo braun wrote: >> > >>>>>>>> >> > >>>>>>>>> Hi, >> > >>>>>>>>> >> > >>>>>>>>> We would like to ask the WG what is their opinion about accepting >> > >>>>>>>>> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD >> > >>>>>>>>> deliverable included in our charter. >> > >>>>>>>>> >> > >>>>>>>>> Please provide comments so we cna make some progress on this long >> > >>>>>>>>> overdue deliverable >> > >>>>>>>>> >> > >>>>>>>>> thanks, Julien and marcelo >> > >>>>>>>>> -------- Mensaje original -------- >> > >>>>>>>>> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt >> > >>>>>>>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >> > >>>>>>>>> De: Internet-Drafts@ietf.org >> > >>>>>>>>> Responder a: internet-drafts@ietf.org >> > >>>>>>>>> Para: i-d-announce@ietf.org >> > >>>>>>>>> >> > >>>>>>>>> >> > >>>>>>>>> >> > >>>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >> > >>>>>>>>> directories. >> > >>>>>>>>> >> > >>>>>>>>> Title : DHCPv6 Prefix Delegation for NEMO >> > >>>>>>>>> Author(s) : R. Droms, et al. >> > >>>>>>>>> Filename : draft-droms-mext-nemo-pd-00.txt >> > >>>>>>>>> Pages : 12 >> > >>>>>>>>> Date : 2008-05-30 >> > >>>>>>>>> >> > >>>>>>>>> One aspect of network mobility support is the assignment of a >> > >>>>>>>>> prefix >> > >>>>>>>>> or prefixes to a Mobile Router (MR) for use on the links in the >> > >>>>>>>>> Mobile Network. DHCPv6 prefix delegation can be used for this >> > >>>>>>>>> configuration task. >> > >>>>>>>>> >> > >>>>>>>>> A URL for this Internet-Draft is: >> > >>>>>>>>> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt >> > >>>>>>>>> >> > >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >> > >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >> > >>>>>>>>> >> > >>>>>>>>> Below is the data which will enable a MIME compliant mail reader >> > >>>>>>>>> implementation to automatically retrieve the ASCII version of the >> > >>>>>>>>> Internet-Draft. >> > >>>>>>>>> >> > >>>>>>>>> >> > >>>>>>>>> Content-Type: text/plain >> > >>>>>>>>> Content-ID: <2008-05-30054232.I-D@ietf.org> >> > >>>>>>>>> >> > >>>>>>>>> >> > >>>>>>>>> _______________________________________________ >> > >>>>>>>>> I-D-Announce mailing list >> > >>>>>>>>> I-D-Announce@ietf.org >> > >>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >> > >>>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >> > >>>>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > >>>>>>>>> >> > >>>>>>>>> _______________________________________________ >> > >>>>>>>>> MEXT mailing list >> > >>>>>>>>> MEXT@ietf.org >> > >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >> > >>>>>>>> >> > >>>>>>>> _______________________________________________ >> > >>>>>>>> MEXT mailing list >> > >>>>>>>> MEXT@ietf.org >> > >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >> > >>>>>> >> > >>>>>> _______________________________________________ >> > >>>>>> MEXT mailing list >> > >>>>>> MEXT@ietf.org >> > >>>>>> https://www.ietf.org/mailman/listinfo/mext >> > >>>>>> >> > >>>>> _______________________________________________ >> > >>>>> MEXT mailing list >> > >>>>> MEXT@ietf.org >> > >>>>> https://www.ietf.org/mailman/listinfo/mext >> > >>>>> >> > >>>> >> > >>>> >> > >>>> >> > >>> >> > >> >> > >> >> > >> >> > > >> > >> > >> > _______________________________________________ >> > MEXT mailing list >> > MEXT@ietf.org >> > https://www.ietf.org/mailman/listinfo/mext >> > >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 17:13:27 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9DE03A6A29; Fri, 6 Jun 2008 17:13:27 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81ACB3A6A29 for ; Fri, 6 Jun 2008 17:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pq1pHUMkWBfI for ; Fri, 6 Jun 2008 17:13:25 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id F148C3A69FB for ; Fri, 6 Jun 2008 17:13:24 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1471804rvf.49 for ; Fri, 06 Jun 2008 17:13:33 -0700 (PDT) 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=+vdUjGE/qGPskDFHTciO+52R//YomVUBBw8T5tGlK4Q=; b=SGvXl+91qp3i8aqrZXEkx4dTGM3L+GOh/RqFhPkBdaFLG4P8Vakpfefs4XgKNJASTQ Zi+YE1mhDy6G0SLdRQPgLVHc7lBxYFT8itg5b/G6uiLDCRRxVI6+7vkm1i+pAyY3Kl5M VGEmF34fD1gEvUmRgYp9GT/6eCwakmn5YoM+c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=jdJNfiq/8hM9NLnQy5WLQeQkHe5MmdrDH96kRvU7zIMqUj3UZaUc3UUxGvCjgz6mqE k/JVEIdWZ/HU8XDpDZMg74hqavUexRXajVm4Lr5EYGRH72IL6ijiCjFnSYM1Xmgoqp7K VwRL6/I+3syAWMDENOa8cn/TzF5WxW0YI9Qgg= Received: by 10.141.170.10 with SMTP id x10mr454087rvo.139.1212797613552; Fri, 06 Jun 2008 17:13:33 -0700 (PDT) Received: by 10.141.189.15 with HTTP; Fri, 6 Jun 2008 17:13:33 -0700 (PDT) Message-ID: <729b68be0806061713t6dd9498ci2c843ac9abdcba04@mail.gmail.com> Date: Sat, 7 Jun 2008 02:13:33 +0200 From: "Jean-Michel Combes" To: "fan zhao" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <48401470.40706@it.uc3m.es> <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> <006001c8c81d$e5581160$5c0c7c0a@china.huawei.com> <004901c8c825$a9ad9650$5c0c7c0a@china.huawei.com> <729b68be0806061630i7d88afa2w235dad4bafe74daa@mail.gmail.com> <729b68be0806061635y59088fccqa629c3974d4edf97@mail.gmail.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Fan, 2008/6/7, fan zhao : > Hi JMC, > > I have a doubt, please see below. > > > On Fri, Jun 6, 2008 at 4:35 PM, Jean-Michel Combes > wrote: > > Sorry, I forgot to finish my email before to send it :) > > > > 2008/6/7, Jean-Michel Combes : > >> Hi, > >> > >> Don't forget that people may want to deploy SEND and so you will have > >> to provide Router Authorization Certificate too in that case. > >> AFAIK, for the moment, there is no proposal to provide such > >> certificates with PBU/PBA and so you will have another mechanism. The > >> consequence is that you will loose the advantage in time you gained in > >> piggybacking the delegated prefixes in the PBU/PBA ... > >> > >> This is not the case with PMIP because the LMA is aware of the > >> prefixes assigned to the MAGs and during the set up of > > > > a MAG, the LMA may provide a Router Authorization Certificate linked > > to a prefix containing all the future prefixes advertised by this MAG. > > What happens if a MR handovers to a PMIP domain? > In this case, > can the LMA know the MNPs that the MR recevies before handover? AFAIK, the MNPs are already delegated to the MR before the HO (otherwise the MR is not a MR but just a MN :)) and there is no relationship between the MR's MNPs and the prefix delegated to the MAG. Or did I miss your point? Best regards. JMC. > > Thanks for clarification. > > Sincerely, > > fan > > > > > > > > Best regards. > > > > JMC. > > > >> > >> 2008/6/7, Frank Xia : > >> > >> > Hi Fan > >> > > >> > Please check my reply... > >> > > >> > > >> > BR > >> > Frank > >> > > >> > ----- Original Message ----- > >> > From: "fan zhao" > >> > To: "Frank Xia" > >> > Cc: "Ryuji Wakikawa" ; "Julien Laganier" > >> > ; > >> > > >> > Sent: Friday, June 06, 2008 5:22 PM > >> > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > >> > > >> > > >> > > Hi Frank, > >> > > > >> > > Please see below.. > >> > > > >> > > On Fri, Jun 6, 2008 at 2:40 PM, Frank Xia wrote: > >> > >> Hi Fan > >> > >> > >> > >> Please see my reply... > >> > >> > >> > >> BR > >> > >> Frank > >> > >> > >> > >> ----- Original Message ----- From: "fan zhao" > >> > >> To: "Frank Xia" > >> > >> Cc: "Ryuji Wakikawa" ; "Julien Laganier" > >> > >> ; > >> > >> Sent: Friday, June 06, 2008 3:33 PM > >> > >> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > >> > >> > >> > >> > >> > >>> Hi Frank, > >> > >>> > >> > >>> Please see below. > >> > >>> > >> > >>> On Fri, Jun 6, 2008 at 10:51 AM, Frank Xia > >> > >>> wrote: > >> > >>>> > >> > >>>> Hi Fan, Ryuji and other colleagues. > >> > >>>> > >> > >>>> Agreed. > >> > >>>> > >> > >>>> IMHO,There are two ways for prefix delegation in Nemo, > >> > >>>> that is, overlay and integrated modes. > >> > >>>> > >> > >>>> DHCP based PD is a overlay solution which introduce redundancy > >> > >>>> while trying to reduce impact on NEMO itself. > >> > >>>> > >> > >>>> I favor the integrated mode in which Prefix Delegation is integrated > >> > >>>> into > >> > >>>> NEMO operations > >> > >>> > >> > >>> I agree that signaling overhead can be reduced if multiple _related_ > >> > >>> requests/responses > >> > >>> are piggybacked together, e.g. during one message exchange. For the MR > >> > >>> to work, it > >> > >>> needs both a HoA/HNP and a MNP. Besides requesting/registering the > >> > >>> MNP, there is > >> > >>> no much difference between the operation of the MN and that of the MR. > >> > >>> Furthermore, > >> > >>> the MR can request the MNP during the establishment of IPSec SA when > >> > >>> it is at either home link or foreign link. > >> > >> > >> > >> Frank=>For adressing in NEMO, there are two categories > >> > >> nodes for addressing, that is, MRs and hosts behind MRs. > >> > >> > >> > >> IKE can be used for MR's addressing, while it probabaly > >> > >> can't be used for host addressing (PD) without extension of IKE. > >> > > > >> > > Fan> We can simply define a new attribute carried in the > >> > > CFG_REQUEST/CFG_REPLY > >> > > configuration payload during the IKE_AUTH exchange. > >> > > >> > Frank=>It couples PD with IKE procedure. How does the > >> > MR renew/release/renumber the prefixes after IKE_AUTH exchange? > >> > Anyway, IKE is not solely for MIP, IMHO, it is not proper to > >> > extend for this purpose. > >> > > >> > IMO, the compromised way is to use BA/BU which > >> > is in line with PMIP thoughtway. > >> > > >> > > >> > > > >> > > > >> > >> > >> > >>> > >> > >>>> because prefix management is an integrated part > >> > >>>> of NEMO. > >> > >>>> PMIPv6 follow the same philosophy. > >> > >>> > >> > >>> If I understand correctly, PMIP is a slightly different case from > >> > >>> DSMIPv6/NEMO. > >> > >>> Because the connection, such as the IPSec SA, between the MAG and the > >> > >>> LMA > >> > >>> is already in place long before the MN attaches to the MAG, it makes > >> > >>> sense > >> > >>> for > >> > >>> the MAG to request the HNP for the MN during the PBU/PBA exchange. With > >> > >>> DSMIPv6, the MN requests the HoA/HNP during the establishment of the > >> > >>> IPSec > >> > >>> SA, therefore the MR should request the MNP during this procedure as > >> > >>> well. > >> > >> > >> > >> Frank=>It is true there is difference between PMIP and NEMO. > >> > >> I just do an analogy. What I want to say is it makes sense if we > >> > >> integrate > >> > >> PD > >> > >> into NEMO. > >> > > > >> > > Fan> OK. > >> > > > >> > > Sincerely, > >> > > fan > >> > > > >> > >> > >> > >>> > >> > >>> What do you think? > >> > >>> > >> > >>> Sincerely, > >> > >>> fan > >> > >>> > >> > >>>> > >> > >>>> BR > >> > >>>> Frank > >> > >>>> > >> > >>>> ----- Original Message ----- From: "fan zhao" > >> > >>>> To: "Ryuji Wakikawa" > >> > >>>> Cc: "Julien Laganier" ; > >> > >>>> Sent: Friday, June 06, 2008 12:18 PM > >> > >>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > >> > >>>> > >> > >>>> > >> > >>>>> Hi Ryuji and et al, > >> > >>>>> > >> > >>>>> Sorry for jumping in. > >> > >>>>> I agree with Ryuji that the DHCP based PD procedure introduces > >> > >>>>> redundancy. > >> > >>>>> IMHO, the MR can request a MNP together with a HNP/HoA when > >> > >>>>> establishing > >> > >>>>> the IPSec SA with the HA. IMO, this is simpler. Do I miss something? > >> > >>>>> Thanks. > >> > >>>>> > >> > >>>>> Sincerely, > >> > >>>>> fan > >> > >>>>> > >> > >>>>> > >> > >>>>> On Wed, Jun 4, 2008 at 5:37 PM, Ryuji Wakikawa > >> > >>>>> > >> > >>>>> wrote: > >> > >>>>>> > >> > >>>>>> Hello Pascal, > >> > >>>>>> > >> > >>>>>> Sorry for late response. We have interop event in Tokyo and tested > >> > >>>>>> HAHA there;-) > >> > >>>>>> > >> > >>>>>> On 2008/06/03, at 17:08, Pascal Thubert (pthubert) wrote: > >> > >>>>>> > >> > >>>>>>> Hi Ryuji: > >> > >>>>>>> > >> > >>>>>>> I agree that PD should not impact bootstrap. These are and should be > >> > >>>>>>> kept unrelated. > >> > >>>>>>> > >> > >>>>>>> We must be able to extend a RFC 3963 MR with PD without forcing the > >> > >>>>>>> bootstrap process in the picture. So I agree not to bring DHAAD back > >> > >>>>>>> into the bootstrap... > >> > >>>>>> > >> > >>>>>> we agree then.. > >> > >>>>>> > >> > >>>>>>> But I think that PD is NOT a bootstrap process. It is post bootstrap > >> > >>>>>>> and > >> > >>>>>>> can reoccur many times in the life of the MR. > >> > >>>>>>> > >> > >>>>>>> Until we define a new process and rev 3775 and 3963, we should stay > >> > >>>>>>> consistent and simple in what we are doing. > >> > >>>>>> > >> > >>>>>> DHCP-PD can surely impact to the bootstrap process. > >> > >>>>>> > >> > >>>>>> Let's say MR boots up as a MN with RFC5026 first. > >> > >>>>>> Then, it tries to get a MNP for NEMO. > >> > >>>>>> > >> > >>>>>> If the current HA is not PD-enabled and DHAAD returns different HA, > >> > >>>>>> MR must de-register the binding from the current HA and tries to > >> > >>>>>> start > >> > >>>>>> all the registration process to the new HA. > >> > >>>>>> > >> > >>>>>> This seems very redundant operation.. > >> > >>>>>> I want to make the PD spec simple. > >> > >>>>>> > >> > >>>>>> regards > >> > >>>>>> ryuji > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> Pascal > >> > >>>>>>> > >> > >>>>>>>> -----Original Message----- > >> > >>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > >> > >>>>>>>> Behalf Of > >> > >>>>>>> > >> > >>>>>>> Ryuji Wakikawa > >> > >>>>>>>> > >> > >>>>>>>> Sent: mardi 3 juin 2008 09:54 > >> > >>>>>>>> To: marcelo bagnulo braun > >> > >>>>>>>> Cc: Julien Laganier; mext@ietf.org > >> > >>>>>>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > >> > >>>>>>>> > >> > >>>>>>>> Hi Marcelo, > >> > >>>>>>>> > >> > >>>>>>>> I agree to accept this as WG doc. > >> > >>>>>>>> > >> > >>>>>>>> I also agree with Romain and Vijay. > >> > >>>>>>>> We don't need extension to DHAAD. > >> > >>>>>>>> Since MR can act as MN, MR should be able to bootstrap with the > >> > >>>>>>>> same > >> > >>>>>>>> mechanism of MIP (except for PD). > >> > >>>>>>>> We should not bring DHAAD back in the bootstrap process only for > >> > >>>>>>>> PD. > >> > >>>>>>>> > >> > >>>>>>>> regards, > >> > >>>>>>>> ryuji > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> On 2008/05/30, at 23:51, marcelo bagnulo braun wrote: > >> > >>>>>>>> > >> > >>>>>>>>> Hi, > >> > >>>>>>>>> > >> > >>>>>>>>> We would like to ask the WG what is their opinion about accepting > >> > >>>>>>>>> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD > >> > >>>>>>>>> deliverable included in our charter. > >> > >>>>>>>>> > >> > >>>>>>>>> Please provide comments so we cna make some progress on this long > >> > >>>>>>>>> overdue deliverable > >> > >>>>>>>>> > >> > >>>>>>>>> thanks, Julien and marcelo > >> > >>>>>>>>> -------- Mensaje original -------- > >> > >>>>>>>>> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt > >> > >>>>>>>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) > >> > >>>>>>>>> De: Internet-Drafts@ietf.org > >> > >>>>>>>>> Responder a: internet-drafts@ietf.org > >> > >>>>>>>>> Para: i-d-announce@ietf.org > >> > >>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts > >> > >>>>>>>>> directories. > >> > >>>>>>>>> > >> > >>>>>>>>> Title : DHCPv6 Prefix Delegation for NEMO > >> > >>>>>>>>> Author(s) : R. Droms, et al. > >> > >>>>>>>>> Filename : draft-droms-mext-nemo-pd-00.txt > >> > >>>>>>>>> Pages : 12 > >> > >>>>>>>>> Date : 2008-05-30 > >> > >>>>>>>>> > >> > >>>>>>>>> One aspect of network mobility support is the assignment of a > >> > >>>>>>>>> prefix > >> > >>>>>>>>> or prefixes to a Mobile Router (MR) for use on the links in the > >> > >>>>>>>>> Mobile Network. DHCPv6 prefix delegation can be used for this > >> > >>>>>>>>> configuration task. > >> > >>>>>>>>> > >> > >>>>>>>>> A URL for this Internet-Draft is: > >> > >>>>>>>>> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt > >> > >>>>>>>>> > >> > >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: > >> > >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ > >> > >>>>>>>>> > >> > >>>>>>>>> Below is the data which will enable a MIME compliant mail reader > >> > >>>>>>>>> implementation to automatically retrieve the ASCII version of the > >> > >>>>>>>>> Internet-Draft. > >> > >>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>>> Content-Type: text/plain > >> > >>>>>>>>> Content-ID: <2008-05-30054232.I-D@ietf.org> > >> > >>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>>> _______________________________________________ > >> > >>>>>>>>> I-D-Announce mailing list > >> > >>>>>>>>> I-D-Announce@ietf.org > >> > >>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce > >> > >>>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html > >> > >>>>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >>>>>>>>> > >> > >>>>>>>>> _______________________________________________ > >> > >>>>>>>>> MEXT mailing list > >> > >>>>>>>>> MEXT@ietf.org > >> > >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext > >> > >>>>>>>> > >> > >>>>>>>> _______________________________________________ > >> > >>>>>>>> MEXT mailing list > >> > >>>>>>>> MEXT@ietf.org > >> > >>>>>>>> https://www.ietf.org/mailman/listinfo/mext > >> > >>>>>> > >> > >>>>>> _______________________________________________ > >> > >>>>>> MEXT mailing list > >> > >>>>>> MEXT@ietf.org > >> > >>>>>> https://www.ietf.org/mailman/listinfo/mext > >> > >>>>>> > >> > >>>>> _______________________________________________ > >> > >>>>> MEXT mailing list > >> > >>>>> MEXT@ietf.org > >> > >>>>> https://www.ietf.org/mailman/listinfo/mext > >> > >>>>> > >> > >>>> > >> > >>>> > >> > >>>> > >> > >>> > >> > >> > >> > >> > >> > >> > >> > > > >> > > >> > > >> > _______________________________________________ > >> > MEXT mailing list > >> > MEXT@ietf.org > >> > https://www.ietf.org/mailman/listinfo/mext > >> > > >> > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 6 17:25:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA273A6945; Fri, 6 Jun 2008 17:25:39 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E7803A6911 for ; Fri, 6 Jun 2008 17:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0TMk7gWXmI4 for ; Fri, 6 Jun 2008 17:25:36 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by core3.amsl.com (Postfix) with ESMTP id 6772E3A692D for ; Fri, 6 Jun 2008 17:25:36 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so537865and.122 for ; Fri, 06 Jun 2008 17:25:43 -0700 (PDT) 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=tyA9xI/2d7VCvTYSMagvgnwMWrBTNZBuSG+YNlRRDJo=; b=KqxEE+n2S46snpH2F57xFXOfPIr7noYC1xlydMDb9zGdKc560jEVvWIMMVqcFEaw2R kRCkF+ifuif+dhJMBT26zavjLJtzTgbfgwd9RP1u6kJ5rFja5rRUoLeCe2TYwy2ANhRB EdWGKcPfR0KlwszYbAR1fN2CBblq3QAA/cDl8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=jhRQwqipD63ywdJ6AaSoaKZMrm/O7qAERNcjLUV9ud82cPMIoDyC5sPOdAGZcCPzHU E9dDmHSx5pxXxdzVYDFKIO2Lg/m9OcrnkPKICdjgEObIAaXyChPyXyRQDnJwjd+mM2P8 XMnhfGiXAQK6TL4fwOoiApZKJvQAFM+IFTNuM= Received: by 10.101.67.15 with SMTP id u15mr1033306ank.90.1212798343123; Fri, 06 Jun 2008 17:25:43 -0700 (PDT) Received: by 10.100.141.11 with HTTP; Fri, 6 Jun 2008 17:25:42 -0700 (PDT) Message-ID: Date: Fri, 6 Jun 2008 17:25:42 -0700 From: "fan zhao" To: "Jean-Michel Combes" In-Reply-To: <729b68be0806061713t6dd9498ci2c843ac9abdcba04@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <48401470.40706@it.uc3m.es> <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> <006001c8c81d$e5581160$5c0c7c0a@china.huawei.com> <004901c8c825$a9ad9650$5c0c7c0a@china.huawei.com> <729b68be0806061630i7d88afa2w235dad4bafe74daa@mail.gmail.com> <729b68be0806061635y59088fccqa629c3974d4edf97@mail.gmail.com> <729b68be0806061713t6dd9498ci2c843ac9abdcba04@mail.gmail.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Jean-Michel, OK, I think I have to check the CSI. :-) Thanks for raising this interesting point. BR, fan On Fri, Jun 6, 2008 at 5:13 PM, Jean-Michel Combes wrote: > Hi Fan, > > 2008/6/7, fan zhao : >> Hi JMC, >> >> I have a doubt, please see below. >> >> >> On Fri, Jun 6, 2008 at 4:35 PM, Jean-Michel Combes >> wrote: >> > Sorry, I forgot to finish my email before to send it :) >> > >> > 2008/6/7, Jean-Michel Combes : >> >> Hi, >> >> >> >> Don't forget that people may want to deploy SEND and so you will have >> >> to provide Router Authorization Certificate too in that case. >> >> AFAIK, for the moment, there is no proposal to provide such >> >> certificates with PBU/PBA and so you will have another mechanism. The >> >> consequence is that you will loose the advantage in time you gained in >> >> piggybacking the delegated prefixes in the PBU/PBA ... >> >> >> >> This is not the case with PMIP because the LMA is aware of the >> >> prefixes assigned to the MAGs and during the set up of >> > >> > a MAG, the LMA may provide a Router Authorization Certificate linked >> > to a prefix containing all the future prefixes advertised by this MAG. >> >> What happens if a MR handovers to a PMIP domain? >> In this case, >> can the LMA know the MNPs that the MR recevies before handover? > > AFAIK, the MNPs are already delegated to the MR before the HO > (otherwise the MR is not a MR but just a MN :)) and there is no > relationship between the MR's MNPs and the prefix delegated to the > MAG. > > Or did I miss your point? > > Best regards. > > JMC. > >> >> Thanks for clarification. >> >> Sincerely, >> >> fan >> >> >> >> >> > >> > Best regards. >> > >> > JMC. >> > >> >> >> >> 2008/6/7, Frank Xia : >> >> >> >> > Hi Fan >> >> > >> >> > Please check my reply... >> >> > >> >> > >> >> > BR >> >> > Frank >> >> > >> >> > ----- Original Message ----- >> >> > From: "fan zhao" >> >> > To: "Frank Xia" >> >> > Cc: "Ryuji Wakikawa" ; "Julien Laganier" >> >> > ; >> >> > >> >> > Sent: Friday, June 06, 2008 5:22 PM >> >> > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> >> > >> >> > >> >> > > Hi Frank, >> >> > > >> >> > > Please see below.. >> >> > > >> >> > > On Fri, Jun 6, 2008 at 2:40 PM, Frank Xia wrote: >> >> > >> Hi Fan >> >> > >> >> >> > >> Please see my reply... >> >> > >> >> >> > >> BR >> >> > >> Frank >> >> > >> >> >> > >> ----- Original Message ----- From: "fan zhao" >> >> > >> To: "Frank Xia" >> >> > >> Cc: "Ryuji Wakikawa" ; "Julien Laganier" >> >> > >> ; >> >> > >> Sent: Friday, June 06, 2008 3:33 PM >> >> > >> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> >> > >> >> >> > >> >> >> > >>> Hi Frank, >> >> > >>> >> >> > >>> Please see below. >> >> > >>> >> >> > >>> On Fri, Jun 6, 2008 at 10:51 AM, Frank Xia >> >> > >>> wrote: >> >> > >>>> >> >> > >>>> Hi Fan, Ryuji and other colleagues. >> >> > >>>> >> >> > >>>> Agreed. >> >> > >>>> >> >> > >>>> IMHO,There are two ways for prefix delegation in Nemo, >> >> > >>>> that is, overlay and integrated modes. >> >> > >>>> >> >> > >>>> DHCP based PD is a overlay solution which introduce redundancy >> >> > >>>> while trying to reduce impact on NEMO itself. >> >> > >>>> >> >> > >>>> I favor the integrated mode in which Prefix Delegation is integrated >> >> > >>>> into >> >> > >>>> NEMO operations >> >> > >>> >> >> > >>> I agree that signaling overhead can be reduced if multiple _related_ >> >> > >>> requests/responses >> >> > >>> are piggybacked together, e.g. during one message exchange. For the MR >> >> > >>> to work, it >> >> > >>> needs both a HoA/HNP and a MNP. Besides requesting/registering the >> >> > >>> MNP, there is >> >> > >>> no much difference between the operation of the MN and that of the MR. >> >> > >>> Furthermore, >> >> > >>> the MR can request the MNP during the establishment of IPSec SA when >> >> > >>> it is at either home link or foreign link. >> >> > >> >> >> > >> Frank=>For adressing in NEMO, there are two categories >> >> > >> nodes for addressing, that is, MRs and hosts behind MRs. >> >> > >> >> >> > >> IKE can be used for MR's addressing, while it probabaly >> >> > >> can't be used for host addressing (PD) without extension of IKE. >> >> > > >> >> > > Fan> We can simply define a new attribute carried in the >> >> > > CFG_REQUEST/CFG_REPLY >> >> > > configuration payload during the IKE_AUTH exchange. >> >> > >> >> > Frank=>It couples PD with IKE procedure. How does the >> >> > MR renew/release/renumber the prefixes after IKE_AUTH exchange? >> >> > Anyway, IKE is not solely for MIP, IMHO, it is not proper to >> >> > extend for this purpose. >> >> > >> >> > IMO, the compromised way is to use BA/BU which >> >> > is in line with PMIP thoughtway. >> >> > >> >> > >> >> > > >> >> > > >> >> > >> >> >> > >>> >> >> > >>>> because prefix management is an integrated part >> >> > >>>> of NEMO. >> >> > >>>> PMIPv6 follow the same philosophy. >> >> > >>> >> >> > >>> If I understand correctly, PMIP is a slightly different case from >> >> > >>> DSMIPv6/NEMO. >> >> > >>> Because the connection, such as the IPSec SA, between the MAG and the >> >> > >>> LMA >> >> > >>> is already in place long before the MN attaches to the MAG, it makes >> >> > >>> sense >> >> > >>> for >> >> > >>> the MAG to request the HNP for the MN during the PBU/PBA exchange. With >> >> > >>> DSMIPv6, the MN requests the HoA/HNP during the establishment of the >> >> > >>> IPSec >> >> > >>> SA, therefore the MR should request the MNP during this procedure as >> >> > >>> well. >> >> > >> >> >> > >> Frank=>It is true there is difference between PMIP and NEMO. >> >> > >> I just do an analogy. What I want to say is it makes sense if we >> >> > >> integrate >> >> > >> PD >> >> > >> into NEMO. >> >> > > >> >> > > Fan> OK. >> >> > > >> >> > > Sincerely, >> >> > > fan >> >> > > >> >> > >> >> >> > >>> >> >> > >>> What do you think? >> >> > >>> >> >> > >>> Sincerely, >> >> > >>> fan >> >> > >>> >> >> > >>>> >> >> > >>>> BR >> >> > >>>> Frank >> >> > >>>> >> >> > >>>> ----- Original Message ----- From: "fan zhao" >> >> > >>>> To: "Ryuji Wakikawa" >> >> > >>>> Cc: "Julien Laganier" ; >> >> > >>>> Sent: Friday, June 06, 2008 12:18 PM >> >> > >>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> >> > >>>> >> >> > >>>> >> >> > >>>>> Hi Ryuji and et al, >> >> > >>>>> >> >> > >>>>> Sorry for jumping in. >> >> > >>>>> I agree with Ryuji that the DHCP based PD procedure introduces >> >> > >>>>> redundancy. >> >> > >>>>> IMHO, the MR can request a MNP together with a HNP/HoA when >> >> > >>>>> establishing >> >> > >>>>> the IPSec SA with the HA. IMO, this is simpler. Do I miss something? >> >> > >>>>> Thanks. >> >> > >>>>> >> >> > >>>>> Sincerely, >> >> > >>>>> fan >> >> > >>>>> >> >> > >>>>> >> >> > >>>>> On Wed, Jun 4, 2008 at 5:37 PM, Ryuji Wakikawa >> >> > >>>>> >> >> > >>>>> wrote: >> >> > >>>>>> >> >> > >>>>>> Hello Pascal, >> >> > >>>>>> >> >> > >>>>>> Sorry for late response. We have interop event in Tokyo and tested >> >> > >>>>>> HAHA there;-) >> >> > >>>>>> >> >> > >>>>>> On 2008/06/03, at 17:08, Pascal Thubert (pthubert) wrote: >> >> > >>>>>> >> >> > >>>>>>> Hi Ryuji: >> >> > >>>>>>> >> >> > >>>>>>> I agree that PD should not impact bootstrap. These are and should be >> >> > >>>>>>> kept unrelated. >> >> > >>>>>>> >> >> > >>>>>>> We must be able to extend a RFC 3963 MR with PD without forcing the >> >> > >>>>>>> bootstrap process in the picture. So I agree not to bring DHAAD back >> >> > >>>>>>> into the bootstrap... >> >> > >>>>>> >> >> > >>>>>> we agree then.. >> >> > >>>>>> >> >> > >>>>>>> But I think that PD is NOT a bootstrap process. It is post bootstrap >> >> > >>>>>>> and >> >> > >>>>>>> can reoccur many times in the life of the MR. >> >> > >>>>>>> >> >> > >>>>>>> Until we define a new process and rev 3775 and 3963, we should stay >> >> > >>>>>>> consistent and simple in what we are doing. >> >> > >>>>>> >> >> > >>>>>> DHCP-PD can surely impact to the bootstrap process. >> >> > >>>>>> >> >> > >>>>>> Let's say MR boots up as a MN with RFC5026 first. >> >> > >>>>>> Then, it tries to get a MNP for NEMO. >> >> > >>>>>> >> >> > >>>>>> If the current HA is not PD-enabled and DHAAD returns different HA, >> >> > >>>>>> MR must de-register the binding from the current HA and tries to >> >> > >>>>>> start >> >> > >>>>>> all the registration process to the new HA. >> >> > >>>>>> >> >> > >>>>>> This seems very redundant operation.. >> >> > >>>>>> I want to make the PD spec simple. >> >> > >>>>>> >> >> > >>>>>> regards >> >> > >>>>>> ryuji >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>>> >> >> > >>>>>>> >> >> > >>>>>>> Pascal >> >> > >>>>>>> >> >> > >>>>>>>> -----Original Message----- >> >> > >>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> >> > >>>>>>>> Behalf Of >> >> > >>>>>>> >> >> > >>>>>>> Ryuji Wakikawa >> >> > >>>>>>>> >> >> > >>>>>>>> Sent: mardi 3 juin 2008 09:54 >> >> > >>>>>>>> To: marcelo bagnulo braun >> >> > >>>>>>>> Cc: Julien Laganier; mext@ietf.org >> >> > >>>>>>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> >> > >>>>>>>> >> >> > >>>>>>>> Hi Marcelo, >> >> > >>>>>>>> >> >> > >>>>>>>> I agree to accept this as WG doc. >> >> > >>>>>>>> >> >> > >>>>>>>> I also agree with Romain and Vijay. >> >> > >>>>>>>> We don't need extension to DHAAD. >> >> > >>>>>>>> Since MR can act as MN, MR should be able to bootstrap with the >> >> > >>>>>>>> same >> >> > >>>>>>>> mechanism of MIP (except for PD). >> >> > >>>>>>>> We should not bring DHAAD back in the bootstrap process only for >> >> > >>>>>>>> PD. >> >> > >>>>>>>> >> >> > >>>>>>>> regards, >> >> > >>>>>>>> ryuji >> >> > >>>>>>>> >> >> > >>>>>>>> >> >> > >>>>>>>> On 2008/05/30, at 23:51, marcelo bagnulo braun wrote: >> >> > >>>>>>>> >> >> > >>>>>>>>> Hi, >> >> > >>>>>>>>> >> >> > >>>>>>>>> We would like to ask the WG what is their opinion about accepting >> >> > >>>>>>>>> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD >> >> > >>>>>>>>> deliverable included in our charter. >> >> > >>>>>>>>> >> >> > >>>>>>>>> Please provide comments so we cna make some progress on this long >> >> > >>>>>>>>> overdue deliverable >> >> > >>>>>>>>> >> >> > >>>>>>>>> thanks, Julien and marcelo >> >> > >>>>>>>>> -------- Mensaje original -------- >> >> > >>>>>>>>> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt >> >> > >>>>>>>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >> >> > >>>>>>>>> De: Internet-Drafts@ietf.org >> >> > >>>>>>>>> Responder a: internet-drafts@ietf.org >> >> > >>>>>>>>> Para: i-d-announce@ietf.org >> >> > >>>>>>>>> >> >> > >>>>>>>>> >> >> > >>>>>>>>> >> >> > >>>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >> >> > >>>>>>>>> directories. >> >> > >>>>>>>>> >> >> > >>>>>>>>> Title : DHCPv6 Prefix Delegation for NEMO >> >> > >>>>>>>>> Author(s) : R. Droms, et al. >> >> > >>>>>>>>> Filename : draft-droms-mext-nemo-pd-00.txt >> >> > >>>>>>>>> Pages : 12 >> >> > >>>>>>>>> Date : 2008-05-30 >> >> > >>>>>>>>> >> >> > >>>>>>>>> One aspect of network mobility support is the assignment of a >> >> > >>>>>>>>> prefix >> >> > >>>>>>>>> or prefixes to a Mobile Router (MR) for use on the links in the >> >> > >>>>>>>>> Mobile Network. DHCPv6 prefix delegation can be used for this >> >> > >>>>>>>>> configuration task. >> >> > >>>>>>>>> >> >> > >>>>>>>>> A URL for this Internet-Draft is: >> >> > >>>>>>>>> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt >> >> > >>>>>>>>> >> >> > >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >> >> > >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >> >> > >>>>>>>>> >> >> > >>>>>>>>> Below is the data which will enable a MIME compliant mail reader >> >> > >>>>>>>>> implementation to automatically retrieve the ASCII version of the >> >> > >>>>>>>>> Internet-Draft. >> >> > >>>>>>>>> >> >> > >>>>>>>>> >> >> > >>>>>>>>> Content-Type: text/plain >> >> > >>>>>>>>> Content-ID: <2008-05-30054232.I-D@ietf.org> >> >> > >>>>>>>>> >> >> > >>>>>>>>> >> >> > >>>>>>>>> _______________________________________________ >> >> > >>>>>>>>> I-D-Announce mailing list >> >> > >>>>>>>>> I-D-Announce@ietf.org >> >> > >>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >> >> > >>>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >> >> > >>>>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> > >>>>>>>>> >> >> > >>>>>>>>> _______________________________________________ >> >> > >>>>>>>>> MEXT mailing list >> >> > >>>>>>>>> MEXT@ietf.org >> >> > >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >> >> > >>>>>>>> >> >> > >>>>>>>> _______________________________________________ >> >> > >>>>>>>> MEXT mailing list >> >> > >>>>>>>> MEXT@ietf.org >> >> > >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >> >> > >>>>>> >> >> > >>>>>> _______________________________________________ >> >> > >>>>>> MEXT mailing list >> >> > >>>>>> MEXT@ietf.org >> >> > >>>>>> https://www.ietf.org/mailman/listinfo/mext >> >> > >>>>>> >> >> > >>>>> _______________________________________________ >> >> > >>>>> MEXT mailing list >> >> > >>>>> MEXT@ietf.org >> >> > >>>>> https://www.ietf.org/mailman/listinfo/mext >> >> > >>>>> >> >> > >>>> >> >> > >>>> >> >> > >>>> >> >> > >>> >> >> > >> >> >> > >> >> >> > >> >> >> > > >> >> > >> >> > >> >> > _______________________________________________ >> >> > MEXT mailing list >> >> > MEXT@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/mext >> >> > >> >> >> > >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From c.tsui@mizunami.com.tw Fri Jun 6 19:56:01 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3F863A67EC; Fri, 6 Jun 2008 19:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -80.468 X-Spam-Level: X-Spam-Status: No, score=-80.468 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, SARE_SPEC_REPLICA_OBFU=1.812, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vf50Alg1m3cB; Fri, 6 Jun 2008 19:56:00 -0700 (PDT) Received: from 190-50-122-122.speedy.com.ar (unknown [190.50.122.122]) by core3.amsl.com (Postfix) with SMTP id 37D2E3A677E; Fri, 6 Jun 2008 19:55:47 -0700 (PDT) X-Originating-IP: 250.158.86.24 by smtp.190.50.122.122; Fri, 06 Jun 2008 22:55:59 -0500 Message-ID: From: "Alton Wyatt" Reply-To: "Alton Wyatt" To: nemo-archive@ietf.org Subject: Inexpensive IWC watches Date: Fri, 06 Jun 2008 22:55:59 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://tipiwuxibun72.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://tipiwuxibun72.blogspot.com/ From ngo-bounces@ietf.org Fri Jun 6 19:56:03 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56F6C3A69E3 for ; Fri, 6 Jun 2008 19:56:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NGO awaits moderator approval From: ngo-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 19:56:02 -0700 Precedence: bulk X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF X-List-Administrivia: yes Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Your mail to 'NGO' with the subject Inexpensive IWC watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ngo/7a68587bb5e8a15c353b79023df72b51a8e414e7 From netconf-bounces@ietf.org Fri Jun 6 19:56:03 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0BB3A69E3 for ; Fri, 6 Jun 2008 19:56:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to Netconf awaits moderator approval From: netconf-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 19:56:02 -0700 Precedence: bulk X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 List-Id: Network Configuration WG mailing list X-List-Administrivia: yes Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Your mail to 'Netconf' with the subject Inexpensive IWC watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netconf/3bfcbf737deb3849e4b053f2ea982f47bc1db224 From nsis-imp-bounces@ietf.org Fri Jun 6 19:56:03 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E1C3A69E3 for ; Fri, 6 Jun 2008 19:56:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NSIS-imp awaits moderator approval From: nsis-imp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 19:56:02 -0700 Precedence: bulk X-BeenThere: nsis-imp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for implementation questions for NSIS protocols X-List-Administrivia: yes Sender: nsis-imp-bounces@ietf.org Errors-To: nsis-imp-bounces@ietf.org Your mail to 'NSIS-imp' with the subject Inexpensive IWC watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis-imp/a5044555359fc8d87129fb5b7f8ec6bc5dcd0907 From nfsv4-bounces@ietf.org Fri Jun 6 19:56:03 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC443A69E3 for ; Fri, 6 Jun 2008 19:56:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nfsv4 awaits moderator approval From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 19:56:02 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org Your mail to 'nfsv4' with the subject Inexpensive IWC watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nfsv4/8cabdaa6910d510cd78bcac0239e11ba24bded05 From nsis-bounces@ietf.org Fri Jun 6 19:56:03 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7428E3A69E3 for ; Fri, 6 Jun 2008 19:56:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nsis awaits moderator approval From: nsis-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 19:56:02 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Your mail to 'nsis' with the subject Inexpensive IWC watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis/4e5dc6656478c49d3682fa624b25a28d6d0e67ac From nemo-bounces@ietf.org Fri Jun 6 19:56:03 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7867D3A69E3 for ; Fri, 6 Jun 2008 19:56:03 -0700 (PDT) Subject: The results of your email commands From: nemo-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0030845471==" Message-ID: Date: Fri, 06 Jun 2008 19:56:02 -0700 Precedence: bulk X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NEMO Working Group X-List-Administrivia: yes Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --===============0030845471== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://tipiwuxibun72.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://tipiwuxibun72.blogspot.com/ - Done. --===============0030845471== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nemo-request@core3.amsl.com Delivered-To: nemo-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3F863A67EC; Fri, 6 Jun 2008 19:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -80.468 X-Spam-Level: X-Spam-Status: No, score=-80.468 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, SARE_SPEC_REPLICA_OBFU=1.812, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vf50Alg1m3cB; Fri, 6 Jun 2008 19:56:00 -0700 (PDT) Received: from 190-50-122-122.speedy.com.ar (unknown [190.50.122.122]) by core3.amsl.com (Postfix) with SMTP id 37D2E3A677E; Fri, 6 Jun 2008 19:55:47 -0700 (PDT) X-Originating-IP: 250.158.86.24 by smtp.190.50.122.122; Fri, 06 Jun 2008 22:55:59 -0500 Message-ID: From: "Alton Wyatt" Reply-To: "Alton Wyatt" To: nemo-archive@ietf.org Subject: Inexpensive IWC watches Date: Fri, 06 Jun 2008 22:55:59 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://tipiwuxibun72.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://tipiwuxibun72.blogspot.com/ --===============0030845471==-- From nsis-bounces@ietf.org Fri Jun 6 19:56:03 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B0103A69F5 for ; Fri, 6 Jun 2008 19:56:03 -0700 (PDT) Subject: The results of your email commands From: nsis-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1799410337==" Message-ID: Date: Fri, 06 Jun 2008 19:56:02 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============1799410337== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://tipiwuxibun72.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://tipiwuxibun72.blogspot.com/ - Done. --===============1799410337== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nsis-request@core3.amsl.com Delivered-To: nsis-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3F863A67EC; Fri, 6 Jun 2008 19:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -80.468 X-Spam-Level: X-Spam-Status: No, score=-80.468 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, SARE_SPEC_REPLICA_OBFU=1.812, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vf50Alg1m3cB; Fri, 6 Jun 2008 19:56:00 -0700 (PDT) Received: from 190-50-122-122.speedy.com.ar (unknown [190.50.122.122]) by core3.amsl.com (Postfix) with SMTP id 37D2E3A677E; Fri, 6 Jun 2008 19:55:47 -0700 (PDT) X-Originating-IP: 250.158.86.24 by smtp.190.50.122.122; Fri, 06 Jun 2008 22:55:59 -0500 Message-ID: From: "Alton Wyatt" Reply-To: "Alton Wyatt" To: nemo-archive@ietf.org Subject: Inexpensive IWC watches Date: Fri, 06 Jun 2008 22:55:59 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://tipiwuxibun72.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://tipiwuxibun72.blogspot.com/ --===============1799410337==-- From nfsv4-bounces@ietf.org Fri Jun 6 19:56:03 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81D513A69E3 for ; Fri, 6 Jun 2008 19:56:03 -0700 (PDT) Subject: The results of your email commands From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2096750868==" Message-ID: Date: Fri, 06 Jun 2008 19:56:02 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org --===============2096750868== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://tipiwuxibun72.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://tipiwuxibun72.blogspot.com/ - Done. --===============2096750868== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nfsv4-request@core3.amsl.com Delivered-To: nfsv4-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3F863A67EC; Fri, 6 Jun 2008 19:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -80.468 X-Spam-Level: X-Spam-Status: No, score=-80.468 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, SARE_SPEC_REPLICA_OBFU=1.812, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vf50Alg1m3cB; Fri, 6 Jun 2008 19:56:00 -0700 (PDT) Received: from 190-50-122-122.speedy.com.ar (unknown [190.50.122.122]) by core3.amsl.com (Postfix) with SMTP id 37D2E3A677E; Fri, 6 Jun 2008 19:55:47 -0700 (PDT) X-Originating-IP: 250.158.86.24 by smtp.190.50.122.122; Fri, 06 Jun 2008 22:55:59 -0500 Message-ID: From: "Alton Wyatt" Reply-To: "Alton Wyatt" To: nemo-archive@ietf.org Subject: Inexpensive IWC watches Date: Fri, 06 Jun 2008 22:55:59 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://tipiwuxibun72.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://tipiwuxibun72.blogspot.com/ --===============2096750868==-- From netlmm-bounces@ietf.org Fri Jun 6 19:56:03 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84BC73A69E3 for ; Fri, 6 Jun 2008 19:56:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to netlmm awaits moderator approval From: netlmm-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 19:56:02 -0700 Precedence: bulk X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETLMM working group discussion list X-List-Administrivia: yes Sender: netlmm-bounces@ietf.org Errors-To: netlmm-bounces@ietf.org Your mail to 'netlmm' with the subject Inexpensive IWC watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netlmm/3c2a3cc236f21154309feb166c0f05fdefd327a6 From ntdp-bounces@ietf.org Fri Jun 6 19:56:03 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A8773A69E3 for ; Fri, 6 Jun 2008 19:56:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NTDP awaits moderator approval From: ntdp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 06 Jun 2008 19:56:02 -0700 Precedence: bulk X-BeenThere: ntdp@ietf.org X-Mailman-Version: 2.1.9 List-Id: define standards for the purpose of scripting of network testing equipment X-List-Administrivia: yes Sender: ntdp-bounces@ietf.org Errors-To: ntdp-bounces@ietf.org Your mail to 'NTDP' with the subject Inexpensive IWC watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ntdp/a1dc4d7b730b61bb57b9712b343ac2d7d55a6a3b From mext-bounces@ietf.org Sun Jun 8 05:21:13 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297AD3A6B96; Sun, 8 Jun 2008 05:21:13 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA3673A6BAC for ; Sun, 8 Jun 2008 05:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.303 X-Spam-Level: X-Spam-Status: No, score=-1.303 tagged_above=-999 required=5 tests=[AWL=1.297, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHiv7pcA23DW for ; Sun, 8 Jun 2008 05:21:10 -0700 (PDT) Received: from moog.chdir.org (unknown [IPv6:2002:58bf:2aa0:339b:f654:e10e:317f:e6fa]) by core3.amsl.com (Postfix) with ESMTP id 6F33B3A6B85 for ; Sun, 8 Jun 2008 05:21:09 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1K5Jtg-0008Vy-Fv; Sun, 08 Jun 2008 14:21:20 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Julien Laganier In-Reply-To: <200806061349.32192.julien.IETF@laposte.net> (Julien Laganier's message of "Fri, 6 Jun 2008 13:49:30 +0200") References: <200806050918.05372.julien.IETF@laposte.net> <200806061144.23200.julien.IETF@laposte.net> <20080606100743.GA12803@sd-5945.dedibox.fr> <200806061349.32192.julien.IETF@laposte.net> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.2 (gnu/linux) X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080608:mext@ietf.org::xnRBhLKuoOcI9MaU:000022Q4 X-Hashcash: 1:20:080608:julien.ietf@laposte.net::YXFxSPQjaHyMYxUd:000000000000000000000000000000000000004CDU Date: Sun, 08 Jun 2008 14:21:18 +0200 Message-ID: <878wxgungh.fsf@natisbad.org> MIME-Version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] [rfc3775] Application using the care-of address X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1644106856==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1644106856== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Hi Julien and sorry for the latency, Julien Laganier writes: >> > RFC5014 allows a sending process to express to the IP stack its >> > preference for a CoA to be selected as source address in outbound >> > packets, and then allows the process to verify that the selected >> > source address is indeed a CoA: >> > >> > ... snip ... >> >> I think you miss the point.=20 > > I guess I do... With 5014, you can manage to get a socket that will use a CoA as source address (with the ability to verify it is indeed a CoA). For common applications, I imagine that this is just fine because they simply do not care about the address itself but simply want to use a CoA and delegate the address decision to the system. For the interaction between MIPv6 and IPsec/IKE, a more direct path is needed (IMHO, other developers that have spent time on the code should comment) at various moments where the MIPv6 process must influence the IPsec stack and the IKE daemon in a very specific way:=20 =2D Bootstrapping (handling of transport mode SA by IKE) =2D Update of in-kernel SP/SA on movement =2D Update of IKE-daemon mirrored SP/SA on movement =2D Update of IKE_SA endpoints on movements =2D ... I think that in the specific case of bootstrapping, it would be possible to specifically mark the SP (or SA information to be negotiated, even if it would introduce a daemon/system specific issue in some way) for the IKE daemon to use a CoA. From your previous code samples, I think that the IKE daemon will manage to get a socket using a CoA as source, retrieve this CoA and consider it the expected source address to use for the negotiation of the IKE_SA (the socket is directly usable but the @ is certainly needed for internal tasks). After scratching my head, I think what you propose could take off, but probably won't fly well or at all. An IKE daemon differs from a common app regarding handling of adresses: it has to be very careful and handle things at a somewhat lower level than a common app. I also have some questions (don't hesitate to reply with pointers if it is documented) associated with your expected use of 5014 for MIPv6 bootstrapping by IKE: what happens when there are multiple addresses on the system (for instance a native, an ULA and a 6to4 address). What is their status? all CoA? The MIPv6 process will choose one specific address for the binding with its HoA (source of the BU when it leaves the MN) based on specific internal policies. What gives the insurance that this address will be the one that the IKE daemon will use if it implements 5014 for bootstrapping? To continue on that path, do you see a simple way for the IKE daemon to update its IKE_SA endpoints on movement with a new CoA (item 4 in my previous list)? How will it be warned to do the change? What are the expected actions to be taken?=20 Because a decision has already been taken on the interest of some work on such a mechanism by the WG, I should probably keep the following additional question for me: what about items 2 and 3? In the end, it is obvious that a MIPv6 process needs to interact with IPsec/IKE. I'd like to be proven false by some implementations (MIPv6, IKE, IPsec stack) that could use what is currently on the table (normalized documents, i.e. RFC) to provide something that works. Cheers, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIS86+AlWVfAR6UCYRAim9AJ9pQBM6xys/f4GmGOjxclD+h7jyEgCfSLev IJEOVhODb1uHSeHUH8QbfE0= =gTPz -----END PGP SIGNATURE----- --=-=-=-- --===============1644106856== 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://www.ietf.org/mailman/listinfo/mext --===============1644106856==-- From cabene@bradfordconstruction.com Sun Jun 8 08:23:47 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4E013A6B2D; Sun, 8 Jun 2008 08:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -54.172 X-Spam-Level: X-Spam-Status: No, score=-54.172 tagged_above=-999 required=5 tests=[BAYES_95=3, FB_REPLICA_ROLEX=3.157, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_GENREP=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oVx3NIJ6Vwg; Sun, 8 Jun 2008 08:23:47 -0700 (PDT) Received: from 25.pool85-50-130.dynamic.orange.es (25.pool85-50-130.dynamic.orange.es [85.50.130.25]) by core3.amsl.com (Postfix) with SMTP id 038DF3A6AE1; Sun, 8 Jun 2008 08:23:38 -0700 (PDT) X-Originating-IP: 94.112.240.23 by smtp.85.50.130.25; Sun, 08 Jun 2008 11:23:54 -0500 Message-ID: From: "Sammie Dow" Reply-To: "Sammie Dow" To: nemo-archive@ietf.org Subject: Affordable replica watches Date: Sun, 08 Jun 2008 11:23:54 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit When it comes down to getting a replica Rolex watch, there is just one place that offers its visitors and customers the highest quality available: Prestige Replicas. This unparalleled online store specializes in top of the line replica watches with unsurpassed performance, and bearing every marking that the genuine timepieces have. Every replica watch that Prestige Replicas carries, is made of solid stainless steel and features a sapphire crystal glass. What's more, every Rolex in store displays the green Rolex sticker with model number and logo on it. Just because you're buying a replica, don't settle for a low quality product. There are only a handful of online stores that offer the highest quality Rolex replica watches and Prestige Replicas is among them, and with the lowest available prices! http://mizorapahoz77.blogspot.com/ From nfsv4-bounces@ietf.org Sun Jun 8 08:23:49 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8863C3A6B45 for ; Sun, 8 Jun 2008 08:23:49 -0700 (PDT) Subject: The results of your email commands From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1968875002==" Message-ID: Date: Sun, 08 Jun 2008 08:23:47 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org --===============1968875002== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://mizorapahoz77.blogspot.com/ - Done. --===============1968875002== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nfsv4-request@core3.amsl.com Delivered-To: nfsv4-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4E013A6B2D; Sun, 8 Jun 2008 08:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -54.172 X-Spam-Level: X-Spam-Status: No, score=-54.172 tagged_above=-999 required=5 tests=[BAYES_95=3, FB_REPLICA_ROLEX=3.157, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_GENREP=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oVx3NIJ6Vwg; Sun, 8 Jun 2008 08:23:47 -0700 (PDT) Received: from 25.pool85-50-130.dynamic.orange.es (25.pool85-50-130.dynamic.orange.es [85.50.130.25]) by core3.amsl.com (Postfix) with SMTP id 038DF3A6AE1; Sun, 8 Jun 2008 08:23:38 -0700 (PDT) X-Originating-IP: 94.112.240.23 by smtp.85.50.130.25; Sun, 08 Jun 2008 11:23:54 -0500 Message-ID: From: "Sammie Dow" Reply-To: "Sammie Dow" To: nemo-archive@ietf.org Subject: Affordable replica watches Date: Sun, 08 Jun 2008 11:23:54 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit When it comes down to getting a replica Rolex watch, there is just one place that offers its visitors and customers the highest quality available: Prestige Replicas. This unparalleled online store specializes in top of the line replica watches with unsurpassed performance, and bearing every marking that the genuine timepieces have. Every replica watch that Prestige Replicas carries, is made of solid stainless steel and features a sapphire crystal glass. What's more, every Rolex in store displays the green Rolex sticker with model number and logo on it. Just because you're buying a replica, don't settle for a low quality product. There are only a handful of online stores that offer the highest quality Rolex replica watches and Prestige Replicas is among them, and with the lowest available prices! http://mizorapahoz77.blogspot.com/ --===============1968875002==-- From nemo-bounces@ietf.org Sun Jun 8 08:23:49 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AA893A6BAC for ; Sun, 8 Jun 2008 08:23:49 -0700 (PDT) Subject: The results of your email commands From: nemo-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0549680067==" Message-ID: Date: Sun, 08 Jun 2008 08:23:48 -0700 Precedence: bulk X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NEMO Working Group X-List-Administrivia: yes Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --===============0549680067== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://mizorapahoz77.blogspot.com/ - Done. --===============0549680067== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nemo-request@core3.amsl.com Delivered-To: nemo-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4E013A6B2D; Sun, 8 Jun 2008 08:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -54.172 X-Spam-Level: X-Spam-Status: No, score=-54.172 tagged_above=-999 required=5 tests=[BAYES_95=3, FB_REPLICA_ROLEX=3.157, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_GENREP=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oVx3NIJ6Vwg; Sun, 8 Jun 2008 08:23:47 -0700 (PDT) Received: from 25.pool85-50-130.dynamic.orange.es (25.pool85-50-130.dynamic.orange.es [85.50.130.25]) by core3.amsl.com (Postfix) with SMTP id 038DF3A6AE1; Sun, 8 Jun 2008 08:23:38 -0700 (PDT) X-Originating-IP: 94.112.240.23 by smtp.85.50.130.25; Sun, 08 Jun 2008 11:23:54 -0500 Message-ID: From: "Sammie Dow" Reply-To: "Sammie Dow" To: nemo-archive@ietf.org Subject: Affordable replica watches Date: Sun, 08 Jun 2008 11:23:54 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit When it comes down to getting a replica Rolex watch, there is just one place that offers its visitors and customers the highest quality available: Prestige Replicas. This unparalleled online store specializes in top of the line replica watches with unsurpassed performance, and bearing every marking that the genuine timepieces have. Every replica watch that Prestige Replicas carries, is made of solid stainless steel and features a sapphire crystal glass. What's more, every Rolex in store displays the green Rolex sticker with model number and logo on it. Just because you're buying a replica, don't settle for a low quality product. There are only a handful of online stores that offer the highest quality Rolex replica watches and Prestige Replicas is among them, and with the lowest available prices! http://mizorapahoz77.blogspot.com/ --===============0549680067==-- From nsis-bounces@ietf.org Sun Jun 8 08:23:49 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92A223A6B45 for ; Sun, 8 Jun 2008 08:23:49 -0700 (PDT) Subject: The results of your email commands From: nsis-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0775657539==" Message-ID: Date: Sun, 08 Jun 2008 08:23:48 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============0775657539== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://mizorapahoz77.blogspot.com/ - Done. --===============0775657539== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nsis-request@core3.amsl.com Delivered-To: nsis-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4E013A6B2D; Sun, 8 Jun 2008 08:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -54.172 X-Spam-Level: X-Spam-Status: No, score=-54.172 tagged_above=-999 required=5 tests=[BAYES_95=3, FB_REPLICA_ROLEX=3.157, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_GENREP=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oVx3NIJ6Vwg; Sun, 8 Jun 2008 08:23:47 -0700 (PDT) Received: from 25.pool85-50-130.dynamic.orange.es (25.pool85-50-130.dynamic.orange.es [85.50.130.25]) by core3.amsl.com (Postfix) with SMTP id 038DF3A6AE1; Sun, 8 Jun 2008 08:23:38 -0700 (PDT) X-Originating-IP: 94.112.240.23 by smtp.85.50.130.25; Sun, 08 Jun 2008 11:23:54 -0500 Message-ID: From: "Sammie Dow" Reply-To: "Sammie Dow" To: nemo-archive@ietf.org Subject: Affordable replica watches Date: Sun, 08 Jun 2008 11:23:54 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit When it comes down to getting a replica Rolex watch, there is just one place that offers its visitors and customers the highest quality available: Prestige Replicas. This unparalleled online store specializes in top of the line replica watches with unsurpassed performance, and bearing every marking that the genuine timepieces have. Every replica watch that Prestige Replicas carries, is made of solid stainless steel and features a sapphire crystal glass. What's more, every Rolex in store displays the green Rolex sticker with model number and logo on it. Just because you're buying a replica, don't settle for a low quality product. There are only a handful of online stores that offer the highest quality Rolex replica watches and Prestige Replicas is among them, and with the lowest available prices! http://mizorapahoz77.blogspot.com/ --===============0775657539==-- From nfsv4-bounces@ietf.org Sun Jun 8 08:23:49 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEEDF3A6BB8 for ; Sun, 8 Jun 2008 08:23:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nfsv4 awaits moderator approval From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Sun, 08 Jun 2008 08:23:48 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org Your mail to 'nfsv4' with the subject Affordable replica watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nfsv4/64b1100edca0be1002353b31255de86422de7848 From ngo-bounces@ietf.org Sun Jun 8 08:23:49 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6A513A6BB8 for ; Sun, 8 Jun 2008 08:23:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NGO awaits moderator approval From: ngo-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Sun, 08 Jun 2008 08:23:48 -0700 Precedence: bulk X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF X-List-Administrivia: yes Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Your mail to 'NGO' with the subject Affordable replica watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ngo/38ce0f7facec1bca5868c01147f3a3daad4adeab From nsis-imp-bounces@ietf.org Sun Jun 8 08:23:49 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0453A6BB8 for ; Sun, 8 Jun 2008 08:23:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NSIS-imp awaits moderator approval From: nsis-imp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Sun, 08 Jun 2008 08:23:49 -0700 Precedence: bulk X-BeenThere: nsis-imp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for implementation questions for NSIS protocols X-List-Administrivia: yes Sender: nsis-imp-bounces@ietf.org Errors-To: nsis-imp-bounces@ietf.org Your mail to 'NSIS-imp' with the subject Affordable replica watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis-imp/e7b9dd27fcffbd470ae64f8eaca2bb14e295be34 From netconf-bounces@ietf.org Sun Jun 8 08:23:49 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C88C43A6BB8 for ; Sun, 8 Jun 2008 08:23:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to Netconf awaits moderator approval From: netconf-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Sun, 08 Jun 2008 08:23:49 -0700 Precedence: bulk X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 List-Id: Network Configuration WG mailing list X-List-Administrivia: yes Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Your mail to 'Netconf' with the subject Affordable replica watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netconf/e37a2ab36186ac540f5e930af77964d305001e31 From netlmm-bounces@ietf.org Sun Jun 8 08:23:49 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D08203A6BDC for ; Sun, 8 Jun 2008 08:23:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to netlmm awaits moderator approval From: netlmm-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Sun, 08 Jun 2008 08:23:49 -0700 Precedence: bulk X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETLMM working group discussion list X-List-Administrivia: yes Sender: netlmm-bounces@ietf.org Errors-To: netlmm-bounces@ietf.org Your mail to 'netlmm' with the subject Affordable replica watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netlmm/c5abd96bf0f893011fdcdc206cdf7c4776ef7586 From nsis-bounces@ietf.org Sun Jun 8 08:23:49 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE30F3A6BB8 for ; Sun, 8 Jun 2008 08:23:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nsis awaits moderator approval From: nsis-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Sun, 08 Jun 2008 08:23:49 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Your mail to 'nsis' with the subject Affordable replica watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis/490210428a47adfaa00dc80bced8c343e8e26d42 From ntdp-bounces@ietf.org Sun Jun 8 08:23:50 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F153A6BE9 for ; Sun, 8 Jun 2008 08:23:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NTDP awaits moderator approval From: ntdp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Sun, 08 Jun 2008 08:23:49 -0700 Precedence: bulk X-BeenThere: ntdp@ietf.org X-Mailman-Version: 2.1.9 List-Id: define standards for the purpose of scripting of network testing equipment X-List-Administrivia: yes Sender: ntdp-bounces@ietf.org Errors-To: ntdp-bounces@ietf.org Your mail to 'NTDP' with the subject Affordable replica watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ntdp/5904b045cd720d7eae8228af2567a4dcff2a085c From mext-bounces@ietf.org Sun Jun 8 11:40:23 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CF313A6C16; Sun, 8 Jun 2008 11:40:23 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 383A53A6C15 for ; Sun, 8 Jun 2008 11:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUn8h7udzINg for ; Sun, 8 Jun 2008 11:40:20 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 4835F3A6C0E for ; Sun, 8 Jun 2008 11:40:20 -0700 (PDT) Received: from localhost ([127.0.0.1]:38757 helo=chardonnay.local) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1K5Poa-0005ns-9U; Sun, 08 Jun 2008 20:40:28 +0200 Message-ID: <484C279B.5040304@levkowetz.com> Date: Sun, 08 Jun 2008 20:40:27 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Julien Laganier References: <483D5A50.1000208@it.uc3m.es> <20080603104511.GA3314@kafka.verkstad.net> <200806051742.39799.julien.IETF@laposte.net> In-Reply-To: <200806051742.39799.julien.IETF@laposte.net> X-Enigmail-Version: 0.95.6 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: julien.IETF@laposte.net, mext@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 Cc: mext@ietf.org Subject: Re: [MEXT] Generic Signaling Message / Name of generic "notification" (Was: Scope of generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On 2008-06-05 17:42 Julien Laganier said the following: > Folks, > > > > What Michael said above rang a bell :) > > How about calling the new framework "MIPv6 Generic Signaling Message > (MGSM), and defines two MH types, one requiring IPsec, the other not. > > Then we would distinguish different types of messages (Revocation, Flow > Distribution Rules, Heartbeat, etc.) based on a subtype inside the > Generic Signaling Message. > > I think that should satisfy everybody: > - the IPsec SPD needs only one set of rules for each of the MH types > (bypass, and protect). > - a MGSM consumer (e.g. Revocation, Distribution Rules) simply specify > the MH type it chooses depending on whether or not it requires IPsec > protection. > - a MGSM consumer allocates one or more MGSM subtypes for each new > message necessary to implement the consumer's functionality. > - a MGSM consumer specifies processing (sending, receiving, state > machines...) for these subtyped messages. Sounds reasonable to me, as a rough plan. Henrik _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 9 04:04:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7AEF3A6A82; Mon, 9 Jun 2008 04:04:29 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8DC63A6A87 for ; Mon, 9 Jun 2008 04:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGvJHrKWQcxi for ; Mon, 9 Jun 2008 04:04:28 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id E71E83A6A4B for ; Mon, 9 Jun 2008 04:04:27 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2060779rvf.49 for ; Mon, 09 Jun 2008 04:04:44 -0700 (PDT) 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=kDqjMrlbWDM8/Z6agOt0LeTFtpxI5xS77CywdkaR3u8=; b=iKT93rRhXt/pmKIAp92DGIJNuJNlHh86LqNubiFPcCS4GHOD+0Uwi2TWdzojN0n0fy CkPaXtKnWR7H7aS6luAmy/3v7GexXtBoc4m1W2XutCRS/95MOZIoqTcSh0e3wSreNkCu oMQux8t7Kc6p0nHwojRq9KU0KAxmK2f0OaeDc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=rpWXSWXerafuvjOmg23E3MM5PmxHBytXmjneTvG/DcUlBsJ9itoHj+/+vnhh4ancFu 7w0ZZiiaK4yVeO+VeWxCwgQBMiqbvTF7bugv3tLxwyfd7DdmmGtYH/8MPkHVr4Qu6gmH qBTqLkl2fbU8cvb4Zncu/WtISu7jtAf/VpJyI= Received: by 10.140.136.6 with SMTP id j6mr87421rvd.231.1213009484296; Mon, 09 Jun 2008 04:04:44 -0700 (PDT) Received: by 10.141.21.16 with HTTP; Mon, 9 Jun 2008 04:04:44 -0700 (PDT) Message-ID: <5e2406980806090404j4c5ae572te454302568e7d8e1@mail.gmail.com> Date: Mon, 9 Jun 2008 13:04:44 +0200 From: "Julien Bournelle" To: "Julien Laganier" In-Reply-To: <200806051742.39799.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline References: <483D5A50.1000208@it.uc3m.es> <20080603104511.GA3314@kafka.verkstad.net> <200806051742.39799.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] Generic Signaling Message / Name of generic "notification" (Was: Scope of generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, inline.. On Thu, Jun 5, 2008 at 5:42 PM, Julien Laganier wrote: > On Tuesday 03 June 2008, Michael Eriksson wrote: >> - I don't particularly like the "notification" part of GNM's name, as >> I think it will should be used for more than notifications. > > Folks, > > > > What Michael said above rang a bell :) > > How about calling the new framework "MIPv6 Generic Signaling Message > (MGSM), and defines two MH types, one requiring IPsec, the other not. > > Then we would distinguish different types of messages (Revocation, Flow > Distribution Rules, Heartbeat, etc.) based on a subtype inside the > Generic Signaling Message. > > I think that should satisfy everybody: > - the IPsec SPD needs only one set of rules for each of the MH types > (bypass, and protect). > - a MGSM consumer (e.g. Revocation, Distribution Rules) simply specify > the MH type it chooses depending on whether or not it requires IPsec > protection. > - a MGSM consumer allocates one or more MGSM subtypes for each new > message necessary to implement the consumer's functionality. > - a MGSM consumer specifies processing (sending, receiving, state > machines...) for these subtyped messages. > > What do you think? sounds good to me. Thanks julien. -julien > > --julien > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 9 07:50:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384F43A6A76; Mon, 9 Jun 2008 07:50:12 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79F33A6834 for ; Mon, 9 Jun 2008 07:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROZWJXKhjdoh for ; Mon, 9 Jun 2008 07:50:08 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 5EA993A69BD for ; Mon, 9 Jun 2008 07:50:08 -0700 (PDT) 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 <0K27003L7AK3VW@usaga04-in.huawei.com> for mext@ietf.org; Mon, 09 Jun 2008 09:50:27 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K2700ED6AJWWQ@usaga04-in.huawei.com> for mext@ietf.org; Mon, 09 Jun 2008 09:50:26 -0500 (CDT) Date: Mon, 09 Jun 2008 09:50:20 -0500 From: Frank Xia To: Jean-Michel Combes Message-id: <010301c8ca40$270a6710$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <48401470.40706@it.uc3m.es> <7892795E1A87F04CADFCCF41FADD00FC05C0F044@xmb-ams-337.emea.cisco.com> <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> <006001c8c81d$e5581160$5c0c7c0a@china.huawei.com> <004901c8c825$a9ad9650$5c0c7c0a@china.huawei.com> <729b68be0806061630i7d88afa2w235dad4bafe74daa@mail.gmail.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Jean-Michel Even in SEND, IMHO, it is not necessary for HA to provide Router Authorization Certificate because HA and MR have authenticated each other using IKE, etc. Anyway, this scenario is not clear. BR Frank ----- Original Message ----- From: "Jean-Michel Combes" To: "Frank Xia" Cc: "fan zhao" ; ; "Julien Laganier" Sent: Friday, June 06, 2008 6:30 PM Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > Hi, > > Don't forget that people may want to deploy SEND and so you will have > to provide Router Authorization Certificate too in that case. > AFAIK, for the moment, there is no proposal to provide such > certificates with PBU/PBA and so you will have another mechanism. The > consequence is that you will loose the advantage in time you gained in > piggybacking the delegated prefixes in the PBU/PBA ... > > This is not the case with PMIP because the LMA is aware of the > prefixes assigned to the MAGs and during the set up of > > 2008/6/7, Frank Xia : >> Hi Fan >> >> Please check my reply... >> >> >> BR >> Frank >> >> ----- Original Message ----- >> From: "fan zhao" >> To: "Frank Xia" >> Cc: "Ryuji Wakikawa" ; "Julien Laganier" >> ; >> >> Sent: Friday, June 06, 2008 5:22 PM >> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> >> >> > Hi Frank, >> > >> > Please see below.. >> > >> > On Fri, Jun 6, 2008 at 2:40 PM, Frank Xia >> wrote: >> >> Hi Fan >> >> >> >> Please see my reply... >> >> >> >> BR >> >> Frank >> >> >> >> ----- Original Message ----- From: "fan zhao" >> >> To: "Frank Xia" >> >> Cc: "Ryuji Wakikawa" ; "Julien Laganier" >> >> ; >> >> Sent: Friday, June 06, 2008 3:33 PM >> >> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> >> >> >> >> >>> Hi Frank, >> >>> >> >>> Please see below. >> >>> >> >>> On Fri, Jun 6, 2008 at 10:51 AM, Frank Xia >> >>> wrote: >> >>>> >> >>>> Hi Fan, Ryuji and other colleagues. >> >>>> >> >>>> Agreed. >> >>>> >> >>>> IMHO,There are two ways for prefix delegation in Nemo, >> >>>> that is, overlay and integrated modes. >> >>>> >> >>>> DHCP based PD is a overlay solution which introduce redundancy >> >>>> while trying to reduce impact on NEMO itself. >> >>>> >> >>>> I favor the integrated mode in which Prefix Delegation is >> integrated >> >>>> into >> >>>> NEMO operations >> >>> >> >>> I agree that signaling overhead can be reduced if multiple _related_ >> >>> requests/responses >> >>> are piggybacked together, e.g. during one message exchange. For the >> MR >> >>> to work, it >> >>> needs both a HoA/HNP and a MNP. Besides requesting/registering the >> >>> MNP, there is >> >>> no much difference between the operation of the MN and that of the >> MR. >> >>> Furthermore, >> >>> the MR can request the MNP during the establishment of IPSec SA when >> >>> it is at either home link or foreign link. >> >> >> >> Frank=>For adressing in NEMO, there are two categories >> >> nodes for addressing, that is, MRs and hosts behind MRs. >> >> >> >> IKE can be used for MR's addressing, while it probabaly >> >> can't be used for host addressing (PD) without extension of IKE. >> > >> > Fan> We can simply define a new attribute carried in the >> > CFG_REQUEST/CFG_REPLY >> > configuration payload during the IKE_AUTH exchange. >> >> Frank=>It couples PD with IKE procedure. How does the >> MR renew/release/renumber the prefixes after IKE_AUTH exchange? >> Anyway, IKE is not solely for MIP, IMHO, it is not proper to >> extend for this purpose. >> >> IMO, the compromised way is to use BA/BU which >> is in line with PMIP thoughtway. >> >> >> > >> > >> >> >> >>> >> >>>> because prefix management is an integrated part >> >>>> of NEMO. >> >>>> PMIPv6 follow the same philosophy. >> >>> >> >>> If I understand correctly, PMIP is a slightly different case from >> >>> DSMIPv6/NEMO. >> >>> Because the connection, such as the IPSec SA, between the MAG and >> the >> >>> LMA >> >>> is already in place long before the MN attaches to the MAG, it makes >> >>> sense >> >>> for >> >>> the MAG to request the HNP for the MN during the PBU/PBA exchange. >> With >> >>> DSMIPv6, the MN requests the HoA/HNP during the establishment of the >> >>> IPSec >> >>> SA, therefore the MR should request the MNP during this procedure as >> >>> well. >> >> >> >> Frank=>It is true there is difference between PMIP and NEMO. >> >> I just do an analogy. What I want to say is it makes sense if we >> >> integrate >> >> PD >> >> into NEMO. >> > >> > Fan> OK. >> > >> > Sincerely, >> > fan >> > >> >> >> >>> >> >>> What do you think? >> >>> >> >>> Sincerely, >> >>> fan >> >>> >> >>>> >> >>>> BR >> >>>> Frank >> >>>> >> >>>> ----- Original Message ----- From: "fan zhao" >> >> >>>> To: "Ryuji Wakikawa" >> >>>> Cc: "Julien Laganier" ; >> >>>> Sent: Friday, June 06, 2008 12:18 PM >> >>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> >>>> >> >>>> >> >>>>> Hi Ryuji and et al, >> >>>>> >> >>>>> Sorry for jumping in. >> >>>>> I agree with Ryuji that the DHCP based PD procedure introduces >> >>>>> redundancy. >> >>>>> IMHO, the MR can request a MNP together with a HNP/HoA when >> >>>>> establishing >> >>>>> the IPSec SA with the HA. IMO, this is simpler. Do I miss >> something? >> >>>>> Thanks. >> >>>>> >> >>>>> Sincerely, >> >>>>> fan >> >>>>> >> >>>>> >> >>>>> On Wed, Jun 4, 2008 at 5:37 PM, Ryuji Wakikawa >> >>>>> >> >>>>> wrote: >> >>>>>> >> >>>>>> Hello Pascal, >> >>>>>> >> >>>>>> Sorry for late response. We have interop event in Tokyo and >> tested >> >>>>>> HAHA there;-) >> >>>>>> >> >>>>>> On 2008/06/03, at 17:08, Pascal Thubert (pthubert) wrote: >> >>>>>> >> >>>>>>> Hi Ryuji: >> >>>>>>> >> >>>>>>> I agree that PD should not impact bootstrap. These are and >> should be >> >>>>>>> kept unrelated. >> >>>>>>> >> >>>>>>> We must be able to extend a RFC 3963 MR with PD without forcing >> the >> >>>>>>> bootstrap process in the picture. So I agree not to bring DHAAD >> back >> >>>>>>> into the bootstrap... >> >>>>>> >> >>>>>> we agree then.. >> >>>>>> >> >>>>>>> But I think that PD is NOT a bootstrap process. It is post >> bootstrap >> >>>>>>> and >> >>>>>>> can reoccur many times in the life of the MR. >> >>>>>>> >> >>>>>>> Until we define a new process and rev 3775 and 3963, we should >> stay >> >>>>>>> consistent and simple in what we are doing. >> >>>>>> >> >>>>>> DHCP-PD can surely impact to the bootstrap process. >> >>>>>> >> >>>>>> Let's say MR boots up as a MN with RFC5026 first. >> >>>>>> Then, it tries to get a MNP for NEMO. >> >>>>>> >> >>>>>> If the current HA is not PD-enabled and DHAAD returns different >> HA, >> >>>>>> MR must de-register the binding from the current HA and tries to >> >>>>>> start >> >>>>>> all the registration process to the new HA. >> >>>>>> >> >>>>>> This seems very redundant operation.. >> >>>>>> I want to make the PD spec simple. >> >>>>>> >> >>>>>> regards >> >>>>>> ryuji >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> Pascal >> >>>>>>> >> >>>>>>>> -----Original Message----- >> >>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> >>>>>>>> Behalf Of >> >>>>>>> >> >>>>>>> Ryuji Wakikawa >> >>>>>>>> >> >>>>>>>> Sent: mardi 3 juin 2008 09:54 >> >>>>>>>> To: marcelo bagnulo braun >> >>>>>>>> Cc: Julien Laganier; mext@ietf.org >> >>>>>>>> Subject: Re: [MEXT] Adoption of >> draft-droms-mext-nemo-pd-00.txt? >> >>>>>>>> >> >>>>>>>> Hi Marcelo, >> >>>>>>>> >> >>>>>>>> I agree to accept this as WG doc. >> >>>>>>>> >> >>>>>>>> I also agree with Romain and Vijay. >> >>>>>>>> We don't need extension to DHAAD. >> >>>>>>>> Since MR can act as MN, MR should be able to bootstrap with the >> >>>>>>>> same >> >>>>>>>> mechanism of MIP (except for PD). >> >>>>>>>> We should not bring DHAAD back in the bootstrap process only >> for >> >>>>>>>> PD. >> >>>>>>>> >> >>>>>>>> regards, >> >>>>>>>> ryuji >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On 2008/05/30, at 23:51, marcelo bagnulo braun wrote: >> >>>>>>>> >> >>>>>>>>> Hi, >> >>>>>>>>> >> >>>>>>>>> We would like to ask the WG what is their opinion about >> accepting >> >>>>>>>>> draft-droms-mext-nemo-pd-00.txt as the WG document for the >> Nemo PD >> >>>>>>>>> deliverable included in our charter. >> >>>>>>>>> >> >>>>>>>>> Please provide comments so we cna make some progress on this >> long >> >>>>>>>>> overdue deliverable >> >>>>>>>>> >> >>>>>>>>> thanks, Julien and marcelo >> >>>>>>>>> -------- Mensaje original -------- >> >>>>>>>>> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt >> >>>>>>>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >> >>>>>>>>> De: Internet-Drafts@ietf.org >> >>>>>>>>> Responder a: internet-drafts@ietf.org >> >>>>>>>>> Para: i-d-announce@ietf.org >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> A New Internet-Draft is available from the on-line >> Internet-Drafts >> >>>>>>>>> directories. >> >>>>>>>>> >> >>>>>>>>> Title : DHCPv6 Prefix Delegation for NEMO >> >>>>>>>>> Author(s) : R. Droms, et al. >> >>>>>>>>> Filename : draft-droms-mext-nemo-pd-00.txt >> >>>>>>>>> Pages : 12 >> >>>>>>>>> Date : 2008-05-30 >> >>>>>>>>> >> >>>>>>>>> One aspect of network mobility support is the assignment of a >> >>>>>>>>> prefix >> >>>>>>>>> or prefixes to a Mobile Router (MR) for use on the links in >> the >> >>>>>>>>> Mobile Network. DHCPv6 prefix delegation can be used for this >> >>>>>>>>> configuration task. >> >>>>>>>>> >> >>>>>>>>> A URL for this Internet-Draft is: >> >>>>>>>>> >> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt >> >>>>>>>>> >> >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >> >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >> >>>>>>>>> >> >>>>>>>>> Below is the data which will enable a MIME compliant mail >> reader >> >>>>>>>>> implementation to automatically retrieve the ASCII version of >> the >> >>>>>>>>> Internet-Draft. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Content-Type: text/plain >> >>>>>>>>> Content-ID: <2008-05-30054232.I-D@ietf.org> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> _______________________________________________ >> >>>>>>>>> I-D-Announce mailing list >> >>>>>>>>> I-D-Announce@ietf.org >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >> >>>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >> >>>>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >>>>>>>>> >> >>>>>>>>> _______________________________________________ >> >>>>>>>>> MEXT mailing list >> >>>>>>>>> MEXT@ietf.org >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >> >>>>>>>> >> >>>>>>>> _______________________________________________ >> >>>>>>>> MEXT mailing list >> >>>>>>>> MEXT@ietf.org >> >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> MEXT mailing list >> >>>>>> MEXT@ietf.org >> >>>>>> https://www.ietf.org/mailman/listinfo/mext >> >>>>>> >> >>>>> _______________________________________________ >> >>>>> MEXT mailing list >> >>>>> MEXT@ietf.org >> >>>>> https://www.ietf.org/mailman/listinfo/mext >> >>>>> >> >>>> >> >>>> >> >>>> >> >>> >> >> >> >> >> >> >> > >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From c.marechal@multimed.be Mon Jun 9 08:08:49 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 095B83A6C3E; Mon, 9 Jun 2008 08:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -78.65 X-Spam-Level: X-Spam-Status: No, score=-78.65 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5F=0.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Z3Q09ReniFw; Mon, 9 Jun 2008 08:08:48 -0700 (PDT) Received: from 99-105-18-190.fibertel.com.ar (unknown [190.18.105.99]) by core3.amsl.com (Postfix) with SMTP id 268DB3A6C63; Mon, 9 Jun 2008 08:08:31 -0700 (PDT) X-Originating-IP: 144.164.90.170 by smtp.190.18.105.99; Mon, 09 Jun 2008 11:08:48 -0500 Message-ID: From: "Todd Hodge" Reply-To: "Todd Hodge" To: nemo-archive@ietf.org Subject: Affordable brand name watches Date: Mon, 09 Jun 2008 11:08:48 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://timapekucyv82.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://timapekucyv82.blogspot.com/ From nfsv4-bounces@ietf.org Mon Jun 9 08:08:50 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5483B3A6C99 for ; Mon, 9 Jun 2008 08:08:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nfsv4 awaits moderator approval From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 09 Jun 2008 08:08:49 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org Your mail to 'nfsv4' with the subject Affordable brand name watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nfsv4/ece693738206fc15caeb1fd2306a1e827e431979 From netconf-bounces@ietf.org Mon Jun 9 08:08:50 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA9F3A6C99 for ; Mon, 9 Jun 2008 08:08:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to Netconf awaits moderator approval From: netconf-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 09 Jun 2008 08:08:49 -0700 Precedence: bulk X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 List-Id: Network Configuration WG mailing list X-List-Administrivia: yes Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Your mail to 'Netconf' with the subject Affordable brand name watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netconf/7a2ce8c7d566863cf5be5459381f888602f99702 From netlmm-bounces@ietf.org Mon Jun 9 08:08:50 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6312B28C15F for ; Mon, 9 Jun 2008 08:08:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to netlmm awaits moderator approval From: netlmm-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 09 Jun 2008 08:08:49 -0700 Precedence: bulk X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETLMM working group discussion list X-List-Administrivia: yes Sender: netlmm-bounces@ietf.org Errors-To: netlmm-bounces@ietf.org Your mail to 'netlmm' with the subject Affordable brand name watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netlmm/3c47c72025374416cabd08bce9e2147432c10527 From nsis-bounces@ietf.org Mon Jun 9 08:08:50 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 747193A6C9C for ; Mon, 9 Jun 2008 08:08:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nsis awaits moderator approval From: nsis-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 09 Jun 2008 08:08:49 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Your mail to 'nsis' with the subject Affordable brand name watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis/95e01842dde284af3b8187c41a82c186f01a6e5f From ntdp-bounces@ietf.org Mon Jun 9 08:08:50 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B9D53A6C9C for ; Mon, 9 Jun 2008 08:08:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NTDP awaits moderator approval From: ntdp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 09 Jun 2008 08:08:49 -0700 Precedence: bulk X-BeenThere: ntdp@ietf.org X-Mailman-Version: 2.1.9 List-Id: define standards for the purpose of scripting of network testing equipment X-List-Administrivia: yes Sender: ntdp-bounces@ietf.org Errors-To: ntdp-bounces@ietf.org Your mail to 'NTDP' with the subject Affordable brand name watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ntdp/56f8726e812b57795d05f350704aa44fc8fc0e66 From nsis-imp-bounces@ietf.org Mon Jun 9 08:08:50 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8967E3A6C9C for ; Mon, 9 Jun 2008 08:08:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NSIS-imp awaits moderator approval From: nsis-imp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 09 Jun 2008 08:08:49 -0700 Precedence: bulk X-BeenThere: nsis-imp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for implementation questions for NSIS protocols X-List-Administrivia: yes Sender: nsis-imp-bounces@ietf.org Errors-To: nsis-imp-bounces@ietf.org Your mail to 'NSIS-imp' with the subject Affordable brand name watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis-imp/f90d81aa9abb4fd5c2f0074938afdab664349310 From ngo-bounces@ietf.org Mon Jun 9 08:08:50 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FA983A6C9C for ; Mon, 9 Jun 2008 08:08:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NGO awaits moderator approval From: ngo-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 09 Jun 2008 08:08:49 -0700 Precedence: bulk X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF X-List-Administrivia: yes Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Your mail to 'NGO' with the subject Affordable brand name watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ngo/fd3df409929fb1b291c15df66477a696ebc233e6 From nemo-bounces@ietf.org Mon Jun 9 08:08:51 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 968943A6C3E for ; Mon, 9 Jun 2008 08:08:51 -0700 (PDT) Subject: The results of your email commands From: nemo-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0334794203==" Message-ID: Date: Mon, 09 Jun 2008 08:08:50 -0700 Precedence: bulk X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NEMO Working Group X-List-Administrivia: yes Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --===============0334794203== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://timapekucyv82.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://timapekucyv82.blogspot.com/ - Done. --===============0334794203== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nemo-request@core3.amsl.com Delivered-To: nemo-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 095B83A6C3E; Mon, 9 Jun 2008 08:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -78.65 X-Spam-Level: X-Spam-Status: No, score=-78.65 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5F=0.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Z3Q09ReniFw; Mon, 9 Jun 2008 08:08:48 -0700 (PDT) Received: from 99-105-18-190.fibertel.com.ar (unknown [190.18.105.99]) by core3.amsl.com (Postfix) with SMTP id 268DB3A6C63; Mon, 9 Jun 2008 08:08:31 -0700 (PDT) X-Originating-IP: 144.164.90.170 by smtp.190.18.105.99; Mon, 09 Jun 2008 11:08:48 -0500 Message-ID: From: "Todd Hodge" Reply-To: "Todd Hodge" To: nemo-archive@ietf.org Subject: Affordable brand name watches Date: Mon, 09 Jun 2008 11:08:48 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://timapekucyv82.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://timapekucyv82.blogspot.com/ --===============0334794203==-- From nfsv4-bounces@ietf.org Mon Jun 9 08:08:51 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99E4D3A6C63 for ; Mon, 9 Jun 2008 08:08:51 -0700 (PDT) Subject: The results of your email commands From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1117363888==" Message-ID: Date: Mon, 09 Jun 2008 08:08:50 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org --===============1117363888== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://timapekucyv82.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://timapekucyv82.blogspot.com/ - Done. --===============1117363888== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nfsv4-request@core3.amsl.com Delivered-To: nfsv4-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 095B83A6C3E; Mon, 9 Jun 2008 08:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -78.65 X-Spam-Level: X-Spam-Status: No, score=-78.65 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5F=0.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Z3Q09ReniFw; Mon, 9 Jun 2008 08:08:48 -0700 (PDT) Received: from 99-105-18-190.fibertel.com.ar (unknown [190.18.105.99]) by core3.amsl.com (Postfix) with SMTP id 268DB3A6C63; Mon, 9 Jun 2008 08:08:31 -0700 (PDT) X-Originating-IP: 144.164.90.170 by smtp.190.18.105.99; Mon, 09 Jun 2008 11:08:48 -0500 Message-ID: From: "Todd Hodge" Reply-To: "Todd Hodge" To: nemo-archive@ietf.org Subject: Affordable brand name watches Date: Mon, 09 Jun 2008 11:08:48 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://timapekucyv82.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://timapekucyv82.blogspot.com/ --===============1117363888==-- From nsis-bounces@ietf.org Mon Jun 9 08:08:51 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EB533A6C3E for ; Mon, 9 Jun 2008 08:08:51 -0700 (PDT) Subject: The results of your email commands From: nsis-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0641013701==" Message-ID: Date: Mon, 09 Jun 2008 08:08:50 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============0641013701== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://timapekucyv82.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://timapekucyv82.blogspot.com/ - Done. --===============0641013701== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nsis-request@core3.amsl.com Delivered-To: nsis-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 095B83A6C3E; Mon, 9 Jun 2008 08:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -78.65 X-Spam-Level: X-Spam-Status: No, score=-78.65 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5F=0.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Z3Q09ReniFw; Mon, 9 Jun 2008 08:08:48 -0700 (PDT) Received: from 99-105-18-190.fibertel.com.ar (unknown [190.18.105.99]) by core3.amsl.com (Postfix) with SMTP id 268DB3A6C63; Mon, 9 Jun 2008 08:08:31 -0700 (PDT) X-Originating-IP: 144.164.90.170 by smtp.190.18.105.99; Mon, 09 Jun 2008 11:08:48 -0500 Message-ID: From: "Todd Hodge" Reply-To: "Todd Hodge" To: nemo-archive@ietf.org Subject: Affordable brand name watches Date: Mon, 09 Jun 2008 11:08:48 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://timapekucyv82.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://timapekucyv82.blogspot.com/ --===============0641013701==-- From mext-bounces@ietf.org Mon Jun 9 09:05:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4B593A6A7F; Mon, 9 Jun 2008 09:05:29 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5AAD3A6A7F for ; Mon, 9 Jun 2008 09:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBAaxA2F1Dxz for ; Mon, 9 Jun 2008 09:05:27 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id EA4083A69C5 for ; Mon, 9 Jun 2008 09:05:26 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2178941rvf.49 for ; Mon, 09 Jun 2008 09:05:46 -0700 (PDT) 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=xZnDS7zg3wGMUGRbQFfL+uPk6Bq1u2LXRNwsgzZDyGk=; b=L8q/rnkMZ77CO6i3euGeglRMzaWOdFJtNa6bU3oR2xh0/7PmnToUBiJo3QKOYVfjkV MUNi1nPHPPRPQ30DhbTwO+z/qaKNRUwSs1OyozqEgdmCVpJsO5SRd0p3sZC4R4WkOfpl wbVOraJd36ogs/gl3KoA7DHCHxdr1XdBpuzrY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=n7uRtEy4dhBJAVOy1iOpmoCrbcCz2f3+IBrrgwj/Z94eXX6kbA6c0aHLj+BtBNebhG RN47JYZQMud7Naj/powIt2TMoF6oh6oLW0C5ObVctUCrYQwXfLeZ1UMg8D4E9evLGxaX CwQFMh6LkVWPT4j56kCUQZkBrVKwSHc1ak3JI= Received: by 10.140.249.20 with SMTP id w20mr2234934rvh.103.1213027546070; Mon, 09 Jun 2008 09:05:46 -0700 (PDT) Received: by 10.141.189.15 with HTTP; Mon, 9 Jun 2008 09:05:45 -0700 (PDT) Message-ID: <729b68be0806090905n1c48163fw11a75825994ca73@mail.gmail.com> Date: Mon, 9 Jun 2008 18:05:45 +0200 From: "Jean-Michel Combes" To: "Frank Xia" In-Reply-To: <010301c8ca40$270a6710$5c0c7c0a@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline References: <48401470.40706@it.uc3m.es> <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> <006001c8c81d$e5581160$5c0c7c0a@china.huawei.com> <004901c8c825$a9ad9650$5c0c7c0a@china.huawei.com> <729b68be0806061630i7d88afa2w235dad4bafe74daa@mail.gmail.com> <010301c8ca40$270a6710$5c0c7c0a@china.huawei.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Frank, If SEND is deployed in the NEMO network (i.e. MR's ingress interface), at the same time the HA has to provide the MNPs, it has to provide the Router Authorization Certificate linked to the MNPs. There is no relationship between IKE and SEND, by the way. Best regards. JMC. 2008/6/9, Frank Xia : > Hi Jean-Michel > > Even in SEND, IMHO, it is not necessary for HA to > provide Router Authorization Certificate because > HA and MR have authenticated each other using > IKE, etc. > > Anyway, this scenario is not clear. > > BR > Frank > > ----- Original Message ----- From: "Jean-Michel Combes" > > To: "Frank Xia" > Cc: "fan zhao" ; ; "Julien Laganier" > > Sent: Friday, June 06, 2008 6:30 PM > > Subject: Re: [MEXT] Adoption of > draft-droms-mext-nemo-pd-00.txt? > > > > > Hi, > > > > Don't forget that people may want to deploy SEND and so you will have > > to provide Router Authorization Certificate too in that case. > > AFAIK, for the moment, there is no proposal to provide such > > certificates with PBU/PBA and so you will have another mechanism. The > > consequence is that you will loose the advantage in time you gained in > > piggybacking the delegated prefixes in the PBU/PBA ... > > > > This is not the case with PMIP because the LMA is aware of the > > prefixes assigned to the MAGs and during the set up of > > > > 2008/6/7, Frank Xia : > > > > > Hi Fan > > > > > > Please check my reply... > > > > > > > > > BR > > > Frank > > > > > > ----- Original Message ----- > > > From: "fan zhao" > > > To: "Frank Xia" > > > Cc: "Ryuji Wakikawa" ; "Julien Laganier" > > > ; > > > > > > Sent: Friday, June 06, 2008 5:22 PM > > > Subject: Re: [MEXT] Adoption of > draft-droms-mext-nemo-pd-00.txt? > > > > > > > > > > Hi Frank, > > > > > > > > Please see below.. > > > > > > > > On Fri, Jun 6, 2008 at 2:40 PM, Frank Xia > wrote: > > > >> Hi Fan > > > >> > > > >> Please see my reply... > > > >> > > > >> BR > > > >> Frank > > > >> > > > >> ----- Original Message ----- From: "fan zhao" > > > >> To: "Frank Xia" > > > >> Cc: "Ryuji Wakikawa" ; "Julien Laganier" > > > >> ; > > > >> Sent: Friday, June 06, 2008 3:33 PM > > > >> Subject: Re: [MEXT] Adoption of > draft-droms-mext-nemo-pd-00.txt? > > > >> > > > >> > > > >>> Hi Frank, > > > >>> > > > >>> Please see below. > > > >>> > > > >>> On Fri, Jun 6, 2008 at 10:51 AM, Frank Xia > > > >>> wrote: > > > >>>> > > > >>>> Hi Fan, Ryuji and other colleagues. > > > >>>> > > > >>>> Agreed. > > > >>>> > > > >>>> IMHO,There are two ways for prefix delegation in Nemo, > > > >>>> that is, overlay and integrated modes. > > > >>>> > > > >>>> DHCP based PD is a overlay solution which introduce redundancy > > > >>>> while trying to reduce impact on NEMO itself. > > > >>>> > > > >>>> I favor the integrated mode in which Prefix Delegation is > integrated > > > >>>> into > > > >>>> NEMO operations > > > >>> > > > >>> I agree that signaling overhead can be reduced if multiple > _related_ > > > >>> requests/responses > > > >>> are piggybacked together, e.g. during one message exchange. For the > MR > > > >>> to work, it > > > >>> needs both a HoA/HNP and a MNP. Besides requesting/registering the > > > >>> MNP, there is > > > >>> no much difference between the operation of the MN and that of the > MR. > > > >>> Furthermore, > > > >>> the MR can request the MNP during the establishment of IPSec SA > when > > > >>> it is at either home link or foreign link. > > > >> > > > >> Frank=>For adressing in NEMO, there are two categories > > > >> nodes for addressing, that is, MRs and hosts behind MRs. > > > >> > > > >> IKE can be used for MR's addressing, while it probabaly > > > >> can't be used for host addressing (PD) without extension of IKE. > > > > > > > > Fan> We can simply define a new attribute carried in the > > > > CFG_REQUEST/CFG_REPLY > > > > configuration payload during the IKE_AUTH exchange. > > > > > > Frank=>It couples PD with IKE procedure. How does the > > > MR renew/release/renumber the prefixes after IKE_AUTH exchange? > > > Anyway, IKE is not solely for MIP, IMHO, it is not proper to > > > extend for this purpose. > > > > > > IMO, the compromised way is to use BA/BU which > > > is in line with PMIP thoughtway. > > > > > > > > > > > > > > > > > >> > > > >>> > > > >>>> because prefix management is an integrated part > > > >>>> of NEMO. > > > >>>> PMIPv6 follow the same philosophy. > > > >>> > > > >>> If I understand correctly, PMIP is a slightly different case from > > > >>> DSMIPv6/NEMO. > > > >>> Because the connection, such as the IPSec SA, between the MAG and > the > > > >>> LMA > > > >>> is already in place long before the MN attaches to the MAG, it > makes > > > >>> sense > > > >>> for > > > >>> the MAG to request the HNP for the MN during the PBU/PBA exchange. > With > > > >>> DSMIPv6, the MN requests the HoA/HNP during the establishment of > the > > > >>> IPSec > > > >>> SA, therefore the MR should request the MNP during this procedure > as > > > >>> well. > > > >> > > > >> Frank=>It is true there is difference between PMIP and NEMO. > > > >> I just do an analogy. What I want to say is it makes sense if we > > > >> integrate > > > >> PD > > > >> into NEMO. > > > > > > > > Fan> OK. > > > > > > > > Sincerely, > > > > fan > > > > > > > >> > > > >>> > > > >>> What do you think? > > > >>> > > > >>> Sincerely, > > > >>> fan > > > >>> > > > >>>> > > > >>>> BR > > > >>>> Frank > > > >>>> > > > >>>> ----- Original Message ----- From: "fan zhao" > > > > >>>> To: "Ryuji Wakikawa" > > > >>>> Cc: "Julien Laganier" ; > > > >>>> Sent: Friday, June 06, 2008 12:18 PM > > > >>>> Subject: Re: [MEXT] Adoption of > draft-droms-mext-nemo-pd-00.txt? > > > >>>> > > > >>>> > > > >>>>> Hi Ryuji and et al, > > > >>>>> > > > >>>>> Sorry for jumping in. > > > >>>>> I agree with Ryuji that the DHCP based PD procedure introduces > > > >>>>> redundancy. > > > >>>>> IMHO, the MR can request a MNP together with a HNP/HoA when > > > >>>>> establishing > > > >>>>> the IPSec SA with the HA. IMO, this is simpler. Do I miss > something? > > > >>>>> Thanks. > > > >>>>> > > > >>>>> Sincerely, > > > >>>>> fan > > > >>>>> > > > >>>>> > > > >>>>> On Wed, Jun 4, 2008 at 5:37 PM, Ryuji Wakikawa > > > >>>>> > > > >>>>> wrote: > > > >>>>>> > > > >>>>>> Hello Pascal, > > > >>>>>> > > > >>>>>> Sorry for late response. We have interop event in Tokyo and > tested > > > >>>>>> HAHA there;-) > > > >>>>>> > > > >>>>>> On 2008/06/03, at 17:08, Pascal Thubert (pthubert) wrote: > > > >>>>>> > > > >>>>>>> Hi Ryuji: > > > >>>>>>> > > > >>>>>>> I agree that PD should not impact bootstrap. These are and > should be > > > >>>>>>> kept unrelated. > > > >>>>>>> > > > >>>>>>> We must be able to extend a RFC 3963 MR with PD without forcing > the > > > >>>>>>> bootstrap process in the picture. So I agree not to bring DHAAD > back > > > >>>>>>> into the bootstrap... > > > >>>>>> > > > >>>>>> we agree then.. > > > >>>>>> > > > >>>>>>> But I think that PD is NOT a bootstrap process. It is post > bootstrap > > > >>>>>>> and > > > >>>>>>> can reoccur many times in the life of the MR. > > > >>>>>>> > > > >>>>>>> Until we define a new process and rev 3775 and 3963, we should > stay > > > >>>>>>> consistent and simple in what we are doing. > > > >>>>>> > > > >>>>>> DHCP-PD can surely impact to the bootstrap process. > > > >>>>>> > > > >>>>>> Let's say MR boots up as a MN with RFC5026 first. > > > >>>>>> Then, it tries to get a MNP for NEMO. > > > >>>>>> > > > >>>>>> If the current HA is not PD-enabled and DHAAD returns different > HA, > > > >>>>>> MR must de-register the binding from the current HA and tries to > > > >>>>>> start > > > >>>>>> all the registration process to the new HA. > > > >>>>>> > > > >>>>>> This seems very redundant operation.. > > > >>>>>> I want to make the PD spec simple. > > > >>>>>> > > > >>>>>> regards > > > >>>>>> ryuji > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> Pascal > > > >>>>>>> > > > >>>>>>>> -----Original Message----- > > > >>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > > >>>>>>>> Behalf Of > > > >>>>>>> > > > >>>>>>> Ryuji Wakikawa > > > >>>>>>>> > > > >>>>>>>> Sent: mardi 3 juin 2008 09:54 > > > >>>>>>>> To: marcelo bagnulo braun > > > >>>>>>>> Cc: Julien Laganier; mext@ietf.org > > > >>>>>>>> Subject: Re: [MEXT] Adoption of > draft-droms-mext-nemo-pd-00.txt? > > > >>>>>>>> > > > >>>>>>>> Hi Marcelo, > > > >>>>>>>> > > > >>>>>>>> I agree to accept this as WG doc. > > > >>>>>>>> > > > >>>>>>>> I also agree with Romain and Vijay. > > > >>>>>>>> We don't need extension to DHAAD. > > > >>>>>>>> Since MR can act as MN, MR should be able to bootstrap with > the > > > >>>>>>>> same > > > >>>>>>>> mechanism of MIP (except for PD). > > > >>>>>>>> We should not bring DHAAD back in the bootstrap process only > for > > > >>>>>>>> PD. > > > >>>>>>>> > > > >>>>>>>> regards, > > > >>>>>>>> ryuji > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> On 2008/05/30, at 23:51, marcelo bagnulo braun wrote: > > > >>>>>>>> > > > >>>>>>>>> Hi, > > > >>>>>>>>> > > > >>>>>>>>> We would like to ask the WG what is their opinion about > accepting > > > >>>>>>>>> draft-droms-mext-nemo-pd-00.txt as the WG document for the > Nemo PD > > > >>>>>>>>> deliverable included in our charter. > > > >>>>>>>>> > > > >>>>>>>>> Please provide comments so we cna make some progress on this > long > > > >>>>>>>>> overdue deliverable > > > >>>>>>>>> > > > >>>>>>>>> thanks, Julien and marcelo > > > >>>>>>>>> -------- Mensaje original -------- > > > >>>>>>>>> Asunto: I-D > Action:draft-droms-mext-nemo-pd-00.txt > > > >>>>>>>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) > > > >>>>>>>>> De: Internet-Drafts@ietf.org > > > >>>>>>>>> Responder a: internet-drafts@ietf.org > > > >>>>>>>>> Para: i-d-announce@ietf.org > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> A New Internet-Draft is available from the on-line > Internet-Drafts > > > >>>>>>>>> directories. > > > >>>>>>>>> > > > >>>>>>>>> Title : DHCPv6 Prefix Delegation for NEMO > > > >>>>>>>>> Author(s) : R. Droms, et al. > > > >>>>>>>>> Filename : draft-droms-mext-nemo-pd-00.txt > > > >>>>>>>>> Pages : 12 > > > >>>>>>>>> Date : 2008-05-30 > > > >>>>>>>>> > > > >>>>>>>>> One aspect of network mobility support is the assignment of a > > > >>>>>>>>> prefix > > > >>>>>>>>> or prefixes to a Mobile Router (MR) for use on the links in > the > > > >>>>>>>>> Mobile Network. DHCPv6 prefix delegation can be used for > this > > > >>>>>>>>> configuration task. > > > >>>>>>>>> > > > >>>>>>>>> A URL for this Internet-Draft is: > > > >>>>>>>>> > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt > > > >>>>>>>>> > > > >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: > > > >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ > > > >>>>>>>>> > > > >>>>>>>>> Below is the data which will enable a MIME compliant mail > reader > > > >>>>>>>>> implementation to automatically retrieve the ASCII version of > the > > > >>>>>>>>> Internet-Draft. > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> Content-Type: text/plain > > > >>>>>>>>> Content-ID: <2008-05-30054232.I-D@ietf.org> > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> > _______________________________________________ > > > >>>>>>>>> I-D-Announce mailing list > > > >>>>>>>>> I-D-Announce@ietf.org > > > >>>>>>>>> > https://www.ietf.org/mailman/listinfo/i-d-announce > > > >>>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html > > > >>>>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > >>>>>>>>> > > > >>>>>>>>> > _______________________________________________ > > > >>>>>>>>> MEXT mailing list > > > >>>>>>>>> MEXT@ietf.org > > > >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext > > > >>>>>>>> > > > >>>>>>>> > _______________________________________________ > > > >>>>>>>> MEXT mailing list > > > >>>>>>>> MEXT@ietf.org > > > >>>>>>>> https://www.ietf.org/mailman/listinfo/mext > > > >>>>>> > > > >>>>>> _______________________________________________ > > > >>>>>> MEXT mailing list > > > >>>>>> MEXT@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/mext > > > >>>>>> > > > >>>>> _______________________________________________ > > > >>>>> MEXT mailing list > > > >>>>> MEXT@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/mext > > > >>>>> > > > >>>> > > > >>>> > > > >>>> > > > >>> > > > >> > > > >> > > > >> > > > > > > > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 9 10:53:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C049D3A6994; Mon, 9 Jun 2008 10:53:35 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 582D43A67FB for ; Mon, 9 Jun 2008 10:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsVn3myiA4Hp for ; Mon, 9 Jun 2008 10:53:32 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id C20BF3A68EA for ; Mon, 9 Jun 2008 10:53:32 -0700 (PDT) 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 <0K27007HXJ1RLR@usaga04-in.huawei.com> for mext@ietf.org; Mon, 09 Jun 2008 12:53:52 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K27006K9J1QVY@usaga04-in.huawei.com> for mext@ietf.org; Mon, 09 Jun 2008 12:53:51 -0500 (CDT) Date: Mon, 09 Jun 2008 12:53:49 -0500 From: Frank Xia To: Jean-Michel Combes Message-id: <000b01c8ca59$c65c3190$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <48401470.40706@it.uc3m.es> <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> <006001c8c81d$e5581160$5c0c7c0a@china.huawei.com> <004901c8c825$a9ad9650$5c0c7c0a@china.huawei.com> <729b68be0806061630i7d88afa2w235dad4bafe74daa@mail.gmail.com> <010301c8ca40$270a6710$5c0c7c0a@china.huawei.com> <729b68be0806090905n1c48163fw11a75825994ca73@mail.gmail.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi JMC Firstly, the certificate issuing party is not supposed to be HA, so the certificate does not mandatorily get from the HA. Or, how does the HA get the certificate of the MR? Secondly, if the prefix information can't be sychronized between the certificate issuing party and the HA, the prefix should not included in the certificate. There are same concerns with PMIPv6 when you insist that the certificate should be delegated from the HA. There is no perfect solution but compromised solution. BR Frank ----- Original Message ----- From: "Jean-Michel Combes" To: "Frank Xia" Cc: "fan zhao" ; ; "Julien Laganier" Sent: Monday, June 09, 2008 11:05 AM Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > Hi Frank, > > If SEND is deployed in the NEMO network (i.e. MR's ingress interface), > at the same time the HA has to provide the MNPs, it has to provide the > Router Authorization Certificate linked to the MNPs. > > There is no relationship between IKE and SEND, by the way. > > Best regards. > > JMC. > > 2008/6/9, Frank Xia : >> Hi Jean-Michel >> >> Even in SEND, IMHO, it is not necessary for HA to >> provide Router Authorization Certificate because >> HA and MR have authenticated each other using >> IKE, etc. >> >> Anyway, this scenario is not clear. >> >> BR >> Frank >> >> ----- Original Message ----- From: "Jean-Michel Combes" >> >> To: "Frank Xia" >> Cc: "fan zhao" ; ; "Julien >> Laganier" >> >> Sent: Friday, June 06, 2008 6:30 PM >> >> Subject: Re: [MEXT] Adoption of >> draft-droms-mext-nemo-pd-00.txt? >> >> >> >> > Hi, >> > >> > Don't forget that people may want to deploy SEND and so you will have >> > to provide Router Authorization Certificate too in that case. >> > AFAIK, for the moment, there is no proposal to provide such >> > certificates with PBU/PBA and so you will have another mechanism. The >> > consequence is that you will loose the advantage in time you gained in >> > piggybacking the delegated prefixes in the PBU/PBA ... >> > >> > This is not the case with PMIP because the LMA is aware of the >> > prefixes assigned to the MAGs and during the set up of >> > >> > 2008/6/7, Frank Xia : >> > >> > > Hi Fan >> > > >> > > Please check my reply... >> > > >> > > >> > > BR >> > > Frank >> > > >> > > ----- Original Message ----- >> > > From: "fan zhao" >> > > To: "Frank Xia" >> > > Cc: "Ryuji Wakikawa" ; "Julien Laganier" >> > > ; >> > > >> > > Sent: Friday, June 06, 2008 5:22 PM >> > > Subject: Re: [MEXT] Adoption of >> draft-droms-mext-nemo-pd-00.txt? >> > > >> > > >> > > > Hi Frank, >> > > > >> > > > Please see below.. >> > > > >> > > > On Fri, Jun 6, 2008 at 2:40 PM, Frank Xia >> wrote: >> > > >> Hi Fan >> > > >> >> > > >> Please see my reply... >> > > >> >> > > >> BR >> > > >> Frank >> > > >> >> > > >> ----- Original Message ----- From: "fan zhao" >> > > >> > > >> To: "Frank Xia" >> > > >> Cc: "Ryuji Wakikawa" ; "Julien >> > > Laganier" >> > > >> ; >> > > >> Sent: Friday, June 06, 2008 3:33 PM >> > > >> Subject: Re: [MEXT] Adoption of >> draft-droms-mext-nemo-pd-00.txt? >> > > >> >> > > >> >> > > >>> Hi Frank, >> > > >>> >> > > >>> Please see below. >> > > >>> >> > > >>> On Fri, Jun 6, 2008 at 10:51 AM, Frank Xia >> > > >> > > >>> wrote: >> > > >>>> >> > > >>>> Hi Fan, Ryuji and other colleagues. >> > > >>>> >> > > >>>> Agreed. >> > > >>>> >> > > >>>> IMHO,There are two ways for prefix delegation in Nemo, >> > > >>>> that is, overlay and integrated modes. >> > > >>>> >> > > >>>> DHCP based PD is a overlay solution which introduce redundancy >> > > >>>> while trying to reduce impact on NEMO itself. >> > > >>>> >> > > >>>> I favor the integrated mode in which Prefix Delegation is >> integrated >> > > >>>> into >> > > >>>> NEMO operations >> > > >>> >> > > >>> I agree that signaling overhead can be reduced if multiple >> _related_ >> > > >>> requests/responses >> > > >>> are piggybacked together, e.g. during one message exchange. For >> > > the >> MR >> > > >>> to work, it >> > > >>> needs both a HoA/HNP and a MNP. Besides requesting/registering >> > > the >> > > >>> MNP, there is >> > > >>> no much difference between the operation of the MN and that of >> > > the >> MR. >> > > >>> Furthermore, >> > > >>> the MR can request the MNP during the establishment of IPSec SA >> when >> > > >>> it is at either home link or foreign link. >> > > >> >> > > >> Frank=>For adressing in NEMO, there are two categories >> > > >> nodes for addressing, that is, MRs and hosts behind MRs. >> > > >> >> > > >> IKE can be used for MR's addressing, while it probabaly >> > > >> can't be used for host addressing (PD) without extension of IKE. >> > > > >> > > > Fan> We can simply define a new attribute carried in the >> > > > CFG_REQUEST/CFG_REPLY >> > > > configuration payload during the IKE_AUTH exchange. >> > > >> > > Frank=>It couples PD with IKE procedure. How does the >> > > MR renew/release/renumber the prefixes after IKE_AUTH exchange? >> > > Anyway, IKE is not solely for MIP, IMHO, it is not proper to >> > > extend for this purpose. >> > > >> > > IMO, the compromised way is to use BA/BU which >> > > is in line with PMIP thoughtway. >> > > >> > > >> > > > >> > > > >> > > >> >> > > >>> >> > > >>>> because prefix management is an integrated part >> > > >>>> of NEMO. >> > > >>>> PMIPv6 follow the same philosophy. >> > > >>> >> > > >>> If I understand correctly, PMIP is a slightly different case >> > > from >> > > >>> DSMIPv6/NEMO. >> > > >>> Because the connection, such as the IPSec SA, between the MAG >> > > and >> the >> > > >>> LMA >> > > >>> is already in place long before the MN attaches to the MAG, it >> makes >> > > >>> sense >> > > >>> for >> > > >>> the MAG to request the HNP for the MN during the PBU/PBA >> > > exchange. >> With >> > > >>> DSMIPv6, the MN requests the HoA/HNP during the establishment of >> the >> > > >>> IPSec >> > > >>> SA, therefore the MR should request the MNP during this >> > > procedure >> as >> > > >>> well. >> > > >> >> > > >> Frank=>It is true there is difference between PMIP and NEMO. >> > > >> I just do an analogy. What I want to say is it makes sense if >> > > we >> > > >> integrate >> > > >> PD >> > > >> into NEMO. >> > > > >> > > > Fan> OK. >> > > > >> > > > Sincerely, >> > > > fan >> > > > >> > > >> >> > > >>> >> > > >>> What do you think? >> > > >>> >> > > >>> Sincerely, >> > > >>> fan >> > > >>> >> > > >>>> >> > > >>>> BR >> > > >>>> Frank >> > > >>>> >> > > >>>> ----- Original Message ----- From: "fan zhao" >> >> > > >>>> To: "Ryuji Wakikawa" >> > > >>>> Cc: "Julien Laganier" ; >> > > >> > > >>>> Sent: Friday, June 06, 2008 12:18 PM >> > > >>>> Subject: Re: [MEXT] Adoption of >> draft-droms-mext-nemo-pd-00.txt? >> > > >>>> >> > > >>>> >> > > >>>>> Hi Ryuji and et al, >> > > >>>>> >> > > >>>>> Sorry for jumping in. >> > > >>>>> I agree with Ryuji that the DHCP based PD procedure introduces >> > > >>>>> redundancy. >> > > >>>>> IMHO, the MR can request a MNP together with a HNP/HoA when >> > > >>>>> establishing >> > > >>>>> the IPSec SA with the HA. IMO, this is simpler. Do I miss >> something? >> > > >>>>> Thanks. >> > > >>>>> >> > > >>>>> Sincerely, >> > > >>>>> fan >> > > >>>>> >> > > >>>>> >> > > >>>>> On Wed, Jun 4, 2008 at 5:37 PM, Ryuji Wakikawa >> > > >>>>> >> > > >>>>> wrote: >> > > >>>>>> >> > > >>>>>> Hello Pascal, >> > > >>>>>> >> > > >>>>>> Sorry for late response. We have interop event in Tokyo and >> tested >> > > >>>>>> HAHA there;-) >> > > >>>>>> >> > > >>>>>> On 2008/06/03, at 17:08, Pascal Thubert (pthubert) wrote: >> > > >>>>>> >> > > >>>>>>> Hi Ryuji: >> > > >>>>>>> >> > > >>>>>>> I agree that PD should not impact bootstrap. These are and >> should be >> > > >>>>>>> kept unrelated. >> > > >>>>>>> >> > > >>>>>>> We must be able to extend a RFC 3963 MR with PD without >> > > forcing >> the >> > > >>>>>>> bootstrap process in the picture. So I agree not to bring >> > > DHAAD >> back >> > > >>>>>>> into the bootstrap... >> > > >>>>>> >> > > >>>>>> we agree then.. >> > > >>>>>> >> > > >>>>>>> But I think that PD is NOT a bootstrap process. It is post >> bootstrap >> > > >>>>>>> and >> > > >>>>>>> can reoccur many times in the life of the MR. >> > > >>>>>>> >> > > >>>>>>> Until we define a new process and rev 3775 and 3963, we >> > > should >> stay >> > > >>>>>>> consistent and simple in what we are doing. >> > > >>>>>> >> > > >>>>>> DHCP-PD can surely impact to the bootstrap process. >> > > >>>>>> >> > > >>>>>> Let's say MR boots up as a MN with RFC5026 first. >> > > >>>>>> Then, it tries to get a MNP for NEMO. >> > > >>>>>> >> > > >>>>>> If the current HA is not PD-enabled and DHAAD returns >> > > different >> HA, >> > > >>>>>> MR must de-register the binding from the current HA and tries >> > > to >> > > >>>>>> start >> > > >>>>>> all the registration process to the new HA. >> > > >>>>>> >> > > >>>>>> This seems very redundant operation.. >> > > >>>>>> I want to make the PD spec simple. >> > > >>>>>> >> > > >>>>>> regards >> > > >>>>>> ryuji >> > > >>>>>> >> > > >>>>>> >> > > >>>>>> >> > > >>>>>>> >> > > >>>>>>> >> > > >>>>>>> Pascal >> > > >>>>>>> >> > > >>>>>>>> -----Original Message----- >> > > >>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] >> > > On >> > > >>>>>>>> Behalf Of >> > > >>>>>>> >> > > >>>>>>> Ryuji Wakikawa >> > > >>>>>>>> >> > > >>>>>>>> Sent: mardi 3 juin 2008 09:54 >> > > >>>>>>>> To: marcelo bagnulo braun >> > > >>>>>>>> Cc: Julien Laganier; mext@ietf.org >> > > >>>>>>>> Subject: Re: [MEXT] Adoption of >> draft-droms-mext-nemo-pd-00.txt? >> > > >>>>>>>> >> > > >>>>>>>> Hi Marcelo, >> > > >>>>>>>> >> > > >>>>>>>> I agree to accept this as WG doc. >> > > >>>>>>>> >> > > >>>>>>>> I also agree with Romain and Vijay. >> > > >>>>>>>> We don't need extension to DHAAD. >> > > >>>>>>>> Since MR can act as MN, MR should be able to bootstrap with >> the >> > > >>>>>>>> same >> > > >>>>>>>> mechanism of MIP (except for PD). >> > > >>>>>>>> We should not bring DHAAD back in the bootstrap process >> > > only >> for >> > > >>>>>>>> PD. >> > > >>>>>>>> >> > > >>>>>>>> regards, >> > > >>>>>>>> ryuji >> > > >>>>>>>> >> > > >>>>>>>> >> > > >>>>>>>> On 2008/05/30, at 23:51, marcelo bagnulo braun wrote: >> > > >>>>>>>> >> > > >>>>>>>>> Hi, >> > > >>>>>>>>> >> > > >>>>>>>>> We would like to ask the WG what is their opinion about >> accepting >> > > >>>>>>>>> draft-droms-mext-nemo-pd-00.txt as the WG document for the >> Nemo PD >> > > >>>>>>>>> deliverable included in our charter. >> > > >>>>>>>>> >> > > >>>>>>>>> Please provide comments so we cna make some progress on >> > > this >> long >> > > >>>>>>>>> overdue deliverable >> > > >>>>>>>>> >> > > >>>>>>>>> thanks, Julien and marcelo >> > > >>>>>>>>> -------- Mensaje original -------- >> > > >>>>>>>>> Asunto: I-D >> Action:draft-droms-mext-nemo-pd-00.txt >> > > >>>>>>>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >> > > >>>>>>>>> De: Internet-Drafts@ietf.org >> > > >>>>>>>>> Responder a: internet-drafts@ietf.org >> > > >>>>>>>>> Para: i-d-announce@ietf.org >> > > >>>>>>>>> >> > > >>>>>>>>> >> > > >>>>>>>>> >> > > >>>>>>>>> A New Internet-Draft is available from the on-line >> Internet-Drafts >> > > >>>>>>>>> directories. >> > > >>>>>>>>> >> > > >>>>>>>>> Title : DHCPv6 Prefix Delegation for NEMO >> > > >>>>>>>>> Author(s) : R. Droms, et al. >> > > >>>>>>>>> Filename : draft-droms-mext-nemo-pd-00.txt >> > > >>>>>>>>> Pages : 12 >> > > >>>>>>>>> Date : 2008-05-30 >> > > >>>>>>>>> >> > > >>>>>>>>> One aspect of network mobility support is the assignment >> > > of a >> > > >>>>>>>>> prefix >> > > >>>>>>>>> or prefixes to a Mobile Router (MR) for use on the links >> > > in >> the >> > > >>>>>>>>> Mobile Network. DHCPv6 prefix delegation can be used for >> this >> > > >>>>>>>>> configuration task. >> > > >>>>>>>>> >> > > >>>>>>>>> A URL for this Internet-Draft is: >> > > >>>>>>>>> >> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt >> > > >>>>>>>>> >> > > >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >> > > >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >> > > >>>>>>>>> >> > > >>>>>>>>> Below is the data which will enable a MIME compliant mail >> reader >> > > >>>>>>>>> implementation to automatically retrieve the ASCII version >> > > of >> the >> > > >>>>>>>>> Internet-Draft. >> > > >>>>>>>>> >> > > >>>>>>>>> >> > > >>>>>>>>> Content-Type: text/plain >> > > >>>>>>>>> Content-ID: <2008-05-30054232.I-D@ietf.org> >> > > >>>>>>>>> >> > > >>>>>>>>> >> > > >>>>>>>>> >> _______________________________________________ >> > > >>>>>>>>> I-D-Announce mailing list >> > > >>>>>>>>> I-D-Announce@ietf.org >> > > >>>>>>>>> >> https://www.ietf.org/mailman/listinfo/i-d-announce >> > > >>>>>>>>> Internet-Draft directories: >> > > http://www.ietf.org/shadow.html >> > > >>>>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > >>>>>>>>> >> > > >>>>>>>>> >> _______________________________________________ >> > > >>>>>>>>> MEXT mailing list >> > > >>>>>>>>> MEXT@ietf.org >> > > >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >> > > >>>>>>>> >> > > >>>>>>>> >> _______________________________________________ >> > > >>>>>>>> MEXT mailing list >> > > >>>>>>>> MEXT@ietf.org >> > > >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >> > > >>>>>> >> > > >>>>>> _______________________________________________ >> > > >>>>>> MEXT mailing list >> > > >>>>>> MEXT@ietf.org >> > > >>>>>> https://www.ietf.org/mailman/listinfo/mext >> > > >>>>>> >> > > >>>>> _______________________________________________ >> > > >>>>> MEXT mailing list >> > > >>>>> MEXT@ietf.org >> > > >>>>> https://www.ietf.org/mailman/listinfo/mext >> > > >>>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > > >>> >> > > >> >> > > >> >> > > >> >> > > > >> > > >> > > >> > > _______________________________________________ >> > > MEXT mailing list >> > > MEXT@ietf.org >> > > https://www.ietf.org/mailman/listinfo/mext >> > > >> > > >> > >> > >> >> >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 9 11:45:37 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 615393A6CDF; Mon, 9 Jun 2008 11:45:37 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EDA753A6CC7; Mon, 9 Jun 2008 11:45:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080609184506.EDA753A6CC7@core3.amsl.com> Date: Mon, 9 Jun 2008 11:45:04 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D ACTION:draft-ietf-mext-rfc3775bis-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Mobility Support in IPv6 Author(s) : D. Johnson, C. Perkins, J. Arkko Filename : draft-ietf-mext-rfc3775bis-00.txt Pages : 172 Date : 2008-6-3 This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-rfc3775bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-9113811.I-D@ietf.org> --NextPart 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://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Tue Jun 10 00:11:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E46143A69BE; Tue, 10 Jun 2008 00:11:28 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AAE43A69A1 for ; Tue, 10 Jun 2008 00:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82OUVW2UaFnD for ; Tue, 10 Jun 2008 00:11:26 -0700 (PDT) Received: from out1.laposte.net (out2.laposte.net [193.251.214.119]) by core3.amsl.com (Postfix) with ESMTP id B27BE3A68E1 for ; Tue, 10 Jun 2008 00:11:26 -0700 (PDT) Received: from meplus.info (localhost [127.0.0.1]) by mwinf8211.laposte.net (SMTP Server) with ESMTP id 26755700008D for ; Tue, 10 Jun 2008 09:11:46 +0200 (CEST) Received: from klee.local (unknown [212.119.9.178]) by mwinf8211.laposte.net (SMTP Server) with ESMTP id F3E457000088; Tue, 10 Jun 2008 09:11:45 +0200 (CEST) X-ME-UUID: 20080610071145999.F3E457000088@mwinf8211.laposte.net From: Julien Laganier To: Frank Xia Date: Tue, 10 Jun 2008 09:11:41 +0200 User-Agent: KMail/1.9.6 References: <48401470.40706@it.uc3m.es> <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> In-Reply-To: <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806100911.41214.julien.IETF@laposte.net> X-me-spamlevel: not-spam X-me-spamrating: 22.634501 Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Friday 06 June 2008, Frank Xia wrote: > Hi Fan, Ryuji and other colleagues. > > Agreed. > > IMHO,There are two ways for prefix delegation in Nemo, > that is, overlay and integrated modes. > > DHCP based PD is a overlay solution which introduce redundancy > while trying to reduce impact on NEMO itself. > > I favor the integrated mode in which Prefix Delegation is integrated > into NEMO operations because prefix management is an integrated part > of NEMO. =A0 PMIPv6 follow the same philosophy. Hello Frank et. al. We are not going to challenge your technical arguments. We have a WG = consensus on developing *one* solution based on *DHCPv6 PD*, so this is = discussion is in our opinion out of scope since there are no reasons to = revert the WG consensus. The question at this stage is whether we want to make the only proposal = on NEMO prefix delegation based on DHCPv6 PD a WG draft. Thanks in advance for your understanding. Regards, -- julien & marcelo, MEXT chairs _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 10 01:26:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B964D3A69AF; Tue, 10 Jun 2008 01:26:03 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A1743A69AF for ; Tue, 10 Jun 2008 01:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOSsFe4HcZAe for ; Tue, 10 Jun 2008 01:25:52 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by core3.amsl.com (Postfix) with ESMTP id 9569B3A6A3F for ; Tue, 10 Jun 2008 01:25:51 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so1007687and.122 for ; Tue, 10 Jun 2008 01:26:12 -0700 (PDT) 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=grHZA2ZAcXmY0JojcWtEnnXdquC/NNAWYNksaCauiZU=; b=Q5zICqk/hDdGvtN1+abCI3t3GLO2tKf8EteZcVcUYXEjtV17b31/5racCaKEVP0Q79 C5l5uDD+9aRmUTd7l8VMKErktMLL7Ww+jt/m7lR0+1p2LZCKywCSnGrXkR4GhBw8Ka3E wY8lAxNCt1kbByLOyp+LZlfKnAe8aH+pjfN9g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=DzAkiMHC3istWX1eWLz5LRABWYDLZC3e97pgRX/k0WH7pMk/S7S2tRdY0t9tXFCEKe HMTeZM/ehKyxmWmhlp3mRMlR56EUsIwaUS9KOOfXJj9lohvLOUaSWW2UlBzq5xqYZc// r59T0W4q2W0cFFh+Tfz86GW4jU5/g/HfSLmKQ= Received: by 10.100.127.15 with SMTP id z15mr4963806anc.80.1213086369637; Tue, 10 Jun 2008 01:26:09 -0700 (PDT) Received: by 10.100.141.11 with HTTP; Tue, 10 Jun 2008 01:26:09 -0700 (PDT) Message-ID: Date: Tue, 10 Jun 2008 01:26:09 -0700 From: "fan zhao" To: "Julien Laganier" In-Reply-To: <200806100911.41214.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline References: <48401470.40706@it.uc3m.es> <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> <200806100911.41214.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, Marcelo et al, > The question at this stage is whether we want to make the only proposal > on NEMO prefix delegation based on DHCPv6 PD a WG draft. IMHO, the DHCP-PD solution leads to additional signaling overhead; furthermore, using the DHCP Authentication Option introduces another layer of overhead/redundancy. Therefore, my oponion is DHCP-PD should not be the only solution. RFC 5026 describes the procedure for the MN to dynamically obtain the home address from the network using the IKEv2. As defined in RFC 3753, a MN could be either a MR or MH. Therefore it is natural to define extensions in the IKEv2 for the MR to request the MNP, which is more efficient and secure. Thanks. Sincerely, fan On Tue, Jun 10, 2008 at 12:11 AM, Julien Laganier wrote: > On Friday 06 June 2008, Frank Xia wrote: >> Hi Fan, Ryuji and other colleagues. >> >> Agreed. >> >> IMHO,There are two ways for prefix delegation in Nemo, >> that is, overlay and integrated modes. >> >> DHCP based PD is a overlay solution which introduce redundancy >> while trying to reduce impact on NEMO itself. >> >> I favor the integrated mode in which Prefix Delegation is integrated >> into NEMO operations because prefix management is an integrated part >> of NEMO. PMIPv6 follow the same philosophy. > > Hello Frank et. al. > > > > We are not going to challenge your technical arguments. We have a WG > consensus on developing *one* solution based on *DHCPv6 PD*, so this is > discussion is in our opinion out of scope since there are no reasons to > revert the WG consensus. > > The question at this stage is whether we want to make the only proposal > on NEMO prefix delegation based on DHCPv6 PD a WG draft. > > Thanks in advance for your understanding. > > Regards, > > -- julien & marcelo, MEXT chairs > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 10 02:01:10 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B94D3A6A05; Tue, 10 Jun 2008 02:01:10 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 946323A6A05 for ; Tue, 10 Jun 2008 02:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrSMmOOc2Vtx for ; Tue, 10 Jun 2008 02:01:08 -0700 (PDT) Received: from out5.laposte.net (out6.laposte.net [193.251.214.123]) by core3.amsl.com (Postfix) with ESMTP id A01513A69E1 for ; Tue, 10 Jun 2008 02:01:08 -0700 (PDT) Received: from meplus.info (localhost [127.0.0.1]) by mwinf8407.laposte.net (SMTP Server) with ESMTP id D4257700009F for ; Tue, 10 Jun 2008 11:01:24 +0200 (CEST) Received: from klee.local (unknown [212.119.9.178]) by mwinf8407.laposte.net (SMTP Server) with ESMTP id 8D12E700008F; Tue, 10 Jun 2008 11:01:24 +0200 (CEST) X-ME-UUID: 20080610090124577.8D12E700008F@mwinf8407.laposte.net From: Julien Laganier To: "fan zhao" Date: Tue, 10 Jun 2008 11:01:22 +0200 User-Agent: KMail/1.9.6 References: <48401470.40706@it.uc3m.es> <200806100911.41214.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806101101.22875.julien.IETF@laposte.net> X-me-spamlevel: not-spam X-me-spamrating: 25.199565 Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Tuesday 10 June 2008, fan zhao wrote: > Hi Julien, Marcelo et al, > > > The question at this stage is whether we want to make the only > > proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft. > > IMHO, the DHCP-PD solution leads to additional signaling overhead; For the record I'm going to reply *once* to your technical input with WG chair hat off. Signaling overhead is a non-issue in the context of prefix delegation since it will only happen once, when a MN becomes a MR. > furthermore, using the DHCP Authentication Option introduces another > layer of overhead/redundancy. If this is a concern, the NEMO prefix delegation might not use the DHCP authentication option, and protect the DHCP PD signalling with an IPsec b/w MR and HA. The WG can decide what it wants. > Therefore, my oponion is DHCP-PD should not be the only solution. This is not to be discussed: We are chartered to specify one solution. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 10 02:05:28 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1113A684B; Tue, 10 Jun 2008 02:05:27 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95D163A684B for ; Tue, 10 Jun 2008 02:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.282 X-Spam-Level: X-Spam-Status: No, score=-6.282 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 366Hjmeqeq1K for ; Tue, 10 Jun 2008 02:05:23 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 1C2EE3A6840 for ; Tue, 10 Jun 2008 02:05:22 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-153.messagelabs.com!1213088739!6221684!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 29577 invoked from network); 10 Jun 2008 09:05:39 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-10.tower-153.messagelabs.com with SMTP; 10 Jun 2008 09:05:39 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m5A95cHg017159 for ; Tue, 10 Jun 2008 02:05:38 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id m5A95bPx011600 for ; Tue, 10 Jun 2008 04:05:38 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id m5A95XxV011528 for ; Tue, 10 Jun 2008 04:05:36 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 10:05:08 +0100 Message-ID: <484E43D4.7020108@gmail.com> Date: Tue, 10 Jun 2008 11:05:24 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: fan zhao References: <48401470.40706@it.uc3m.es> <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> <200806100911.41214.julien.IETF@laposte.net> In-Reply-To: X-Antivirus: avast! (VPS 080609-2, 09/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 10 Jun 2008 09:05:08.0504 (UTC) FILETIME=[14C22180:01C8CAD9] X-CFilter-Loop: Reflected Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Fan and thank you for the other private email, I take advantage of this to reply publicly. fan zhao wrote: > Hi Julien, Marcelo et al, > >> The question at this stage is whether we want to make the only >> proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft. WEll I agree in principle, provided authors are open to feedback from implementation and ready to modify it further. > IMHO, the DHCP-PD solution leads to additional signaling overhead; > furthermore, using the DHCP Authentication Option introduces another > layer of overhead/redundancy. Therefore, my oponion is DHCP-PD should > not be the only solution. Well DHCP-PD through the secured MR-HA tunnel wouldn't use DHCP auth option. > RFC 5026 describes the procedure for the MN to dynamically obtain the > home address from the network using the IKEv2. As defined in RFC > 3753, a MN could be either a MR or MH. Therefore it is natural to > define extensions in the IKEv2 for the MR to request the MNP, which > is more efficient and secure. I'm not sure using IKEv2 to obtain MNP is more efficient than DHCP, at least because IKEv2 has much more roundtrips than DHCP, so it could be considered heavier (or less efficient). Alex > > Thanks. > > Sincerely, fan > > > > > On Tue, Jun 10, 2008 at 12:11 AM, Julien Laganier > wrote: >> On Friday 06 June 2008, Frank Xia wrote: >>> Hi Fan, Ryuji and other colleagues. >>> >>> Agreed. >>> >>> IMHO,There are two ways for prefix delegation in Nemo, that is, >>> overlay and integrated modes. >>> >>> DHCP based PD is a overlay solution which introduce redundancy >>> while trying to reduce impact on NEMO itself. >>> >>> I favor the integrated mode in which Prefix Delegation is >>> integrated into NEMO operations because prefix management is an >>> integrated part of NEMO. PMIPv6 follow the same philosophy. >> Hello Frank et. al. >> >> >> >> We are not going to challenge your technical arguments. We have a >> WG consensus on developing *one* solution based on *DHCPv6 PD*, so >> this is discussion is in our opinion out of scope since there are >> no reasons to revert the WG consensus. >> >> The question at this stage is whether we want to make the only >> proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft. >> >> Thanks in advance for your understanding. >> >> Regards, >> >> -- julien & marcelo, MEXT chairs >> >> > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 10 02:15:23 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E206D3A68EE; Tue, 10 Jun 2008 02:15:23 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340423A68EE for ; Tue, 10 Jun 2008 02:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqqoyRjPi9Id for ; Tue, 10 Jun 2008 02:15:22 -0700 (PDT) Received: from out1.laposte.net (out2.laposte.net [193.251.214.119]) by core3.amsl.com (Postfix) with ESMTP id 3FC5C3A67DB for ; Tue, 10 Jun 2008 02:15:21 -0700 (PDT) Received: from meplus.info (localhost [127.0.0.1]) by mwinf8218.laposte.net (SMTP Server) with ESMTP id 90AEFE000088 for ; Tue, 10 Jun 2008 11:15:42 +0200 (CEST) Received: from klee.local (unknown [212.119.9.178]) by mwinf8218.laposte.net (SMTP Server) with ESMTP id 508E5E000084; Tue, 10 Jun 2008 11:15:39 +0200 (CEST) X-ME-UUID: 20080610091539330.508E5E000084@mwinf8218.laposte.net From: Julien Laganier To: Alexandru Petrescu Date: Tue, 10 Jun 2008 11:15:37 +0200 User-Agent: KMail/1.9.6 References: <48401470.40706@it.uc3m.es> <484E43D4.7020108@gmail.com> In-Reply-To: <484E43D4.7020108@gmail.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806101115.37624.julien.IETF@laposte.net> X-me-spamlevel: not-spam X-me-spamrating: 15.786402 Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Alex, On Tuesday 10 June 2008, Alexandru Petrescu wrote: > > fan zhao wrote: > > Hi Julien, Marcelo et al, > > > >> The question at this stage is whether we want to make the only > >> proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft. > > WEll I agree in principle, provided authors are open to feedback from > implementation and ready to modify it further. Just for clarification, if the draft becomes a WG draft, it will of course be subject to modifications as per the WG consensus. This is the IETF process > > IMHO, the DHCP-PD solution leads to additional signaling overhead; > > furthermore, using the DHCP Authentication Option introduces > > another layer of overhead/redundancy. Therefore, my oponion is > > DHCP-PD should not be the only solution. > > Well DHCP-PD through the secured MR-HA tunnel wouldn't use DHCP auth > option. This is my understanding as well. > > RFC 5026 describes the procedure for the MN to dynamically obtain > > the home address from the network using the IKEv2. As defined in > > RFC 3753, a MN could be either a MR or MH. Therefore it is natural > > to define extensions in the IKEv2 for the MR to request the MNP, > > which is more efficient and secure. > > I'm not sure using IKEv2 to obtain MNP is more efficient than DHCP, > at least because IKEv2 has much more roundtrips than DHCP, so it > could be considered heavier (or less efficient). And bottom line is that optimizing the efficiency of a one round-trip process that happens once when the MR boots up, and not in any critical path (e.g. handover) at the expense of modularity is questionable, IMHO. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 10 02:17:09 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E6E3A6A82; Tue, 10 Jun 2008 02:17:09 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A3203A69E9 for ; Tue, 10 Jun 2008 02:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xiElU1u6jaJ for ; Tue, 10 Jun 2008 02:17:07 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by core3.amsl.com (Postfix) with ESMTP id 1B6EF28B56A for ; Tue, 10 Jun 2008 02:17:07 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so1012619and.122 for ; Tue, 10 Jun 2008 02:17:28 -0700 (PDT) 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=KaakZyp6bTczAlueCvGbiLiZZdubxbqEw+llfLqKrSI=; b=IQEEH4Er3+KRFjMNJfwtZPIaWQnKguSLg9RH+wn6Wtbp5PdbrRWupnf+O4OKVftBBj ycI7TvRNxDcetTrmm4za40Ta81l/q4TKcXsK5UfLt04/pO7GyF0SBJNscN92899NVFP1 1D+ahG4KboF6uJcY6JOubTGCiiNKfmGTgI8Bo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=fBBoapter9T8IRupzf77i/E4d6hEgi3O/STQsJRagRT+lvCUgykFNk+HMxcnCZrA1i dz+JIoJjoJin3h8+or/SrRIUt167HJae/rBmo8gm7BKpomtZwxqx+C62JvtvEV2hT4Fl /UjyTlZsVDlSGCXNvW8bHaZyA9nLflyWTaHDA= Received: by 10.100.125.12 with SMTP id x12mr4974048anc.159.1213089447994; Tue, 10 Jun 2008 02:17:27 -0700 (PDT) Received: by 10.100.141.11 with HTTP; Tue, 10 Jun 2008 02:17:27 -0700 (PDT) Message-ID: Date: Tue, 10 Jun 2008 02:17:27 -0700 From: "fan zhao" To: "Julien Laganier" In-Reply-To: <200806101101.22875.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline References: <48401470.40706@it.uc3m.es> <200806100911.41214.julien.IETF@laposte.net> <200806101101.22875.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, Thanks for your reply. Please see below. On Tue, Jun 10, 2008 at 2:01 AM, Julien Laganier wrote: > On Tuesday 10 June 2008, fan zhao wrote: >> Hi Julien, Marcelo et al, >> >> > The question at this stage is whether we want to make the only >> > proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft. >> >> IMHO, the DHCP-PD solution leads to additional signaling overhead; > > For the record I'm going to reply *once* to your technical input with WG > chair hat off. > > Signaling overhead is a non-issue in the context of prefix delegation > since it will only happen once, when a MN becomes a MR. It also holds true for the IKEv2 based approach: the MR can just request once. What I want to say is under the same condication, the IKEv2 based approach is more efficient. > >> furthermore, using the DHCP Authentication Option introduces another >> layer of overhead/redundancy. > > If this is a concern, the NEMO prefix delegation might not use the DHCP > authentication option, and protect the DHCP PD signalling with an IPsec > b/w MR and HA. The WG can decide what it wants. Sure. Sorry we do not have a draft to describe the IKEv2 based approach yet. Once it is uploaded, I hope it can make it clearer. > >> Therefore, my oponion is DHCP-PD should not be the only solution. > > This is not to be discussed: We are chartered to specify one solution. Ok, I correct myself: my oponion is DHCP-PD should not be the solution. Sincerely, fan > > --julien > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 10 02:47:20 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A92DD3A69E0; Tue, 10 Jun 2008 02:47:20 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F146B3A69E0 for ; Tue, 10 Jun 2008 02:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFKwRuXXRlLh for ; Tue, 10 Jun 2008 02:47:16 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by core3.amsl.com (Postfix) with ESMTP id 043FA3A68EE for ; Tue, 10 Jun 2008 02:47:15 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so1015503and.122 for ; Tue, 10 Jun 2008 02:47:35 -0700 (PDT) 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=q7LbUXOhN8wO9BgNywIWT3N1Xmkundw43aZ+Wm4AfCI=; b=wgM/7qJiW+FdFNjnnKCDNYXC+rQWGECt0em58NhjJ7+b89kvfSJyG2PBCfWlhemyv/ gWtxpATvkzKYBSDtufQRrNp8lrgz9sOQ0D6NuySQ0s8FsJ6/HxDfw7GbjL5eXC/zN4Xa NhS8vJ9O2n4RBSECPgSdvqdyd70pPuEl76yQc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=qugK2cMHK5IlKj/e73lNQ82pw513BdQw3mCM3rc12KB8T+CDx4PN6IgokHCGie6y28 Fxmn0/UEKnifZizqFeTEoo8eUBriMZAYK7FUlm/34ZvE7/PuuAslfgQE8sYOOLu2c4/z L5Vz4bnPSCjVSI0VIbUXXvl6Ob05qXSaoryz0= Received: by 10.100.173.9 with SMTP id v9mr5100435ane.39.1213091255007; Tue, 10 Jun 2008 02:47:35 -0700 (PDT) Received: by 10.100.141.11 with HTTP; Tue, 10 Jun 2008 02:47:34 -0700 (PDT) Message-ID: Date: Tue, 10 Jun 2008 02:47:34 -0700 From: "fan zhao" To: "Alexandru Petrescu" In-Reply-To: <484E43D4.7020108@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <48401470.40706@it.uc3m.es> <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> <200806100911.41214.julien.IETF@laposte.net> <484E43D4.7020108@gmail.com> Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Alex, Thanks for your reply. Sorry I could not reply you earlier. On Tue, Jun 10, 2008 at 2:05 AM, Alexandru Petrescu wrote: > Hi Fan and thank you for the other private email, I take advantage of this > to reply publicly. > > fan zhao wrote: >> >> Hi Julien, Marcelo et al, >> >>> The question at this stage is whether we want to make the only >>> proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft. > > WEll I agree in principle, provided authors are open to feedback from > implementation and ready to modify it further. > >> IMHO, the DHCP-PD solution leads to additional signaling overhead; >> furthermore, using the DHCP Authentication Option introduces another >> layer of overhead/redundancy. Therefore, my oponion is DHCP-PD should >> not be the only solution. > > Well DHCP-PD through the secured MR-HA tunnel wouldn't use DHCP auth option. I agree. The secured MR-HA tunnel relies on the IPSec SA. The IPSec SA is established when the MR powers up. During the IPSec SA establishment with the HA, the MR can request its home address and the MNP using the configuration payload. > >> RFC 5026 describes the procedure for the MN to dynamically obtain the >> home address from the network using the IKEv2. As defined in RFC >> 3753, a MN could be either a MR or MH. Therefore it is natural to >> define extensions in the IKEv2 for the MR to request the MNP, which >> is more efficient and secure. > > I'm not sure using IKEv2 to obtain MNP is more efficient than DHCP, at least > because IKEv2 has much more roundtrips than DHCP, so it could be considered > heavier (or less efficient). Alex, the following is the comparison between the DHCP-PD and the IKE-PD. DHCP-PD: Assume that the MR is not at the home link, when the MR powers up using CMIP, it follows the bootstrapping procedure as a MN: first, it obtains a local IP address as CoA; second, it obtains the IP address of the HA; third, it establishes the IPSec SA with the HA, during this procedure, the MR obtains a HoA; fourth, the MR compares the HoA with the previously configured IP address, i.e CoA and the MR determines that it is not at home; therefore it sends a BU to the HA to reg the binding between HoA and CoA and receives a BA; fifth, based on its configuration, the MR realizes it should act as a MR and obtain a MNP. With the DHCP based approach, the MR sends a DHCP solicit message to the HA and the MR receives a DHCP reply message. Now the PD is completed. IKE-PD: Assume that the MR is not at home link, ... first, it obtains a local IP address as CoA; second, it obtains the IP address of the HA; third, it establishes the IPSec SA with the HA, during this procedure, the MR obtains a HoA and a MNP based its configuration; fourth, the MR compares the HoA with the previously configured IP address, i.e CoA and the MR determines that it is not at home; therefore it sends a BU to the HA to register the binding between HoA and MNP and CoA and receives a BA. Note that we conclude before the home link detection is based on the IKE. Therefore, the MN also performs 1) to 4) when it is on its home link. So with the IKE-PD, the MN does not need to send and receive the DHCP messages. It is also not as simple as saving two messages. Consider this case: the MN needs to set up an additional IPSec child SA to protect the data traffic. This is done after the IPSec SA is performed. With the DHCP-PD, if the MN performs the Child SA establishment for the traffic from/to itself before the DHCP-PD, then after DHCP-PD, the MN needs to set up another child SA to protect the traffic to/from the MNNs. If the MN performs the Child SA establishment for the traffic from/to itself after the DHCP-PD, this means the commnucation between MN and CN is delayed. therefore, when the MN handovers from a PMIP domain to a target access network using CMIP. DHCP-PD would result in more delay. With the IKE-PD, since the MN knows its HoA and MNP at the same time, it can immediately set up one Child SA to protect the traffic from/to itself and the MNNs. Do I miss something? Thanks. Sincerely, fan > > Alex > >> >> Thanks. >> >> Sincerely, fan >> >> >> >> >> On Tue, Jun 10, 2008 at 12:11 AM, Julien Laganier >> wrote: >>> >>> On Friday 06 June 2008, Frank Xia wrote: >>>> >>>> Hi Fan, Ryuji and other colleagues. >>>> >>>> Agreed. >>>> >>>> IMHO,There are two ways for prefix delegation in Nemo, that is, >>>> overlay and integrated modes. >>>> >>>> DHCP based PD is a overlay solution which introduce redundancy while >>>> trying to reduce impact on NEMO itself. >>>> >>>> I favor the integrated mode in which Prefix Delegation is >>>> integrated into NEMO operations because prefix management is an >>>> integrated part of NEMO. PMIPv6 follow the same philosophy. >>> >>> Hello Frank et. al. >>> >>> >>> >>> We are not going to challenge your technical arguments. We have a >>> WG consensus on developing *one* solution based on *DHCPv6 PD*, so >>> this is discussion is in our opinion out of scope since there are >>> no reasons to revert the WG consensus. >>> >>> The question at this stage is whether we want to make the only >>> proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft. >>> >>> Thanks in advance for your understanding. >>> >>> Regards, >>> >>> -- julien & marcelo, MEXT chairs >>> >>> >> _______________________________________________ MEXT mailing list >> MEXT@ietf.org https://www.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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 10 02:51:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B01463A69EA; Tue, 10 Jun 2008 02:51:00 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D80973A69E9 for ; Tue, 10 Jun 2008 02:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obVWYyFuvBNh for ; Tue, 10 Jun 2008 02:50:58 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by core3.amsl.com (Postfix) with ESMTP id 95D4F3A69EA for ; Tue, 10 Jun 2008 02:50:58 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so1015857and.122 for ; Tue, 10 Jun 2008 02:51:18 -0700 (PDT) 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=8rkjlWvTvgXMnVdMU7YhGemMTlhcSxq/i2JhbYZmB4Y=; b=wbLBIQZS+gLMh0bKU7DJe52ir8SutB0FR4BhOmpC4ssmSoU3VNA+qcWufhBndVFThq f/oEZFfJS3tnSFvweJGnJYotCZRwXzRb5bMF1K7EDVxT12ru/X6DWq1uWS7lrohIfYns NBRTBqko4D5KYEWltURkRFzIKmwfSTgZim7fc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=nKvbTO6urCy/RkxoiG0JfWqvq0gGcAylx8yO6lI42ibzZ8ZCL5itGMkopVIAjxr3un a2kG92DMSFL5zBrnBCBvVh3EwbQvpOidIuTv/771Z2dW6HqGMi5Fz2FMsU2iO3i/g6p8 eL+25wCAVk9kvkdUGYBZ0SgUo0KRhzU+OcaFk= Received: by 10.100.123.4 with SMTP id v4mr5050550anc.107.1213091477954; Tue, 10 Jun 2008 02:51:17 -0700 (PDT) Received: by 10.100.141.11 with HTTP; Tue, 10 Jun 2008 02:51:17 -0700 (PDT) Message-ID: Date: Tue, 10 Jun 2008 02:51:17 -0700 From: "fan zhao" To: "Alexandru Petrescu" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <48401470.40706@it.uc3m.es> <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> <200806100911.41214.julien.IETF@laposte.net> <484E43D4.7020108@gmail.com> Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Sorry I miss one more step with the DHCP-PD when the MR is not at home link. Please see below. On Tue, Jun 10, 2008 at 2:47 AM, fan zhao wrote: > Hi Alex, > > Thanks for your reply. Sorry I could not reply you earlier. > > On Tue, Jun 10, 2008 at 2:05 AM, Alexandru Petrescu > wrote: >> Hi Fan and thank you for the other private email, I take advantage of this >> to reply publicly. >> >> fan zhao wrote: >>> >>> Hi Julien, Marcelo et al, >>> >>>> The question at this stage is whether we want to make the only >>>> proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft. >> >> WEll I agree in principle, provided authors are open to feedback from >> implementation and ready to modify it further. >> >>> IMHO, the DHCP-PD solution leads to additional signaling overhead; >>> furthermore, using the DHCP Authentication Option introduces another >>> layer of overhead/redundancy. Therefore, my oponion is DHCP-PD should >>> not be the only solution. >> >> Well DHCP-PD through the secured MR-HA tunnel wouldn't use DHCP auth option. > I agree. The secured MR-HA tunnel relies on the IPSec SA. The IPSec SA > is established > when the MR powers up. > During the IPSec SA establishment with the HA, the MR can request its > home address and the > MNP using the configuration payload. > >> >>> RFC 5026 describes the procedure for the MN to dynamically obtain the >>> home address from the network using the IKEv2. As defined in RFC >>> 3753, a MN could be either a MR or MH. Therefore it is natural to >>> define extensions in the IKEv2 for the MR to request the MNP, which >>> is more efficient and secure. >> >> I'm not sure using IKEv2 to obtain MNP is more efficient than DHCP, at least >> because IKEv2 has much more roundtrips than DHCP, so it could be considered >> heavier (or less efficient). > > Alex, the following is the comparison between the DHCP-PD and the IKE-PD. > > DHCP-PD: > Assume that the MR is not at the home link, when the MR powers up using CMIP, > it follows the bootstrapping procedure as a MN: first, it obtains a > local IP address as CoA; > second, it obtains the IP address of the HA; third, it establishes the > IPSec SA with the HA, > during this procedure, the MR obtains a HoA; fourth, the MR compares > the HoA with > the previously configured IP address, i.e CoA and the MR determines > that it is not at home; > therefore it sends a BU to the HA to reg the binding between HoA and > CoA and receives a BA; fifth, > based on its configuration, the MR realizes it should act as a MR and > obtain a MNP. With the > DHCP based approach, the MR sends a DHCP solicit message to the HA and > the MR receives > a DHCP reply message. Now the PD is completed. One more step for the MR is that now the MR needs to send the BU message again to the HA to register the binding between the HoA, the MNP and the CoA. > > IKE-PD: > Assume that the MR is not at home link, ... first, it obtains a local > IP address as CoA; > second, it obtains the IP address of the HA; third, it establishes the > IPSec SA with the HA, > during this procedure, the MR obtains a HoA and a MNP based its > configuration; fourth, the MR compares the HoA with > the previously configured IP address, i.e CoA and the MR determines > that it is not at home; > therefore it sends a BU to the HA to register the binding between HoA > and MNP and CoA and receives a BA. > > Note that we conclude before the home link detection is based on the > IKE. Therefore, the MN also > performs 1) to 4) when it is on its home link. So with the IKE-PD, the > MN does not need to send and > receive the DHCP messages. > > It is also not as simple as saving two messages. It is also not as simple as saving four messages (two dhcp messages plus BU/BA). That is all. Thanks for reading. Sincerely, fan > Consider this case: the MN needs to set up an additional IPSec child > SA to protect the data traffic. > This is done after the IPSec SA is performed. With the DHCP-PD, if the > MN performs the Child SA > establishment for the traffic from/to itself before the DHCP-PD, then > after DHCP-PD, the MN needs to > set up another child SA to protect the traffic to/from the MNNs. If > the MN performs the Child SA > establishment for the traffic from/to itself after the DHCP-PD, this > means the commnucation between > MN and CN is delayed. therefore, when the MN handovers from a PMIP > domain to a target access network > using CMIP. DHCP-PD would result in more delay. > With the IKE-PD, since the MN knows its HoA and MNP at the same time, > it can immediately set > up one Child SA to protect the traffic from/to itself and the MNNs. > > Do I miss something? Thanks. > > Sincerely, > fan > >> >> Alex >> >>> >>> Thanks. >>> >>> Sincerely, fan >>> >>> >>> >>> >>> On Tue, Jun 10, 2008 at 12:11 AM, Julien Laganier >>> wrote: >>>> >>>> On Friday 06 June 2008, Frank Xia wrote: >>>>> >>>>> Hi Fan, Ryuji and other colleagues. >>>>> >>>>> Agreed. >>>>> >>>>> IMHO,There are two ways for prefix delegation in Nemo, that is, >>>>> overlay and integrated modes. >>>>> >>>>> DHCP based PD is a overlay solution which introduce redundancy while >>>>> trying to reduce impact on NEMO itself. >>>>> >>>>> I favor the integrated mode in which Prefix Delegation is >>>>> integrated into NEMO operations because prefix management is an >>>>> integrated part of NEMO. PMIPv6 follow the same philosophy. >>>> >>>> Hello Frank et. al. >>>> >>>> >>>> >>>> We are not going to challenge your technical arguments. We have a >>>> WG consensus on developing *one* solution based on *DHCPv6 PD*, so >>>> this is discussion is in our opinion out of scope since there are >>>> no reasons to revert the WG consensus. >>>> >>>> The question at this stage is whether we want to make the only >>>> proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft. >>>> >>>> Thanks in advance for your understanding. >>>> >>>> Regards, >>>> >>>> -- julien & marcelo, MEXT chairs >>>> >>>> >>> _______________________________________________ MEXT mailing list >>> MEXT@ietf.org https://www.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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 10 05:48:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACD083A6AC0; Tue, 10 Jun 2008 05:48:40 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5D3E3A6918; Tue, 10 Jun 2008 05:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOnpAzWExGMs; Tue, 10 Jun 2008 05:48:36 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 42FEB3A68BD; Tue, 10 Jun 2008 05:48:33 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1K63HN-0002Dl-Ut; Tue, 10 Jun 2008 14:48:50 +0200 X-Hashcash: 1:20:080610:mext@ietf.org::1XHiXbQLG6GsfE95:0000AGdz X-Hashcash: 1:20:080610:ipsec@ietf.org::C8ChjT5ErotwvdBg:00029FY From: arno@natisbad.org (Arnaud Ebalard) To: IETF MEXT WG X-GnuPG-Key: 0x047A5026 Date: Tue, 10 Jun 2008 14:48:42 +0200 Message-ID: <87d4mp5uc5.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: IETF IPsec WG Subject: [MEXT] Clarifications on dynamic HoA assignment by IKE (RFC 4877 and 5026) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2041746722==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============2041746722== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Hi, I just read again RFC 4877 and RFC 5026 (and related sections of RFC 4306) and I have questions. IPsec WG is in Cc; sorry if you receive the mail twice and also for its length. In RFC 4877, it is written that "the home agent and the mobile node MAY support remote configuration of the home address". This is specifically covered in Section 9 but there are related notes in other parts of the document. Simply put, my questions would be: "What are the *detailed* steps by which IKE negotiation will be *triggered* on the Mobile Node in the process of getting a HoA dynamically assigned? How is the address provided to the MIPv6 module?". More precisely, I'd like to clarify the following points: SPD entries provided in section 7.2.1 make use of home_address_1 which might not be available yet (at least on the mobile node). This is commented after the SPD entries: "In the examples shown above, the home address of the mobile node might not be available all the time. For instance, the mobile node might not have configured a home address yet. When the mobile node acquires a new home address, it must either add the address to the corresponding SPD entries or create the SPD entries for the home address." Associated questions are: o Which address should be used meanwhile (in the SPD entries on the MN, for instance)? o how will the IKE negotiation be triggered, i.e. by which packet? o how can the SPD entries be added afterwhile if they are supposed to trigger IKE negotiation? I think I have missed something in the reference documents because I am under the impression that *something* makes IKE start a negotiation without any SPD related event (like a packet matching a SP and asking for protection) to get a HoA, but I am unable to find what. Is it implicitly expected that the IKE daemon starts an IKE_AUTH exchange to grab a HoA on its own? What is controlled by MIPv6 / what is not? How? I'll appreciate some feedback on that. Now, regarding RFC 5026, there are 7 references to RFC 4877: the use of previous HoA assignement is also listed based on content of RFC 4877 and another mechanism (section 5.3.2, HoA Auto-Configuration by the Mobile Node) which allows the MN to get the prefix it should use to autoconfigure an address it will then send back to the HA. Like previous HoA assignment, the prefix is obtained using IKEv2 during IKE_AUTH exchange. Basically, I have the same questions as for dynamic HoA assignement above. How are things triggered? Who controls what? How is the synchronization between IKE and MIPv6 performed? In the end, after reading those 2 documents, I am under the impression (do not hesitate to correct me) that the MIPv6 process on the MN has the ability to *trigger* an IKE negotiation with the IKE daemon on its HA for the purpose of configuring its HoA. I am also under the impression that this neogiation is not the result of an SPD lookup indicating that a queued packet requires protection.=20 Then I looked at RFC 4306 to find some answers. There are some elements on the topic in Section 1.1.3, at the end of section 2.9, in section 2.19 and in section 3.15 but the scenario where IKE starts negotiation and gets the HoA on its own just looks odd. In RFC 3776 (for static and dynamic keying) and for statically assigned HoA in RFC 4877, MIPv6 module handles HoA, and IKE acts accordingly (yes, it needs some modification to bootstrap) but in the dynamic assignment case, the scenario is reversed and IKE starts and "configures" MIPv6 (at least for the HoA part). This is not explicitly stated (if my understanding and descriptions are correct) and the details are missing in associated document (AFAICT).=20=20 When reading RFC 4877 and RFC 5026, I was under the impression that MIPv6 and IKE are expected to be one unique entity. I wonder how it will be possible in that context to have separate IKEv2 and MIPv6 implementations interoperate on the same MN, HA or MR. If I missed some documents, don't hesitate to tell. Thanks, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFITngwAlWVfAR6UCYRAhwtAJ96meg1qMHo83whhuSKCBnK0QnEYQCdGCgs I3qX1Ng6UOBQrF4VBsUpD/4= =JVoV -----END PGP SIGNATURE----- --=-=-=-- --===============2041746722== 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://www.ietf.org/mailman/listinfo/mext --===============2041746722==-- From mext-bounces@ietf.org Tue Jun 10 07:58:01 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566413A6937; Tue, 10 Jun 2008 07:58:01 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B04C3A6937 for ; Tue, 10 Jun 2008 07:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QT3UPuAJgRLm for ; Tue, 10 Jun 2008 07:57:59 -0700 (PDT) Received: from web84315.mail.re1.yahoo.com (web84315.mail.re1.yahoo.com [69.147.74.194]) by core3.amsl.com (Postfix) with SMTP id 2AC093A6839 for ; Tue, 10 Jun 2008 07:57:59 -0700 (PDT) Received: (qmail 77911 invoked by uid 60001); 10 Jun 2008 14:58:17 -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=G2p+3Cd8OgDC8D7UFPNmJP7Ce+II8nCQPMy5uafdbQQPUEVae7fwHpM2K0Z0cheobpUauqYsi+9oQQgejLTY6UgVDbMEWqrij7ckfuAI/XOxcd1gL+sATCtfdvWJxMDQnh/HnaleoMxi/tkcZIVduSBJdU8hmpgDkky13bFhuqk=; X-YMail-OSG: drETSDYVM1nNPCJX229uVkwkYyxBc6Z1uhyCBMtlkBhCg.4LCkudANSjXw9wcXIvw2m4zyd1qCIuN3qD0cVNAdYFYPh4m0L8GAMZl6QDGaWFwaKFfuuLTp0- Received: from [206.16.17.212] by web84315.mail.re1.yahoo.com via HTTP; Tue, 10 Jun 2008 07:58:16 PDT X-Mailer: YahooMailRC/975.41 YahooMailWebService/0.7.185 Date: Tue, 10 Jun 2008 07:58:16 -0700 (PDT) From: Behcet Sarikaya To: Julien Laganier MIME-Version: 1.0 Message-ID: <179893.77457.qm@web84315.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 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="===============0268995675==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0268995675== Content-Type: multipart/alternative; boundary="0-181338345-1213109896=:77457" --0-181338345-1213109896=:77457 Content-Type: text/plain; charset=us-ascii Hi Julien, First of all the consensus was on DHCP-PD not necessarily DHCP-PD from MR. So the idea of IKE-PD could as well be considered in-line with the consensus. DHCP-PD from MR has several disadvantages such as additional software on the upstream interface of MR be it for a one-time use as you stated. Regards, Behcet ----- Original Message ---- From: Julien Laganier To: Alexandru Petrescu Cc: mext@ietf.org Sent: Tuesday, June 10, 2008 4:15:37 AM Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Hello Alex, On Tuesday 10 June 2008, Alexandru Petrescu wrote: > > fan zhao wrote: > > Hi Julien, Marcelo et al, > > > >> The question at this stage is whether we want to make the only > >> proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft. > > WEll I agree in principle, provided authors are open to feedback from > implementation and ready to modify it further. Just for clarification, if the draft becomes a WG draft, it will of course be subject to modifications as per the WG consensus. This is the IETF process > > IMHO, the DHCP-PD solution leads to additional signaling overhead; > > furthermore, using the DHCP Authentication Option introduces > > another layer of overhead/redundancy. Therefore, my oponion is > > DHCP-PD should not be the only solution. > > Well DHCP-PD through the secured MR-HA tunnel wouldn't use DHCP auth > option. This is my understanding as well. > > RFC 5026 describes the procedure for the MN to dynamically obtain > > the home address from the network using the IKEv2. As defined in > > RFC 3753, a MN could be either a MR or MH. Therefore it is natural > > to define extensions in the IKEv2 for the MR to request the MNP, > > which is more efficient and secure. > > I'm not sure using IKEv2 to obtain MNP is more efficient than DHCP, > at least because IKEv2 has much more roundtrips than DHCP, so it > could be considered heavier (or less efficient). And bottom line is that optimizing the efficiency of a one round-trip process that happens once when the MR boots up, and not in any critical path (e.g. handover) at the expense of modularity is questionable, IMHO. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-181338345-1213109896=:77457 Content-Type: text/html; charset=us-ascii
Hi Julien,
  First of all the consensus was on DHCP-PD not necessarily DHCP-PD from MR. So the idea of IKE-PD could as well be considered in-line with the consensus.
  DHCP-PD from MR has several disadvantages such as additional software on the upstream interface of MR be it for a one-time use as you stated.

Regards,

Behcet

----- Original Message ----
From: Julien Laganier <julien.IETF@laposte.net>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Cc: mext@ietf.org
Sent: Tuesday, June 10, 2008 4:15:37 AM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

Hello Alex,

On Tuesday 10 June 2008, Alexandru Petrescu wrote:
>
> fan zhao wrote:
> > Hi Julien, Marcelo et al,
> >
> >> The question at this stage is whether we want to make the only
> >> proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft.
>
> WEll I agree in principle, provided authors are open to feedback from
> implementation and ready to modify it further.

Just for clarification, if the draft becomes a WG draft, it will of
course be subject to modifications as per the WG consensus. This is the
IETF process

> > IMHO, the DHCP-PD solution leads to additional signaling overhead;
> > furthermore, using the DHCP Authentication Option introduces
> > another layer of overhead/redundancy. Therefore, my oponion is
> > DHCP-PD should not be the only solution.
>
> Well DHCP-PD through the secured MR-HA tunnel wouldn't use DHCP auth
> option.

This is my understanding as well.

> > RFC 5026 describes the procedure for the MN to dynamically obtain
> > the home address from the network using the IKEv2. As defined in
> > RFC 3753, a MN could be either a MR or MH. Therefore it is natural
> > to define extensions in the IKEv2 for the MR to request the MNP,
> > which is more efficient and secure.
>
> I'm not sure using IKEv2 to obtain MNP is more efficient than DHCP,
> at least because IKEv2 has much more roundtrips than DHCP, so it
> could be considered heavier (or less efficient).

And bottom line is that optimizing the efficiency of a one round-trip
process that happens once when the MR boots up, and not in any critical
path (e.g. handover) at the expense of modularity is questionable,
IMHO.

--julien

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
--0-181338345-1213109896=:77457-- --===============0268995675== 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://www.ietf.org/mailman/listinfo/mext --===============0268995675==-- From mext-bounces@ietf.org Tue Jun 10 11:22:09 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A8FE3A6994; Tue, 10 Jun 2008 11:22:09 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EAFE3A6994 for ; Tue, 10 Jun 2008 11:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MJLUU9bnigI for ; Tue, 10 Jun 2008 11:22:06 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 5E83C3A692E for ; Tue, 10 Jun 2008 11:22:05 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 14:22:20 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Thread-Index: AcjK3wt2kUgYQ6p8RXqNcj7ZaBIGBwAR3VPw References: <48401470.40706@it.uc3m.es><006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com><200806100911.41214.julien.IETF@laposte.net><484E43D4.7020108@gmail.com> From: "Vijay Devarapalli" To: "fan zhao" , "Alexandru Petrescu" Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Fan, *If* we are not going to be using DCHP for the mobile router to obtain mobile network prefix(es) from the home agent, I would prefer the BU/BAck exchange rather than modifying/extending IKEv2. The mobile router could just request for the mobile network prefix(es) in the BU and get the information in the BAck. Vijay > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of fan zhao > Sent: Tuesday, June 10, 2008 2:48 AM > To: Alexandru Petrescu > Cc: mext@ietf.org; Julien Laganier > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > Hi Alex, > > Thanks for your reply. Sorry I could not reply you earlier. > > On Tue, Jun 10, 2008 at 2:05 AM, Alexandru Petrescu > wrote: > > Hi Fan and thank you for the other private email, I take > advantage of this > > to reply publicly. > > > > fan zhao wrote: > >> > >> Hi Julien, Marcelo et al, > >> > >>> The question at this stage is whether we want to make the only > >>> proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft. > > > > WEll I agree in principle, provided authors are open to > feedback from > > implementation and ready to modify it further. > > > >> IMHO, the DHCP-PD solution leads to additional signaling overhead; > >> furthermore, using the DHCP Authentication Option > introduces another > >> layer of overhead/redundancy. Therefore, my oponion is > DHCP-PD should > >> not be the only solution. > > > > Well DHCP-PD through the secured MR-HA tunnel wouldn't use > DHCP auth option. > I agree. The secured MR-HA tunnel relies on the IPSec SA. The IPSec SA > is established > when the MR powers up. > During the IPSec SA establishment with the HA, the MR can request its > home address and the > MNP using the configuration payload. > > > > >> RFC 5026 describes the procedure for the MN to dynamically > obtain the > >> home address from the network using the IKEv2. As defined in RFC > >> 3753, a MN could be either a MR or MH. Therefore it is natural to > >> define extensions in the IKEv2 for the MR to request the MNP, which > >> is more efficient and secure. > > > > I'm not sure using IKEv2 to obtain MNP is more efficient > than DHCP, at least > > because IKEv2 has much more roundtrips than DHCP, so it > could be considered > > heavier (or less efficient). > > Alex, the following is the comparison between the DHCP-PD and > the IKE-PD. > > DHCP-PD: > Assume that the MR is not at the home link, when the MR > powers up using CMIP, > it follows the bootstrapping procedure as a MN: first, it obtains a > local IP address as CoA; > second, it obtains the IP address of the HA; third, it establishes the > IPSec SA with the HA, > during this procedure, the MR obtains a HoA; fourth, the MR compares > the HoA with > the previously configured IP address, i.e CoA and the MR determines > that it is not at home; > therefore it sends a BU to the HA to reg the binding between HoA and > CoA and receives a BA; fifth, > based on its configuration, the MR realizes it should act as a MR and > obtain a MNP. With the > DHCP based approach, the MR sends a DHCP solicit message to the HA and > the MR receives > a DHCP reply message. Now the PD is completed. > > IKE-PD: > Assume that the MR is not at home link, ... first, it obtains a local > IP address as CoA; > second, it obtains the IP address of the HA; third, it establishes the > IPSec SA with the HA, > during this procedure, the MR obtains a HoA and a MNP based its > configuration; fourth, the MR compares the HoA with > the previously configured IP address, i.e CoA and the MR determines > that it is not at home; > therefore it sends a BU to the HA to register the binding between HoA > and MNP and CoA and receives a BA. > > Note that we conclude before the home link detection is based on the > IKE. Therefore, the MN also > performs 1) to 4) when it is on its home link. So with the IKE-PD, the > MN does not need to send and > receive the DHCP messages. > > It is also not as simple as saving two messages. > Consider this case: the MN needs to set up an additional IPSec child > SA to protect the data traffic. > This is done after the IPSec SA is performed. With the DHCP-PD, if the > MN performs the Child SA > establishment for the traffic from/to itself before the DHCP-PD, then > after DHCP-PD, the MN needs to > set up another child SA to protect the traffic to/from the MNNs. If > the MN performs the Child SA > establishment for the traffic from/to itself after the DHCP-PD, this > means the commnucation between > MN and CN is delayed. therefore, when the MN handovers from a PMIP > domain to a target access network > using CMIP. DHCP-PD would result in more delay. > With the IKE-PD, since the MN knows its HoA and MNP at the same time, > it can immediately set > up one Child SA to protect the traffic from/to itself and the MNNs. > > Do I miss something? Thanks. > > Sincerely, > fan > > > > > Alex > > > >> > >> Thanks. > >> > >> Sincerely, fan > >> > >> > >> > >> > >> On Tue, Jun 10, 2008 at 12:11 AM, Julien Laganier > >> wrote: > >>> > >>> On Friday 06 June 2008, Frank Xia wrote: > >>>> > >>>> Hi Fan, Ryuji and other colleagues. > >>>> > >>>> Agreed. > >>>> > >>>> IMHO,There are two ways for prefix delegation in Nemo, that is, > >>>> overlay and integrated modes. > >>>> > >>>> DHCP based PD is a overlay solution which introduce > redundancy while > >>>> trying to reduce impact on NEMO itself. > >>>> > >>>> I favor the integrated mode in which Prefix Delegation is > >>>> integrated into NEMO operations because prefix management is an > >>>> integrated part of NEMO. PMIPv6 follow the same philosophy. > >>> > >>> Hello Frank et. al. > >>> > >>> > >>> > >>> We are not going to challenge your technical arguments. We have a > >>> WG consensus on developing *one* solution based on *DHCPv6 PD*, so > >>> this is discussion is in our opinion out of scope since there are > >>> no reasons to revert the WG consensus. > >>> > >>> The question at this stage is whether we want to make the only > >>> proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft. > >>> > >>> Thanks in advance for your understanding. > >>> > >>> Regards, > >>> > >>> -- julien & marcelo, MEXT chairs > >>> > >>> > >> _______________________________________________ MEXT mailing list > >> MEXT@ietf.org https://www.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://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From c.slijkerman@qunited.nl Tue Jun 10 11:46:02 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE06C3A6A6D; Tue, 10 Jun 2008 11:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -50.969 X-Spam-Level: X-Spam-Status: No, score=-50.969 tagged_above=-999 required=5 tests=[BAYES_60=1, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMZU9cyCzpBx; Tue, 10 Jun 2008 11:46:00 -0700 (PDT) Received: from pc-95-145-47-190.cm.vtr.net (pc-95-145-47-190.cm.vtr.net [190.47.145.95]) by core3.amsl.com (Postfix) with SMTP id 13E263A6A8D; Tue, 10 Jun 2008 11:45:37 -0700 (PDT) X-Originating-IP: 35.79.84.16 by smtp.190.47.145.95; Tue, 10 Jun 2008 14:46:00 -0500 Message-ID: From: "Johnnie Frederick" Reply-To: "Johnnie Frederick" To: multi6-archive@ietf.org Subject: Replica watches made easy Date: Tue, 10 Jun 2008 14:46:00 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Prestige Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://dadafupuwyh87.blogspot.com/ Prestige Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://dadafupuwyh87.blogspot.com/ From mext-bounces@ietf.org Tue Jun 10 12:18:23 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E2AD3A6AA7; Tue, 10 Jun 2008 12:18:23 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7575A3A6AA7 for ; Tue, 10 Jun 2008 12:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gh0P4wCskuQL for ; Tue, 10 Jun 2008 12:18:20 -0700 (PDT) Received: from web84310.mail.re1.yahoo.com (web84310.mail.re1.yahoo.com [69.147.74.189]) by core3.amsl.com (Postfix) with SMTP id 278603A67B1 for ; Tue, 10 Jun 2008 12:18:20 -0700 (PDT) Received: (qmail 14382 invoked by uid 60001); 10 Jun 2008 19:18:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=AqkiH+RgqKWNZ6SMGLr4qZul6xSoMTZ+jZiQtoFsQ7kTQA9nLen4umMQH95m87yBV3oB1JRHeXF9cwuDHh3P+/p2LIxSGYs6cTIkP/SUW/00kOC6W4NuTQQmnAyETPn8m1GGu+El19n5qhq6gSaCI1Tqg23FzpB6BGD8jp13tcU=; X-YMail-OSG: 2cZFU1kVM1nWmXh48ry5TfAdsZT7SLFSPT17SDIJbIuSOahZuPcQ78jDFnNHYVksxabI.mkawk7jOW1f.d0Ve5krIVw0Cjybl0AEqmE2Bur6T8iDpo3CHv8- Received: from [206.16.17.212] by web84310.mail.re1.yahoo.com via HTTP; Tue, 10 Jun 2008 12:18:41 PDT X-Mailer: YahooMailRC/975.41 YahooMailWebService/0.7.185 Date: Tue, 10 Jun 2008 12:18:41 -0700 (PDT) From: Behcet Sarikaya To: Vijay Devarapalli MIME-Version: 1.0 Message-ID: <947302.14203.qm@web84310.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 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="===============1068168395==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1068168395== Content-Type: multipart/alternative; boundary="0-1249675877-1213125521=:14203" --0-1249675877-1213125521=:14203 Content-Type: text/plain; charset=us-ascii Hi Vijay, Pls. see inline. Regards, Behcet ----- Original Message ---- From: Vijay Devarapalli To: fan zhao ; Alexandru Petrescu Cc: Julien Laganier ; mext@ietf.org Sent: Tuesday, June 10, 2008 1:22:20 PM Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Hello Fan, *If* we are not going to be using DCHP for the mobile router to obtain mobile network prefix(es) from the home agent, I would prefer the BU/BAck exchange rather than modifying/extending IKEv2. [behcet] You mean other than RFC 5026? The mobile router could just request for the mobile network prefix(es) in the BU and get the information in the BAck. Vijay > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of fan zhao > Sent: Tuesday, June 10, 2008 2:48 AM > To: Alexandru Petrescu > Cc: mext@ietf.org; Julien Laganier > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > Hi Alex, > > Thanks for your reply. Sorry I could not reply you earlier. > > On Tue, Jun 10, 2008 at 2:05 AM, Alexandru Petrescu > wrote: > > Hi Fan and thank you for the other private email, I take > advantage of this > > to reply publicly. > > > > fan zhao wrote: > >> > >> Hi Julien, Marcelo et al, > >> > >>> The question at this stage is whether we want to make the only > >>> proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft. > > > > WEll I agree in principle, provided authors are open to > feedback from > > implementation and ready to modify it further. > > > >> IMHO, the DHCP-PD solution leads to additional signaling overhead; > >> furthermore, using the DHCP Authentication Option > introduces another > >> layer of overhead/redundancy. Therefore, my oponion is > DHCP-PD should > >> not be the only solution. > > > > Well DHCP-PD through the secured MR-HA tunnel wouldn't use > DHCP auth option. > I agree. The secured MR-HA tunnel relies on the IPSec SA. The IPSec SA > is established > when the MR powers up. > During the IPSec SA establishment with the HA, the MR can request its > home address and the > MNP using the configuration payload. > > > > >> RFC 5026 describes the procedure for the MN to dynamically > obtain the > >> home address from the network using the IKEv2. As defined in RFC > >> 3753, a MN could be either a MR or MH. Therefore it is natural to > >> define extensions in the IKEv2 for the MR to request the MNP, which > >> is more efficient and secure. > > > > I'm not sure using IKEv2 to obtain MNP is more efficient > than DHCP, at least > > because IKEv2 has much more roundtrips than DHCP, so it > could be considered > > heavier (or less efficient). > > Alex, the following is the comparison between the DHCP-PD and > the IKE-PD. > > DHCP-PD: > Assume that the MR is not at the home link, when the MR > powers up using CMIP, > it follows the bootstrapping procedure as a MN: first, it obtains a > local IP address as CoA; > second, it obtains the IP address of the HA; third, it establishes the > IPSec SA with the HA, > during this procedure, the MR obtains a HoA; fourth, the MR compares > the HoA with > the previously configured IP address, i.e CoA and the MR determines > that it is not at home; > therefore it sends a BU to the HA to reg the binding between HoA and > CoA and receives a BA; fifth, > based on its configuration, the MR realizes it should act as a MR and > obtain a MNP. With the > DHCP based approach, the MR sends a DHCP solicit message to the HA and > the MR receives > a DHCP reply message. Now the PD is completed. > > IKE-PD: > Assume that the MR is not at home link, ... first, it obtains a local > IP address as CoA; > second, it obtains the IP address of the HA; third, it establishes the > IPSec SA with the HA, > during this procedure, the MR obtains a HoA and a MNP based its > configuration; fourth, the MR compares the HoA with > the previously configured IP address, i.e CoA and the MR determines > that it is not at home; > therefore it sends a BU to the HA to register the binding between HoA > and MNP and CoA and receives a BA. > > Note that we conclude before the home link detection is based on the > IKE. Therefore, the MN also > performs 1) to 4) when it is on its home link. So with the IKE-PD, the > MN does not need to send and > receive the DHCP messages. > > It is also not as simple as saving two messages. > Consider this case: the MN needs to set up an additional IPSec child > SA to protect the data traffic. > This is done after the IPSec SA is performed. With the DHCP-PD, if the > MN performs the Child SA > establishment for the traffic from/to itself before the DHCP-PD, then > after DHCP-PD, the MN needs to > set up another child SA to protect the traffic to/from the MNNs. If > the MN performs the Child SA > establishment for the traffic from/to itself after the DHCP-PD, this > means the commnucation between > MN and CN is delayed. therefore, when the MN handovers from a PMIP > domain to a target access network > using CMIP. DHCP-PD would result in more delay. > With the IKE-PD, since the MN knows its HoA and MNP at the same time, > it can immediately set > up one Child SA to protect the traffic from/to itself and the MNNs. > > Do I miss something? Thanks. > > Sincerely, > fan > > > > > Alex > > > >> > >> Thanks. > >> > >> Sincerely, fan > >> > >> > >> > >> > >> On Tue, Jun 10, 2008 at 12:11 AM, Julien Laganier > >> wrote: > >>> > >>> On Friday 06 June 2008, Frank Xia wrote: > >>>> > >>>> Hi Fan, Ryuji and other colleagues. > >>>> > >>>> Agreed. > >>>> > >>>> IMHO,There are two ways for prefix delegation in Nemo, that is, > >>>> overlay and integrated modes. > >>>> > >>>> DHCP based PD is a overlay solution which introduce > redundancy while > >>>> trying to reduce impact on NEMO itself. > >>>> > >>>> I favor the integrated mode in which Prefix Delegation is > >>>> integrated into NEMO operations because prefix management is an > >>>> integrated part of NEMO. PMIPv6 follow the same philosophy. > >>> > >>> Hello Frank et. al. > >>> > >>> > >>> > >>> We are not going to challenge your technical arguments. We have a > >>> WG consensus on developing *one* solution based on *DHCPv6 PD*, so > >>> this is discussion is in our opinion out of scope since there are > >>> no reasons to revert the WG consensus. > >>> > >>> The question at this stage is whether we want to make the only > >>> proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft. > >>> > >>> Thanks in advance for your understanding. > >>> > >>> Regards, > >>> > >>> -- julien & marcelo, MEXT chairs > >>> > >>> > >> _______________________________________________ MEXT mailing list > >> MEXT@ietf.org https://www.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://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-1249675877-1213125521=:14203 Content-Type: text/html; charset=us-ascii
Hi Vijay,
  Pls. see inline.

Regards,

Behcet

----- Original Message ----
From: Vijay Devarapalli <vijay@wichorus.com>
To: fan zhao <fanzhao828@gmail.com>; Alexandru Petrescu <alexandru.petrescu@gmail.com>
Cc: Julien Laganier <julien.IETF@laposte.net>; mext@ietf.org
Sent: Tuesday, June 10, 2008 1:22:20 PM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

Hello Fan,

*If* we are not going to be using DCHP for the mobile router to obtain
mobile network prefix(es) from the home agent, I would prefer the
BU/BAck exchange rather than modifying/extending IKEv2.

[behcet] You mean other than RFC 5026?

The mobile
router could just request for the mobile network prefix(es) in the BU
and get the information in the BAck.

Vijay

> -----Original Message-----
> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On
> Behalf Of fan zhao
> Sent: Tuesday, June 10, 2008 2:48 AM
> To: Alexandru Petrescu
> Cc: mext@ietf.org; Julien Laganier
> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?
>
> Hi Alex,
>
> Thanks for your reply. Sorry I could not reply you earlier.
>
> On Tue, Jun 10, 2008 at 2:05 AM, Alexandru Petrescu
> <alexandru.petrescu@gmail.com> wrote:
> > Hi Fan and thank you for the other private email, I take
> advantage of this
> > to reply publicly.
> >
> > fan zhao wrote:
> >>
> >> Hi Julien, Marcelo et al,
> >>
> >>> The question at this stage is whether we want to make the only
> >>> proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft.
> >
> > WEll I agree in principle, provided authors are open to
> feedback from
> > implementation and ready to modify it further.
> >
> >> IMHO, the DHCP-PD solution leads to additional signaling overhead;
> >> furthermore, using the DHCP Authentication Option
> introduces another
> >> layer of overhead/redundancy. Therefore, my oponion is
> DHCP-PD should
> >> not be the only solution.
> >
> > Well DHCP-PD through the secured MR-HA tunnel wouldn't use
> DHCP auth option.
> I agree. The secured MR-HA tunnel relies on the IPSec SA. The IPSec SA
> is established
> when the MR powers up.
> During the IPSec SA establishment with the HA, the MR can request its
> home address and the
> MNP using the configuration payload.
>
> >
> >> RFC 5026 describes the procedure for the MN to dynamically
> obtain the
> >>  home address from the network using the IKEv2. As defined in RFC
> >> 3753, a MN could be either a MR or MH. Therefore it is natural to
> >> define extensions in the IKEv2 for the MR to request the MNP, which
> >> is more efficient and secure.
> >
> > I'm not sure using IKEv2 to obtain MNP is more efficient
> than DHCP, at least
> > because IKEv2 has much more roundtrips than DHCP, so it
> could be considered
> > heavier (or less efficient).
>
> Alex, the following is the comparison between the DHCP-PD and
> the IKE-PD.
>
> DHCP-PD:
> Assume that the MR is not at the home link, when the MR
> powers up using CMIP,
> it follows the bootstrapping procedure as a MN: first, it obtains a
> local IP address as CoA;
> second, it obtains the IP address of the HA; third, it establishes the
> IPSec SA with the HA,
> during this procedure, the MR obtains a HoA; fourth, the MR compares
> the HoA with
> the previously configured IP address, i.e CoA and the MR determines
> that it is not at home;
> therefore it sends a BU to the HA to reg the binding between HoA and
> CoA and receives a BA; fifth,
> based on its configuration, the MR realizes it should act as a MR and
> obtain a MNP. With the
> DHCP based approach, the MR sends a DHCP solicit message to the HA and
> the MR receives
> a DHCP reply message. Now the PD is completed.
>
> IKE-PD:
> Assume that the MR is not at home link, ... first, it obtains a local
> IP address as CoA;
> second, it obtains the IP address of the HA; third, it establishes the
> IPSec SA with the HA,
> during this procedure, the MR obtains a HoA and a MNP based its
> configuration; fourth, the MR compares the HoA with
> the previously configured IP address, i.e CoA and the MR determines
> that it is not at home;
> therefore it sends a BU to the HA to register the binding between HoA
> and MNP and CoA and receives a BA.
>
> Note that we conclude before the home link detection is based on the
> IKE. Therefore, the MN also
> performs 1) to 4) when it is on its home link. So with the IKE-PD, the
> MN does not need to send and
> receive the DHCP messages.
>
> It is also not as simple as saving two messages.
> Consider this case: the MN needs to set up an additional IPSec child
> SA to protect the data traffic.
> This is done after the IPSec SA is performed. With the DHCP-PD, if the
> MN performs the Child SA
> establishment for the traffic from/to itself before the DHCP-PD, then
> after DHCP-PD, the MN needs to
> set up another child SA to protect the traffic to/from the MNNs. If
> the MN performs the Child SA
> establishment for the traffic from/to itself after the DHCP-PD, this
> means the commnucation between
> MN and CN is delayed. therefore, when the MN handovers from a PMIP
> domain to a target access network
> using CMIP. DHCP-PD would result in more delay.
> With the IKE-PD, since the MN knows its HoA and MNP at the same time,
> it can immediately set
> up one Child SA to protect the traffic from/to itself and the MNNs.
>
> Do I miss something? Thanks.
>
> Sincerely,
> fan
>
> >
> > Alex
> >
> >>
> >> Thanks.
> >>
> >> Sincerely, fan
> >>
> >>
> >>
> >>
> >> On Tue, Jun 10, 2008 at 12:11 AM, Julien Laganier
> >> <julien.IETF@laposte.net> wrote:
> >>>
> >>> On Friday 06 June 2008, Frank Xia wrote:
> >>>>
> >>>> Hi Fan, Ryuji and other colleagues.
> >>>>
> >>>> Agreed.
> >>>>
> >>>> IMHO,There are two ways for prefix delegation in Nemo, that is,
> >>>> overlay and integrated modes.
> >>>>
> >>>> DHCP based PD is a overlay solution which introduce
> redundancy while
> >>>> trying to reduce impact on NEMO itself.
> >>>>
> >>>> I favor the integrated mode in which Prefix Delegation is
> >>>> integrated into NEMO operations because prefix management is an
> >>>> integrated part of NEMO.  PMIPv6 follow the same philosophy.
> >>>
> >>> Hello Frank et. al.
> >>>
> >>> <WG chair hat ON>
> >>>
> >>> We are not going to challenge your technical arguments. We have a
> >>> WG consensus on developing *one* solution based on *DHCPv6 PD*, so
> >>> this is discussion is in our opinion out of scope since there are
> >>> no reasons to revert the WG consensus.
> >>>
> >>> The question at this stage is whether we want to make the only
> >>> proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft.
> >>>
> >>> Thanks in advance for your understanding.
> >>>
> >>> Regards,
> >>>
> >>> -- julien & marcelo, MEXT chairs
> >>>
> >>>
> >> _______________________________________________ MEXT mailing list
> >> MEXT@ietf.org https://www.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://www.ietf.org/mailman/listinfo/mext
>
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
--0-1249675877-1213125521=:14203-- --===============1068168395== 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://www.ietf.org/mailman/listinfo/mext --===============1068168395==-- From mext-bounces@ietf.org Tue Jun 10 15:28:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1910128C0EF; Tue, 10 Jun 2008 15:28:50 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D013A6B13 for ; Tue, 10 Jun 2008 15:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usZdUP59NaIz for ; Tue, 10 Jun 2008 15:28:47 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by core3.amsl.com (Postfix) with ESMTP id B62543A6ACA for ; Tue, 10 Jun 2008 15:28:46 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so1111352and.122 for ; Tue, 10 Jun 2008 15:29:05 -0700 (PDT) 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=zyQ0VfHH4KvHE0Hx2YRpPvFI46i/p6WYkYCmcX70/VU=; b=EDIMLpwoq9iFqqzGStl3a8AFma1cPctXqqucGiTFLNd+15rlHDtFPnfLc77ZAOI9od muAY0NPoGzV04N3SuXaC0YqavPRRtWh7vEZKpzSbZyfiyZz5DBjf4GMeb3//M9K4iZXQ V4P65bYQyaDpSvAgswy5fBP4NNLzvhz/CD+RA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=BpMZLXCSW+aFrgjbSagXv/t/1om3IsQIqQlKxTDXHocPGNpOQR3yM6Mt8hdsiogau+ arSAVjR8LNju9NFyVG/ODumVAopeVw1JqQXGR9/nRgj+b8P8SkwAvz0XifzkxO0CaiCI t+IM12NjJ8h9BlsEbiB4uMGc9xnVzTqdXXV50= Received: by 10.100.41.4 with SMTP id o4mr6364736ano.136.1213136945834; Tue, 10 Jun 2008 15:29:05 -0700 (PDT) Received: by 10.100.141.11 with HTTP; Tue, 10 Jun 2008 15:29:05 -0700 (PDT) Message-ID: Date: Tue, 10 Jun 2008 15:29:05 -0700 From: "fan zhao" To: "Arnaud Ebalard" In-Reply-To: <87d4mp5uc5.fsf@natisbad.org> MIME-Version: 1.0 Content-Disposition: inline References: <87d4mp5uc5.fsf@natisbad.org> Cc: IETF IPsec WG , IETF MEXT WG Subject: Re: [MEXT] [IPsec] Clarifications on dynamic HoA assignment by IKE (RFC 4877 and 5026) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Arnaud, IMO, before the MN gets a HoA, the corresponding SPD entry does not have the HoA. Such entry may contain the mobility header type or may be even not created until the HoA is allocated. The IKE can be triggered by the configuration/ selection of the mobility protocol to be used. Your impression is correct and I agree with you: the initialization of the MIP is embedded into the IKE and their logical functions are tightly correlated. Sincerely, fan On Tue, Jun 10, 2008 at 5:48 AM, Arnaud Ebalard wrote: > Hi, > > I just read again RFC 4877 and RFC 5026 (and related sections of RFC > 4306) and I have questions. IPsec WG is in Cc; sorry if you receive the > mail twice and also for its length. > > In RFC 4877, it is written that "the home agent and the mobile node MAY > support remote configuration of the home address". This is specifically > covered in Section 9 but there are related notes in other parts of the > document. > > Simply put, my questions would be: "What are the *detailed* steps by > which IKE negotiation will be *triggered* on the Mobile Node in the > process of getting a HoA dynamically assigned? How is the address > provided to the MIPv6 module?". > > More precisely, I'd like to clarify the following points: > > SPD entries provided in section 7.2.1 make use of home_address_1 which > might not be available yet (at least on the mobile node). This is > commented after the SPD entries: "In the examples shown above, the > home address of the mobile node might not be available all the time. > For instance, the mobile node might not have configured a home address > yet. When the mobile node acquires a new home address, it must either > add the address to the corresponding SPD entries or create the SPD > entries for the home address." Associated questions are: > > o Which address should be used meanwhile (in the SPD entries on the > MN, for instance)? > o how will the IKE negotiation be triggered, i.e. by which packet? > o how can the SPD entries be added afterwhile if they are supposed to > trigger IKE negotiation? > > I think I have missed something in the reference documents because I am > under the impression that *something* makes IKE start a negotiation > without any SPD related event (like a packet matching a SP and asking > for protection) to get a HoA, but I am unable to find what. Is it > implicitly expected that the IKE daemon starts an IKE_AUTH exchange to > grab a HoA on its own? What is controlled by MIPv6 / what is not? How? > I'll appreciate some feedback on that. > > > Now, regarding RFC 5026, there are 7 references to RFC 4877: the use > of previous HoA assignement is also listed based on content of RFC 4877 > and another mechanism (section 5.3.2, HoA Auto-Configuration by the > Mobile Node) which allows the MN to get the prefix it should use to > autoconfigure an address it will then send back to the HA. Like previous > HoA assignment, the prefix is obtained using IKEv2 during IKE_AUTH > exchange. Basically, I have the same questions as for dynamic HoA > assignement above. How are things triggered? Who controls what? How is > the synchronization between IKE and MIPv6 performed? > > > In the end, after reading those 2 documents, I am under the impression > (do not hesitate to correct me) that the MIPv6 process on the MN has the > ability to *trigger* an IKE negotiation with the IKE daemon on its HA > for the purpose of configuring its HoA. I am also under the impression > that this neogiation is not the result of an SPD lookup indicating that > a queued packet requires protection. > > Then I looked at RFC 4306 to find some answers. There are some elements > on the topic in Section 1.1.3, at the end of section 2.9, in section > 2.19 and in section 3.15 but the scenario where IKE starts negotiation > and gets the HoA on its own just looks odd. > > In RFC 3776 (for static and dynamic keying) and for statically assigned > HoA in RFC 4877, MIPv6 module handles HoA, and IKE acts accordingly > (yes, it needs some modification to bootstrap) but in the dynamic > assignment case, the scenario is reversed and IKE starts and > "configures" MIPv6 (at least for the HoA part). This is not explicitly > stated (if my understanding and descriptions are correct) and the > details are missing in associated document (AFAICT). > > When reading RFC 4877 and RFC 5026, I was under the impression that > MIPv6 and IKE are expected to be one unique entity. I wonder how it will > be possible in that context to have separate IKEv2 and MIPv6 > implementations interoperate on the same MN, HA or MR. > > If I missed some documents, don't hesitate to tell. > > Thanks, > > a+ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 10 19:30:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7750F3A694B; Tue, 10 Jun 2008 19:30:05 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E4DD33A68E6; Tue, 10 Jun 2008 19:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080611023001.E4DD33A68E6@core3.amsl.com> Date: Tue, 10 Jun 2008 19:30:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-v4traversal-04.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Mobile IPv6 Support for Dual Stack Hosts and Routers Author(s) : H. Soliman Filename : draft-ietf-mext-nemo-v4traversal-04.txt Pages : 48 Date : 2008-06-10 The current Mobile IPv6 and NEMO specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the Mobile Node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-nemo-v4traversal-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-10192058.I-D@ietf.org> --NextPart 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://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Tue Jun 10 19:38:21 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85B333A68E2; Tue, 10 Jun 2008 19:38:21 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB1D93A68E2 for ; Tue, 10 Jun 2008 19:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nt47bAln6cUg for ; Tue, 10 Jun 2008 19:38:20 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0DB2B3A6814 for ; Tue, 10 Jun 2008 19:38:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,621,1204531200"; d="scan'208";a="31561209" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 10 Jun 2008 19:38:43 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m5B2chb2013181; Tue, 10 Jun 2008 19:38:43 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5B2chjj006619; Wed, 11 Jun 2008 02:38:43 GMT Date: Tue, 10 Jun 2008 19:38:43 -0700 (PDT) From: Sri Gundavelli To: Julien Laganier In-Reply-To: <200806051742.39799.julien.IETF@laposte.net> Message-ID: References: <483D5A50.1000208@it.uc3m.es> <20080603104511.GA3314@kafka.verkstad.net> <200806051742.39799.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-790359597-1213151923=:7520" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1746; t=1213151923; x=1214015923; 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]=20Generic=20Signaling=20Message= 20/=20Name=20of=20generic=20=22notification=22=0A=20(Was=3A= 20Scope=20of=20generic=20notification) |Sender:=20; bh=aVmHn66OO0B4w1TXCbGQV+sFZwqg7OZjFBkLPDepLkU=; b=Xvs1+9pO0ZgNHqbEubjuc98N48tWaGq3xVc21EpQ9mkxqN/Z8sD602oA+9 sDMQYSRg5uIdLraIOomN6RcBNlbQs90t9GRNyZStjQwVv9Ra77J5Fi280Wju 3M/wzVLbVO; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] Generic Signaling Message / Name of generic "notification" (Was: Scope of generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-790359597-1213151923=:7520 Content-Type: TEXT/PLAIN; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Julien, This change should be fine .. Thanks Sri On Thu, 5 Jun 2008, Julien Laganier wrote: > On Tuesday 03 June 2008, Michael Eriksson wrote: >> - I don't particularly like the "notification" part of GNM's name, as >> =A0 I think it will should be used for more than notifications. > > Folks, > > > > What Michael said above rang a bell :) > > How about calling the new framework "MIPv6 Generic Signaling Message > (MGSM), and defines two MH types, one requiring IPsec, the other not. > > Then we would distinguish different types of messages (Revocation, Flow > Distribution Rules, Heartbeat, etc.) based on a subtype inside the > Generic Signaling Message. > > I think that should satisfy everybody: > - the IPsec SPD needs only one set of rules for each of the MH types > (bypass, and protect). > - a MGSM consumer (e.g. Revocation, Distribution Rules) simply specify > the MH type it chooses depending on whether or not it requires IPsec > protection. > - a MGSM consumer allocates one or more MGSM subtypes for each new > message necessary to implement the consumer's functionality. > - a MGSM consumer specifies processing (sending, receiving, state > machines...) for these subtyped messages. > > What do you think? > > --julien > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > ---559023410-790359597-1213151923=:7520 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://www.ietf.org/mailman/listinfo/mext ---559023410-790359597-1213151923=:7520-- From mext-bounces@ietf.org Tue Jun 10 19:39:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A9803A6851; Tue, 10 Jun 2008 19:39:49 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3EA23A6851 for ; Tue, 10 Jun 2008 19:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8QdrJKXg5E4 for ; Tue, 10 Jun 2008 19:39:46 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id ABCF43A6814 for ; Tue, 10 Jun 2008 19:39:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,621,1204531200"; d="scan'208";a="40254971" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 10 Jun 2008 19:40:10 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5B2eA6n013563; Tue, 10 Jun 2008 19:40:10 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5B2eArN007330; Wed, 11 Jun 2008 02:40:10 GMT Date: Tue, 10 Jun 2008 19:40:10 -0700 (PDT) From: Sri Gundavelli To: Jari Arkko In-Reply-To: <4845B5D9.2080507@piuha.net> Message-ID: References: <4845B5D9.2080507@piuha.net> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3075; t=1213152010; x=1214016010; 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=20AD=20review=20of=20draft-ietf-mext-nemo -mib |Sender:=20; bh=kdyLv/R9VN7jwuoVs2vakHVjTr50JxUaKe/GKizDIX4=; b=QRNFLUqgZGiQ55Zh9vbdNgnq/WoRRb/5oPbOohDwX7zNCxtDWweUnf3gmq HgBAi+ulj1sewPHS7OfM3YVyPWBdgAcL6hrcjstPwr/So3Trp8xmgfneFL74 s3rKjybeiD; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: draft-ietf-mext-nemo-mib@tools.ietf.org, "mext@ietf.org" Subject: Re: [MEXT] AD review of draft-ietf-mext-nemo-mib X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Jari, Thanks for the review. We will address the issues and post the revised document. Regards Sri On Tue, 3 Jun 2008, Jari Arkko wrote: > Here are the results of my review. I believe the documents needs one > additional editing round, as well as a few additional reviews to make > sure everything is right. > > All the issues below are relatively small, but the fact that many > of these things were missed means that additional eyes are needed > on the document. > > Here are the details: > > - Remove Counter64, because it is not used > > - Replace nemo@ietf.org with mext@ietf.org > > - Update copyright notice to 2008 > > - Update revision string > > - nemoRegisteredUpTime: Do you count only the current location and > registration? Please specify. > > - nemoRegHomeAgentAddress: The text says: "The home agent address of > the mobile router which was used in the last accepted registration." > I cannot parse this statement. Did you mean to say "The home agent > address used in the last accepted registration sent by the mobile > router."? A similar change would be needed for nemoRegHomeAddress, > nemoRegCareofAddress. > > - nemoRegHomeAddressPrefixLength: The text says: "The prefix length of > the home address that the mobile router is using for roaming." > What does roaming have to do with this? Just say "The prefix length > of the home address for the mobile router." > > - nemoActiveEgressIfIndex: s/current active/currently active/. > > - nemoHomeRegRetryCount and nemoHomeRegRetryDelay appear to implement > a BU retransmission model that is based on a maximum number of > attempts, with fixed time between them. This is in violation of > RFC 3775, Section 11.8. > > - nemoRegisterConnectedPrefixes: The term "connected prefix" does not > appear in RFC 3963 or RFC 4885. Please provide a reference or define > what the semantics of this object are. > > - nemoBindingCacheTable: It says: "This table models the Binding Cache > that includes NEMO related information and is maintained by the > mobile router." This is obviously wrong, as it is the home agent > that maintains this information. More generally, I'm concerned that > similar errors have crept into many of the description fields in > the document. It needs better review. > > - nemoBindingAckNotHomeRegn, nemoBindingRegTypeChanged: why is > the naming different (BindingAck vs. BindingReg)? > > - nemoBindingAckNotHomeRegn, nemoBindingRegTypeChanged, etc: > why is there no nemoBindingAckOtherError to count the number > of errors not classified in the MIB? Remember that we keep > adding new error codes. > > - nemoMovedFNtoFN: this object should clarify that movement > is defined as movement in layer 3, i.e., a different > care of address was configured. Movements at layer 2 > may result in some ND/DHCP activity, but do not always > result in layer 3 change. > > I am expecting a revised draft and information about additional > reviews before proceeding. > > Jari > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From c.lenaerts@waypoint.be Tue Jun 10 20:29:13 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36C8B3A6868; Tue, 10 Jun 2008 20:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -80.392 X-Spam-Level: X-Spam-Status: No, score=-80.392 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR=2.426, J_CHICKENPOX_24=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUbYNRogKGjf; Tue, 10 Jun 2008 20:29:12 -0700 (PDT) Received: from pc-27-106-83-200.cm.vtr.net (pc-27-106-83-200.cm.vtr.net [200.83.106.27]) by core3.amsl.com (Postfix) with SMTP id 0229A3A6872; Tue, 10 Jun 2008 20:28:27 -0700 (PDT) X-Originating-IP: 128.194.107.128 by smtp.200.83.106.27; Tue, 10 Jun 2008 23:28:49 -0500 Message-ID: From: "Shanna Lyons" Reply-To: "Shanna Lyons" To: nemo-archive@ietf.org Subject: The discreet replica store Date: Tue, 10 Jun 2008 23:28:49 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today! http://hamamogatyw57.blogspot.com/ From netlmm-bounces@ietf.org Tue Jun 10 20:29:14 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 792A83A688B for ; Tue, 10 Jun 2008 20:29:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to netlmm awaits moderator approval From: netlmm-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Tue, 10 Jun 2008 20:29:13 -0700 Precedence: bulk X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETLMM working group discussion list X-List-Administrivia: yes Sender: netlmm-bounces@ietf.org Errors-To: netlmm-bounces@ietf.org Your mail to 'netlmm' with the subject The discreet replica store Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netlmm/83d2711aaba9084224b024ee53db4cda7ded7fb8 From ngo-bounces@ietf.org Tue Jun 10 20:29:14 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 972E93A6949 for ; Tue, 10 Jun 2008 20:29:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NGO awaits moderator approval From: ngo-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Tue, 10 Jun 2008 20:29:13 -0700 Precedence: bulk X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF X-List-Administrivia: yes Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Your mail to 'NGO' with the subject The discreet replica store Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ngo/dcb3a99c0b96b20bd6be90f40dc12a5edf7a5e03 From nfsv4-bounces@ietf.org Tue Jun 10 20:29:14 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A54AA3A6949 for ; Tue, 10 Jun 2008 20:29:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nfsv4 awaits moderator approval From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Tue, 10 Jun 2008 20:29:13 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org Your mail to 'nfsv4' with the subject The discreet replica store Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nfsv4/ebd1d781a67a7867e60ba59d287bac44f6dc93fa From ntdp-bounces@ietf.org Tue Jun 10 20:29:14 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09563A6949 for ; Tue, 10 Jun 2008 20:29:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NTDP awaits moderator approval From: ntdp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Tue, 10 Jun 2008 20:29:13 -0700 Precedence: bulk X-BeenThere: ntdp@ietf.org X-Mailman-Version: 2.1.9 List-Id: define standards for the purpose of scripting of network testing equipment X-List-Administrivia: yes Sender: ntdp-bounces@ietf.org Errors-To: ntdp-bounces@ietf.org Your mail to 'NTDP' with the subject The discreet replica store Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ntdp/7947996226f17ace88c9690df674cb827373c914 From nsis-bounces@ietf.org Tue Jun 10 20:29:14 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA52D3A6949 for ; Tue, 10 Jun 2008 20:29:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nsis awaits moderator approval From: nsis-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Tue, 10 Jun 2008 20:29:14 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Your mail to 'nsis' with the subject The discreet replica store Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis/ba88d130835b7e0ee014c8beed8f167886c34ecc From nsis-imp-bounces@ietf.org Tue Jun 10 20:29:14 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C36E63A6949 for ; Tue, 10 Jun 2008 20:29:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NSIS-imp awaits moderator approval From: nsis-imp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Tue, 10 Jun 2008 20:29:14 -0700 Precedence: bulk X-BeenThere: nsis-imp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for implementation questions for NSIS protocols X-List-Administrivia: yes Sender: nsis-imp-bounces@ietf.org Errors-To: nsis-imp-bounces@ietf.org Your mail to 'NSIS-imp' with the subject The discreet replica store Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis-imp/ce685206d48a8d3df4a9db4716b43262ed7cca8b From netconf-bounces@ietf.org Tue Jun 10 20:29:14 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0C373A694B for ; Tue, 10 Jun 2008 20:29:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to Netconf awaits moderator approval From: netconf-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Tue, 10 Jun 2008 20:29:14 -0700 Precedence: bulk X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 List-Id: Network Configuration WG mailing list X-List-Administrivia: yes Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Your mail to 'Netconf' with the subject The discreet replica store Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netconf/980e2e5bc3b357938c0c9c372248c5a50eb6f7f7 From nemo-bounces@ietf.org Tue Jun 10 20:29:15 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 304533A688B for ; Tue, 10 Jun 2008 20:29:15 -0700 (PDT) Subject: The results of your email commands From: nemo-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1072067013==" Message-ID: Date: Tue, 10 Jun 2008 20:29:14 -0700 Precedence: bulk X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NEMO Working Group X-List-Administrivia: yes Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --===============1072067013== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://hamamogatyw57.blogspot.com/ - Done. --===============1072067013== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nemo-request@core3.amsl.com Delivered-To: nemo-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36C8B3A6868; Tue, 10 Jun 2008 20:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -80.392 X-Spam-Level: X-Spam-Status: No, score=-80.392 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR=2.426, J_CHICKENPOX_24=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUbYNRogKGjf; Tue, 10 Jun 2008 20:29:12 -0700 (PDT) Received: from pc-27-106-83-200.cm.vtr.net (pc-27-106-83-200.cm.vtr.net [200.83.106.27]) by core3.amsl.com (Postfix) with SMTP id 0229A3A6872; Tue, 10 Jun 2008 20:28:27 -0700 (PDT) X-Originating-IP: 128.194.107.128 by smtp.200.83.106.27; Tue, 10 Jun 2008 23:28:49 -0500 Message-ID: From: "Shanna Lyons" Reply-To: "Shanna Lyons" To: nemo-archive@ietf.org Subject: The discreet replica store Date: Tue, 10 Jun 2008 23:28:49 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today! http://hamamogatyw57.blogspot.com/ --===============1072067013==-- From nfsv4-bounces@ietf.org Tue Jun 10 20:29:15 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E1A23A6938 for ; Tue, 10 Jun 2008 20:29:15 -0700 (PDT) Subject: The results of your email commands From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0311894488==" Message-ID: Date: Tue, 10 Jun 2008 20:29:14 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org --===============0311894488== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://hamamogatyw57.blogspot.com/ - Done. --===============0311894488== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nfsv4-request@core3.amsl.com Delivered-To: nfsv4-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36C8B3A6868; Tue, 10 Jun 2008 20:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -80.392 X-Spam-Level: X-Spam-Status: No, score=-80.392 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR=2.426, J_CHICKENPOX_24=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUbYNRogKGjf; Tue, 10 Jun 2008 20:29:12 -0700 (PDT) Received: from pc-27-106-83-200.cm.vtr.net (pc-27-106-83-200.cm.vtr.net [200.83.106.27]) by core3.amsl.com (Postfix) with SMTP id 0229A3A6872; Tue, 10 Jun 2008 20:28:27 -0700 (PDT) X-Originating-IP: 128.194.107.128 by smtp.200.83.106.27; Tue, 10 Jun 2008 23:28:49 -0500 Message-ID: From: "Shanna Lyons" Reply-To: "Shanna Lyons" To: nemo-archive@ietf.org Subject: The discreet replica store Date: Tue, 10 Jun 2008 23:28:49 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today! http://hamamogatyw57.blogspot.com/ --===============0311894488==-- From nsis-bounces@ietf.org Tue Jun 10 20:29:17 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1D63A6919 for ; Tue, 10 Jun 2008 20:29:17 -0700 (PDT) Subject: The results of your email commands From: nsis-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0584762853==" Message-ID: Date: Tue, 10 Jun 2008 20:29:15 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============0584762853== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://hamamogatyw57.blogspot.com/ - Done. --===============0584762853== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nsis-request@core3.amsl.com Delivered-To: nsis-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36C8B3A6868; Tue, 10 Jun 2008 20:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -80.392 X-Spam-Level: X-Spam-Status: No, score=-80.392 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR=2.426, J_CHICKENPOX_24=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUbYNRogKGjf; Tue, 10 Jun 2008 20:29:12 -0700 (PDT) Received: from pc-27-106-83-200.cm.vtr.net (pc-27-106-83-200.cm.vtr.net [200.83.106.27]) by core3.amsl.com (Postfix) with SMTP id 0229A3A6872; Tue, 10 Jun 2008 20:28:27 -0700 (PDT) X-Originating-IP: 128.194.107.128 by smtp.200.83.106.27; Tue, 10 Jun 2008 23:28:49 -0500 Message-ID: From: "Shanna Lyons" Reply-To: "Shanna Lyons" To: nemo-archive@ietf.org Subject: The discreet replica store Date: Tue, 10 Jun 2008 23:28:49 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today! http://hamamogatyw57.blogspot.com/ --===============0584762853==-- From mext-bounces@ietf.org Wed Jun 11 00:23:58 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402E83A68E8; Wed, 11 Jun 2008 00:23:58 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F2513A67B4; Wed, 11 Jun 2008 00:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAjB+z+KDVmv; Wed, 11 Jun 2008 00:23:55 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id CC4143A679F; Wed, 11 Jun 2008 00:23:51 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1K6Kgd-0006h1-Lq; Wed, 11 Jun 2008 09:24:03 +0200 X-Hashcash: 1:20:080611:francis.dupont@fdupont.fr::tAC9IoiAY9QkEfb4:0000000000000000000000000000000000000ZO4 X-Hashcash: 1:20:080611:vijay.devarapalli@azairenet.com::7SMWcy9LfHp8/IbV:000000000000000000000000000000EZI4 X-Hashcash: 1:20:080611:marcelo@it.uc3m.es::RUsgJu/V7vR0wiGz:00000000000000000000000000000000000000000004yUD X-Hashcash: 1:20:080611:julien.ietf@laposte.net::A+aq5EdFfrt5Pwpj:000000000000000000000000000000000000002nr0 From: arno@natisbad.org (Arnaud Ebalard) To: "fan zhao" References: <87d4mp5uc5.fsf@natisbad.org> X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080611:fanzhao828@gmail.com::PvLOXHKI2hBPPzk1:000000000000000000000000000000000000000001YEC X-Hashcash: 1:20:080611:ipsec@ietf.org::K0tINuPn8Lc1T1e6:0003XMH X-Hashcash: 1:20:080611:mext@ietf.org::39sagdw4yXgYaBxD:00004Nfy Date: Wed, 11 Jun 2008 09:23:55 +0200 Message-ID: <87iqwgtoxg.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: IETF IPsec WG , Vijay Devarapalli , IETF MEXT WG , Julien Laganier Subject: Re: [MEXT] [IPsec] Clarifications on dynamic HoA assignment by IKE (RFC 4877 and 5026) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0595142299==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0595142299== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Hi, "fan zhao" writes: > Your impression is correct and I agree with you: the initialization of > the MIP is embedded into the IKE and their logical functions are > tightly correlated. If that is the case, this is IMHO a kind of regression compared to RFC 3776 which did not lead to such strong requirements. Of course, IKE module requires some changes to support mobility but requiring IKE to be implemented in MIPv6 module or the opposite looks like an issue. Francis, Vijeay, Marcelo, Julien, can you comment our understanding of RFC 4877 and RFC 5026 implications? In the end, can IKE module and MIPv6 module be implemented separately and how is that supposed to work? I have left my initial analysis below. >> I just read again RFC 4877 and RFC 5026 (and related sections of RFC >> 4306) and I have questions. IPsec WG is in Cc; sorry if you receive the >> mail twice and also for its length. >> >> In RFC 4877, it is written that "the home agent and the mobile node MAY >> support remote configuration of the home address". This is specifically >> covered in Section 9 but there are related notes in other parts of the >> document. >> >> Simply put, my questions would be: "What are the *detailed* steps by >> which IKE negotiation will be *triggered* on the Mobile Node in the >> process of getting a HoA dynamically assigned? How is the address >> provided to the MIPv6 module?". >> >> More precisely, I'd like to clarify the following points: >> >> SPD entries provided in section 7.2.1 make use of home_address_1 which >> might not be available yet (at least on the mobile node). This is >> commented after the SPD entries: "In the examples shown above, the >> home address of the mobile node might not be available all the time. >> For instance, the mobile node might not have configured a home address >> yet. When the mobile node acquires a new home address, it must either >> add the address to the corresponding SPD entries or create the SPD >> entries for the home address." Associated questions are: >> >> o Which address should be used meanwhile (in the SPD entries on the >> MN, for instance)? >> o how will the IKE negotiation be triggered, i.e. by which packet? >> o how can the SPD entries be added afterwhile if they are supposed to >> trigger IKE negotiation? >> >> I think I have missed something in the reference documents because I am >> under the impression that *something* makes IKE start a negotiation >> without any SPD related event (like a packet matching a SP and asking >> for protection) to get a HoA, but I am unable to find what. Is it >> implicitly expected that the IKE daemon starts an IKE_AUTH exchange to >> grab a HoA on its own? What is controlled by MIPv6 / what is not? How? >> I'll appreciate some feedback on that. >> >> >> Now, regarding RFC 5026, there are 7 references to RFC 4877: the use >> of previous HoA assignement is also listed based on content of RFC 4877 >> and another mechanism (section 5.3.2, HoA Auto-Configuration by the >> Mobile Node) which allows the MN to get the prefix it should use to >> autoconfigure an address it will then send back to the HA. Like previous >> HoA assignment, the prefix is obtained using IKEv2 during IKE_AUTH >> exchange. Basically, I have the same questions as for dynamic HoA >> assignement above. How are things triggered? Who controls what? How is >> the synchronization between IKE and MIPv6 performed? >> >> >> In the end, after reading those 2 documents, I am under the impression >> (do not hesitate to correct me) that the MIPv6 process on the MN has the >> ability to *trigger* an IKE negotiation with the IKE daemon on its HA >> for the purpose of configuring its HoA. I am also under the impression >> that this neogiation is not the result of an SPD lookup indicating that >> a queued packet requires protection. >> >> Then I looked at RFC 4306 to find some answers. There are some elements >> on the topic in Section 1.1.3, at the end of section 2.9, in section >> 2.19 and in section 3.15 but the scenario where IKE starts negotiation >> and gets the HoA on its own just looks odd. >> >> In RFC 3776 (for static and dynamic keying) and for statically assigned >> HoA in RFC 4877, MIPv6 module handles HoA, and IKE acts accordingly >> (yes, it needs some modification to bootstrap) but in the dynamic >> assignment case, the scenario is reversed and IKE starts and >> "configures" MIPv6 (at least for the HoA part). This is not explicitly >> stated (if my understanding and descriptions are correct) and the >> details are missing in associated document (AFAICT). >> >> When reading RFC 4877 and RFC 5026, I was under the impression that >> MIPv6 and IKE are expected to be one unique entity. I wonder how it will >> be possible in that context to have separate IKEv2 and MIPv6 >> implementations interoperate on the same MN, HA or MR. >> >> If I missed some documents, don't hesitate to tell. >> >> Thanks, >> >> a+ a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIT32RAlWVfAR6UCYRAkr+AJ97WRoilCCM5agGrsvSDNPX0Q3ZRgCdE0cy 6iuQcrxFNvLM2WI3ffhSMBo= =7rcK -----END PGP SIGNATURE----- --=-=-=-- --===============0595142299== 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://www.ietf.org/mailman/listinfo/mext --===============0595142299==-- From mext-bounces@ietf.org Wed Jun 11 00:38:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23E363A6835; Wed, 11 Jun 2008 00:38:49 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23A0A3A6835 for ; Wed, 11 Jun 2008 00:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.275 X-Spam-Level: X-Spam-Status: No, score=-1.275 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiOwdko4-j6o for ; Wed, 11 Jun 2008 00:38:47 -0700 (PDT) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id 03DFF3A67D1 for ; Wed, 11 Jun 2008 00:38:46 -0700 (PDT) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id m5B7d9NH029860; Wed, 11 Jun 2008 09:39:09 +0200 Received: from nets138a.ww300.siemens.net ([192.168.217.3]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m5B7d9EK020118; Wed, 11 Jun 2008 09:39:09 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jun 2008 09:39:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Jun 2008 09:39:04 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD6803FDB472@zagh223a.ww300.siemens.net> In-Reply-To: <200806051742.39799.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Generic Signaling Message / Name of generic "notification"(Was: Scope of generic notification) Thread-Index: AcjHIt2bqPKYbgfqQoOgeWHSt3FqNAEceZng References: <483D5A50.1000208@it.uc3m.es><20080603104511.GA3314@kafka.verkstad.net> <200806051742.39799.julien.IETF@laposte.net> From: "Premec, Domagoj" To: "Julien Laganier" , X-OriginalArrivalTime: 11 Jun 2008 07:39:08.0825 (UTC) FILETIME=[3BC35890:01C8CB96] 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::080611093909-0BE1EBA0-7F7127F1/0-0/0-15 X-purgate-size: 2055/0 Subject: Re: [MEXT] Generic Signaling Message / Name of generic "notification"(Was: Scope of generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien, Would it still be possible to allocate new MH types for new MIP messages? I= f the answer is yes, then we need some criteria to define which new message= s get its own MH type and which become an MGSM message. Otherwise this defi= nition will not help avoding the discussions that we have right now about B= RI and MH type. domagoj > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On = > Behalf Of Julien Laganier > Sent: 05. lipanj 2008 17:43 > To: mext@ietf.org > Subject: [MEXT] Generic Signaling Message / Name of generic = > "notification"(Was: Scope of generic notification) > = > On Tuesday 03 June 2008, Michael Eriksson wrote: > > - I don't particularly like the "notification" part of = > GNM's name, as > > =A0 I think it will should be used for more than notifications. > = > Folks, > = > > = > What Michael said above rang a bell :) > = > How about calling the new framework "MIPv6 Generic Signaling = > Message (MGSM), and defines two MH types, one requiring = > IPsec, the other not. > = > Then we would distinguish different types of messages = > (Revocation, Flow Distribution Rules, Heartbeat, etc.) based = > on a subtype inside the Generic Signaling Message. > = > I think that should satisfy everybody: > - the IPsec SPD needs only one set of rules for each of the = > MH types (bypass, and protect). > - a MGSM consumer (e.g. Revocation, Distribution Rules) = > simply specify the MH type it chooses depending on whether or = > not it requires IPsec protection. > - a MGSM consumer allocates one or more MGSM subtypes for = > each new message necessary to implement the consumer's functionality. > - a MGSM consumer specifies processing (sending, receiving, state > machines...) for these subtyped messages. > = > What do you think? > = > --julien > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 11 00:56:30 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A055F3A6845; Wed, 11 Jun 2008 00:56:30 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40CEF3A6845; Wed, 11 Jun 2008 00:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHDZa1FYCFXw; Wed, 11 Jun 2008 00:56:28 -0700 (PDT) Received: from ws000774.tietoenator.com (ws000774.tietoenator.com [193.12.181.129]) by core3.amsl.com (Postfix) with ESMTP id 9EB173A6835; Wed, 11 Jun 2008 00:56:27 -0700 (PDT) X-AuditID: c10cb581-00000efc000004dc-c5-484f853f6e05 Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jun 2008 09:56:47 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 09:56:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Jun 2008 09:56:47 +0200 Message-ID: In-Reply-To: <87d4mp5uc5.fsf@natisbad.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Clarifications on dynamic HoA assignment by IKE (RFC 4877and 5026) thread-index: AcjK+G/bHVgdcOk1TNSO//tJbG8UmQAoAolg References: <87d4mp5uc5.fsf@natisbad.org> From: To: , X-OriginalArrivalTime: 11 Jun 2008 07:56:48.0264 (UTC) FILETIME=[B33CE880:01C8CB98] X-Brightmail-Tracker: AAAAAA== Cc: IPsec@ietf.org Subject: Re: [MEXT] [IPsec] Clarifications on dynamic HoA assignment by IKE (RFC 4877and 5026) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Some coordination between IKE and MIP is required, but in my view, IKE and MIP can be implemented separately. Assume a node has a single mobile application/process, which requires uninterrupted IP connectivity. As long as this application is not started, all other applications just use the addresses as available, and have to give up/restart when addresses are removed. When the mobile application is to be started, whoever starts the mobile application has to ensure a mobile address is available; if no mobile address is available, it must be created (bootstrapping), namely by running IKE from one of the available addresses on one of the interfaces towards the home agent, and if from IKE is received an address in a CFG payload which differs from the available address used, then a BU/BA exchange to set up the tunnels. Thus, someone has to coordinate IKE and MIP, but they can be implemented as separate modules. Christian > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Arnaud Ebalard > Sent: 10. juni 2008 14:49 > To: IETF MEXT WG > Cc: IETF IPsec WG > Subject: [IPsec] Clarifications on dynamic HoA assignment by > IKE (RFC 4877and 5026) > > Hi, > > I just read again RFC 4877 and RFC 5026 (and related sections of RFC > 4306) and I have questions. IPsec WG is in Cc; sorry if you > receive the mail twice and also for its length. > > In RFC 4877, it is written that "the home agent and the > mobile node MAY support remote configuration of the home > address". This is specifically covered in Section 9 but there > are related notes in other parts of the document. > > Simply put, my questions would be: "What are the *detailed* > steps by which IKE negotiation will be *triggered* on the > Mobile Node in the process of getting a HoA dynamically > assigned? How is the address provided to the MIPv6 module?". > > More precisely, I'd like to clarify the following points: > > SPD entries provided in section 7.2.1 make use of > home_address_1 which might not be available yet (at least on > the mobile node). This is commented after the SPD entries: > "In the examples shown above, the home address of the mobile > node might not be available all the time. > For instance, the mobile node might not have configured a > home address yet. When the mobile node acquires a new home > address, it must either add the address to the corresponding > SPD entries or create the SPD entries for the home address." > Associated questions are: > > o Which address should be used meanwhile (in the SPD entries on the > MN, for instance)? > o how will the IKE negotiation be triggered, i.e. by which packet? > o how can the SPD entries be added afterwhile if they are supposed to > trigger IKE negotiation? > > I think I have missed something in the reference documents > because I am under the impression that *something* makes IKE > start a negotiation without any SPD related event (like a > packet matching a SP and asking for protection) to get a HoA, > but I am unable to find what. Is it implicitly expected that > the IKE daemon starts an IKE_AUTH exchange to grab a HoA on > its own? What is controlled by MIPv6 / what is not? How? > I'll appreciate some feedback on that. > > > Now, regarding RFC 5026, there are 7 references to RFC 4877: > the use of previous HoA assignement is also listed based on > content of RFC 4877 and another mechanism (section 5.3.2, HoA > Auto-Configuration by the Mobile Node) which allows the MN to > get the prefix it should use to autoconfigure an address it > will then send back to the HA. Like previous HoA assignment, > the prefix is obtained using IKEv2 during IKE_AUTH exchange. > Basically, I have the same questions as for dynamic HoA > assignement above. How are things triggered? Who controls > what? How is the synchronization between IKE and MIPv6 performed? > > > In the end, after reading those 2 documents, I am under the > impression (do not hesitate to correct me) that the MIPv6 > process on the MN has the ability to *trigger* an IKE > negotiation with the IKE daemon on its HA for the purpose of > configuring its HoA. I am also under the impression that this > neogiation is not the result of an SPD lookup indicating that > a queued packet requires protection. > > Then I looked at RFC 4306 to find some answers. There are > some elements on the topic in Section 1.1.3, at the end of > section 2.9, in section > 2.19 and in section 3.15 but the scenario where IKE starts > negotiation and gets the HoA on its own just looks odd. > > In RFC 3776 (for static and dynamic keying) and for > statically assigned HoA in RFC 4877, MIPv6 module handles > HoA, and IKE acts accordingly (yes, it needs some > modification to bootstrap) but in the dynamic assignment > case, the scenario is reversed and IKE starts and > "configures" MIPv6 (at least for the HoA part). This is not > explicitly stated (if my understanding and descriptions are > correct) and the details are missing in associated document > (AFAICT). > > When reading RFC 4877 and RFC 5026, I was under the impression that > MIPv6 and IKE are expected to be one unique entity. I wonder > how it will be possible in that context to have separate > IKEv2 and MIPv6 implementations interoperate on the same MN, HA or MR. > > If I missed some documents, don't hesitate to tell. > > Thanks, > > a+ > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 11 02:28:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFB973A6869; Wed, 11 Jun 2008 02:28:28 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA38E3A6994 for ; Wed, 11 Jun 2008 02:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDw4mf4psQYi for ; Wed, 11 Jun 2008 02:28:25 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by core3.amsl.com (Postfix) with ESMTP id 74D9A3A6869 for ; Wed, 11 Jun 2008 02:28:25 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id y36so55719ugd.46 for ; Wed, 11 Jun 2008 02:28:49 -0700 (PDT) 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=8WNqrGKMmds2oyTA4metOI+KCqjkedL9A1OxtJjLaVA=; b=FpOVEiDZy327j2ryG+JziOV/OlVjxH43b2TJ/b6bD7U/oAJhWKmrTmXKN3IaJ4cl7G vR/jH+VfaES+eBmhTEOOMtnMQSpdyg8tODNSSd5keeHdIdVgq8Uf3YdF7GY++8ylMK4x 3b8ourPnA3aELUu3WLTeDpNTgJm08f2uJl8Yo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:sender; b=IFgtCPoJLJ8fHcTpGF4kimPhf6hlWJxMrVHvq68hOdh+GWjufvEBiFF5kVwbEa4p4h YXzQRtUdNd6gg1/l/yXJ+iAgGF+77ezMTfuo/XZE7VtuG/FVg9hqnPcKKMOQ8BWU7U+e cXtNlY6N4SVTupOrTm6AgwmMpRIpbpJx7k8uA= Received: by 10.210.41.14 with SMTP id o14mr4981217ebo.137.1213176529400; Wed, 11 Jun 2008 02:28:49 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id j8sm20207126gvb.1.2008.06.11.02.28.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Jun 2008 02:28:47 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Wed, 11 Jun 2008 11:28:46 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <483D5A50.1000208@it.uc3m.es> <200806051742.39799.julien.IETF@laposte.net> <3C31CDD06342EA4A8137716247B1CD6803FDB472@zagh223a.ww300.siemens.net> In-Reply-To: <3C31CDD06342EA4A8137716247B1CD6803FDB472@zagh223a.ww300.siemens.net> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806111128.46428.julien.IETF@laposte.net> Subject: Re: [MEXT] Generic Signaling Message / Name of generic "notification"(Was: Scope of generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Domagoj, On Wednesday 11 June 2008, Premec, Domagoj wrote: > Julien, > > Would it still be possible to allocate new MH types for new MIP > messages? = Yes it would be possible. The plan is to design a MGSM framework that is = as generic as possible and should thus be suitable to most needs. = However we can't predict for sure that an usage that can't be satisfied = with MGSM won't arise in the future. > If the answer is yes, then we need some criteria to define = > which new messages get its own MH type and which become an MGSM > message. Otherwise this definition will not help avoding the > discussions that we have right now about BRI and MH type. I don't think we need a criteria -- The BRI/MH type discussion happened = because we hadn't an MGSM framework yet. = Once we have MGSM, and we have a specific protocol extension to realize, = it's IMO pretty straightforward to decide between new MH types and = MGSM: Either the protocol extension can be realized with MGSM thus it = uses MGSM, or it can't thus it gets new header types. An alternative = could also be to extend MGSM so that it can supports the new protocol = extension. --julien > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of Julien Laganier > > Sent: 05. lipanj 2008 17:43 > > To: mext@ietf.org > > Subject: [MEXT] Generic Signaling Message / Name of generic > > "notification"(Was: Scope of generic notification) > > > > On Tuesday 03 June 2008, Michael Eriksson wrote: > > > - I don't particularly like the "notification" part of > > > > GNM's name, as > > > > > =A0 I think it will should be used for more than notifications. > > > > Folks, > > > > > > > > What Michael said above rang a bell :) > > > > How about calling the new framework "MIPv6 Generic Signaling > > Message (MGSM), and defines two MH types, one requiring > > IPsec, the other not. > > > > Then we would distinguish different types of messages > > (Revocation, Flow Distribution Rules, Heartbeat, etc.) based > > on a subtype inside the Generic Signaling Message. > > > > I think that should satisfy everybody: > > - the IPsec SPD needs only one set of rules for each of the > > MH types (bypass, and protect). > > - a MGSM consumer (e.g. Revocation, Distribution Rules) > > simply specify the MH type it chooses depending on whether or > > not it requires IPsec protection. > > - a MGSM consumer allocates one or more MGSM subtypes for > > each new message necessary to implement the consumer's > > functionality. - a MGSM consumer specifies processing (sending, > > receiving, state machines...) for these subtyped messages. > > > > What do you think? > > > > --julien > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 11 08:27:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 014A33A6953; Wed, 11 Jun 2008 08:27:03 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B6D23A6953 for ; Wed, 11 Jun 2008 08:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzPOoBEHGPI3 for ; Wed, 11 Jun 2008 08:27:00 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by core3.amsl.com (Postfix) with ESMTP id 684023A6878 for ; Wed, 11 Jun 2008 08:27:00 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id i29so1469479wxd.31 for ; Wed, 11 Jun 2008 08:27:23 -0700 (PDT) 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=+NYQS5NPw3QbcPzs+w04D4oAxSPB+Mbwa676sd04Ras=; b=JQCijL+tfjBwmj90d5/qpZlXZl9v1pGE8FGI/gcKte/kEJf2E1iEX9mUcIxp2J81Mh XfGw9UcXg7KRbyvilO1qbNRE3nZ4tMjcr5aLbjc5zMm1XxNobdCiOWAt4n+h7N9SjOGc 1hjkHGEelufu/+Z4OJebIa+3Y5vGJnWHTQQ14= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=aLbSBACM1ro82epp5S0un2k4ro6eJGT/V3iLKphFLCSM9iTNQnDLLHooiERFx2dGmU tjPHX1bNmx5G/Qt05IcSaA7sJ0fO8fheI54r1/3ojTETaAPSB/wLGnnyDJLrVizM4Tvf LrYMf0KP5xbC0a07/CH3j+QsvVL90nBku3a0w= Received: by 10.70.58.2 with SMTP id g2mr8040475wxa.20.1213198043444; Wed, 11 Jun 2008 08:27:23 -0700 (PDT) Received: by 10.70.55.11 with HTTP; Wed, 11 Jun 2008 08:27:23 -0700 (PDT) Message-ID: <729b68be0806110827k5ac05aa3hed4a9146d2ed95e2@mail.gmail.com> Date: Wed, 11 Jun 2008 17:27:23 +0200 From: "Jean-Michel Combes" To: "Frank Xia" In-Reply-To: <000b01c8ca59$c65c3190$5c0c7c0a@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline References: <48401470.40706@it.uc3m.es> <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> <006001c8c81d$e5581160$5c0c7c0a@china.huawei.com> <004901c8c825$a9ad9650$5c0c7c0a@china.huawei.com> <729b68be0806061630i7d88afa2w235dad4bafe74daa@mail.gmail.com> <010301c8ca40$270a6710$5c0c7c0a@china.huawei.com> <729b68be0806090905n1c48163fw11a75825994ca73@mail.gmail.com> <000b01c8ca59$c65c3190$5c0c7c0a@china.huawei.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Frank, At first I assume this is the HA that delegates the MNPs. 2008/6/9, Frank Xia : > Hi JMC > > Firstly, the certificate issuing party is not supposed to be HA, so > the certificate does not mandatorily get from the HA. Agree. The HA has just to provide the cert. > Or, how does the HA get the certificate of the MR? HA may be the Certificate Authority or a Registration Authority. > > Secondly, if the prefix information can't be sychronized between > the certificate issuing party and the HA, the prefix should not > included in the certificate. AFAIK, the HA is always aware of the delegated MNPs: in explicit mode with the Prefix Table and in implicit mode where it is assumed the HA knows the MNPs in using a specific mechanism > > There are same concerns with PMIPv6 when you insist that > the certificate should be delegated from the HA. IMHO, this is the simplest solution when we assume this is the HA/LMA that delegates the prefixes. Best regards. > > There is no perfect solution but compromised solution. > > BR > Frank > > ----- Original Message ----- From: "Jean-Michel Combes" > > To: "Frank Xia" > Cc: "fan zhao" ; ; "Julien Laganier" > > Sent: Monday, June 09, 2008 11:05 AM > > Subject: Re: [MEXT] Adoption of > draft-droms-mext-nemo-pd-00.txt? > > > > > Hi Frank, > > > > If SEND is deployed in the NEMO network (i.e. MR's ingress interface), > > at the same time the HA has to provide the MNPs, it has to provide the > > Router Authorization Certificate linked to the MNPs. > > > > There is no relationship between IKE and SEND, by the way. > > > > Best regards. > > > > JMC. > > > > 2008/6/9, Frank Xia : > > > > > Hi Jean-Michel > > > > > > Even in SEND, IMHO, it is not necessary for HA to > > > provide Router Authorization Certificate because > > > HA and MR have authenticated each other using > > > IKE, etc. > > > > > > Anyway, this scenario is not clear. > > > > > > BR > > > Frank > > > > > > ----- Original Message ----- From: "Jean-Michel Combes" > > > > > > To: "Frank Xia" > > > Cc: "fan zhao" ; ; "Julien > Laganier" > > > > > > Sent: Friday, June 06, 2008 6:30 PM > > > > > > Subject: Re: [MEXT] Adoption of > > > draft-droms-mext-nemo-pd-00.txt? > > > > > > > > > > > > > Hi, > > > > > > > > Don't forget that people may want to deploy SEND and so you will have > > > > to provide Router Authorization Certificate too in that case. > > > > AFAIK, for the moment, there is no proposal to provide such > > > > certificates with PBU/PBA and so you will have another mechanism. The > > > > consequence is that you will loose the advantage in time you gained in > > > > piggybacking the delegated prefixes in the PBU/PBA ... > > > > > > > > This is not the case with PMIP because the LMA is aware of the > > > > prefixes assigned to the MAGs and during the set up of > > > > > > > > 2008/6/7, Frank Xia : > > > > > > > > > Hi Fan > > > > > > > > > > Please check my reply... > > > > > > > > > > > > > > > BR > > > > > Frank > > > > > > > > > > ----- Original Message ----- > > > > > From: "fan zhao" > > > > > To: "Frank Xia" > > > > > Cc: "Ryuji Wakikawa" ; "Julien Laganier" > > > > > ; > > > > > > > > > > Sent: Friday, June 06, 2008 5:22 PM > > > > > Subject: Re: [MEXT] Adoption of > > > draft-droms-mext-nemo-pd-00.txt? > > > > > > > > > > > > > > > > Hi Frank, > > > > > > > > > > > > Please see below.. > > > > > > > > > > > > On Fri, Jun 6, 2008 at 2:40 PM, Frank Xia > > > > wrote: > > > > > >> Hi Fan > > > > > >> > > > > > >> Please see my reply... > > > > > >> > > > > > >> BR > > > > > >> Frank > > > > > >> > > > > > >> ----- Original Message ----- From: "fan zhao" > > > > > > > > >> To: "Frank Xia" > > > > > >> Cc: "Ryuji Wakikawa" ; "Julien > > > Laganier" > > > > > >> ; > > > > > >> Sent: Friday, June 06, 2008 3:33 PM > > > > > >> Subject: Re: [MEXT] Adoption of > > > draft-droms-mext-nemo-pd-00.txt? > > > > > >> > > > > > >> > > > > > >>> Hi Frank, > > > > > >>> > > > > > >>> Please see below. > > > > > >>> > > > > > >>> On Fri, Jun 6, 2008 at 10:51 AM, Frank Xia > > > > > > > > >>> wrote: > > > > > >>>> > > > > > >>>> Hi Fan, Ryuji and other colleagues. > > > > > >>>> > > > > > >>>> Agreed. > > > > > >>>> > > > > > >>>> IMHO,There are two ways for prefix delegation in Nemo, > > > > > >>>> that is, overlay and integrated modes. > > > > > >>>> > > > > > >>>> DHCP based PD is a overlay solution which introduce redundancy > > > > > >>>> while trying to reduce impact on NEMO itself. > > > > > >>>> > > > > > >>>> I favor the integrated mode in which Prefix Delegation is > > > integrated > > > > > >>>> into > > > > > >>>> NEMO operations > > > > > >>> > > > > > >>> I agree that signaling overhead can be reduced if multiple > > > _related_ > > > > > >>> requests/responses > > > > > >>> are piggybacked together, e.g. during one message exchange. For > > > the > > > MR > > > > > >>> to work, it > > > > > >>> needs both a HoA/HNP and a MNP. Besides requesting/registering > > > the > > > > > >>> MNP, there is > > > > > >>> no much difference between the operation of the MN and that of > > > the > > > MR. > > > > > >>> Furthermore, > > > > > >>> the MR can request the MNP during the establishment of IPSec SA > > > when > > > > > >>> it is at either home link or foreign link. > > > > > >> > > > > > >> Frank=>For adressing in NEMO, there are two categories > > > > > >> nodes for addressing, that is, MRs and hosts behind MRs. > > > > > >> > > > > > >> IKE can be used for MR's addressing, while it probabaly > > > > > >> can't be used for host addressing (PD) without extension of IKE. > > > > > > > > > > > > Fan> We can simply define a new attribute carried in the > > > > > > CFG_REQUEST/CFG_REPLY > > > > > > configuration payload during the IKE_AUTH exchange. > > > > > > > > > > Frank=>It couples PD with IKE procedure. How does the > > > > > MR renew/release/renumber the prefixes after IKE_AUTH exchange? > > > > > Anyway, IKE is not solely for MIP, IMHO, it is not proper to > > > > > extend for this purpose. > > > > > > > > > > IMO, the compromised way is to use BA/BU which > > > > > is in line with PMIP thoughtway. > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > >>> > > > > > >>>> because prefix management is an integrated part > > > > > >>>> of NEMO. > > > > > >>>> PMIPv6 follow the same philosophy. > > > > > >>> > > > > > >>> If I understand correctly, PMIP is a slightly different case > > > from > > > > > >>> DSMIPv6/NEMO. > > > > > >>> Because the connection, such as the IPSec SA, between the MAG > > > and > > > the > > > > > >>> LMA > > > > > >>> is already in place long before the MN attaches to the MAG, it > > > makes > > > > > >>> sense > > > > > >>> for > > > > > >>> the MAG to request the HNP for the MN during the PBU/PBA > > > exchange. > > > With > > > > > >>> DSMIPv6, the MN requests the HoA/HNP during the establishment > of > > > the > > > > > >>> IPSec > > > > > >>> SA, therefore the MR should request the MNP during this > > > procedure > > > as > > > > > >>> well. > > > > > >> > > > > > >> Frank=>It is true there is difference between PMIP and NEMO. > > > > > >> I just do an analogy. What I want to say is it makes sense if > > > we > > > > > >> integrate > > > > > >> PD > > > > > >> into NEMO. > > > > > > > > > > > > Fan> OK. > > > > > > > > > > > > Sincerely, > > > > > > fan > > > > > > > > > > > >> > > > > > >>> > > > > > >>> What do you think? > > > > > >>> > > > > > >>> Sincerely, > > > > > >>> fan > > > > > >>> > > > > > >>>> > > > > > >>>> BR > > > > > >>>> Frank > > > > > >>>> > > > > > >>>> ----- Original Message ----- From: "fan zhao" > > > > > > > > >>>> To: "Ryuji Wakikawa" > > > > > >>>> Cc: "Julien Laganier" ; > > > > > > > > >>>> Sent: Friday, June 06, 2008 12:18 PM > > > > > >>>> Subject: Re: [MEXT] Adoption of > > > draft-droms-mext-nemo-pd-00.txt? > > > > > >>>> > > > > > >>>> > > > > > >>>>> Hi Ryuji and et al, > > > > > >>>>> > > > > > >>>>> Sorry for jumping in. > > > > > >>>>> I agree with Ryuji that the DHCP based PD procedure > introduces > > > > > >>>>> redundancy. > > > > > >>>>> IMHO, the MR can request a MNP together with a HNP/HoA when > > > > > >>>>> establishing > > > > > >>>>> the IPSec SA with the HA. IMO, this is simpler. Do I miss > > > something? > > > > > >>>>> Thanks. > > > > > >>>>> > > > > > >>>>> Sincerely, > > > > > >>>>> fan > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> On Wed, Jun 4, 2008 at 5:37 PM, Ryuji Wakikawa > > > > > >>>>> > > > > > >>>>> wrote: > > > > > >>>>>> > > > > > >>>>>> Hello Pascal, > > > > > >>>>>> > > > > > >>>>>> Sorry for late response. We have interop event in Tokyo and > > > tested > > > > > >>>>>> HAHA there;-) > > > > > >>>>>> > > > > > >>>>>> On 2008/06/03, at 17:08, Pascal Thubert (pthubert) wrote: > > > > > >>>>>> > > > > > >>>>>>> Hi Ryuji: > > > > > >>>>>>> > > > > > >>>>>>> I agree that PD should not impact bootstrap. These are and > > > should be > > > > > >>>>>>> kept unrelated. > > > > > >>>>>>> > > > > > >>>>>>> We must be able to extend a RFC 3963 MR with PD without > > > forcing > > > the > > > > > >>>>>>> bootstrap process in the picture. So I agree not to bring > > > DHAAD > > > back > > > > > >>>>>>> into the bootstrap... > > > > > >>>>>> > > > > > >>>>>> we agree then.. > > > > > >>>>>> > > > > > >>>>>>> But I think that PD is NOT a bootstrap process. It is post > > > bootstrap > > > > > >>>>>>> and > > > > > >>>>>>> can reoccur many times in the life of the MR. > > > > > >>>>>>> > > > > > >>>>>>> Until we define a new process and rev 3775 and 3963, we > > > should > > > stay > > > > > >>>>>>> consistent and simple in what we are doing. > > > > > >>>>>> > > > > > >>>>>> DHCP-PD can surely impact to the bootstrap process. > > > > > >>>>>> > > > > > >>>>>> Let's say MR boots up as a MN with RFC5026 first. > > > > > >>>>>> Then, it tries to get a MNP for NEMO. > > > > > >>>>>> > > > > > >>>>>> If the current HA is not PD-enabled and DHAAD returns > > > different > > > HA, > > > > > >>>>>> MR must de-register the binding from the current HA and > tries > > to > > > > > >>>>>> start > > > > > >>>>>> all the registration process to the new HA. > > > > > >>>>>> > > > > > >>>>>> This seems very redundant operation.. > > > > > >>>>>> I want to make the PD spec simple. > > > > > >>>>>> > > > > > >>>>>> regards > > > > > >>>>>> ryuji > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>>> > > > > > >>>>>>> > > > > > >>>>>>> Pascal > > > > > >>>>>>> > > > > > >>>>>>>> -----Original Message----- > > > > > >>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > > > On > > > > > >>>>>>>> Behalf Of > > > > > >>>>>>> > > > > > >>>>>>> Ryuji Wakikawa > > > > > >>>>>>>> > > > > > >>>>>>>> Sent: mardi 3 juin 2008 09:54 > > > > > >>>>>>>> To: marcelo bagnulo braun > > > > > >>>>>>>> Cc: Julien Laganier; mext@ietf.org > > > > > >>>>>>>> Subject: Re: [MEXT] Adoption of > > > draft-droms-mext-nemo-pd-00.txt? > > > > > >>>>>>>> > > > > > >>>>>>>> Hi Marcelo, > > > > > >>>>>>>> > > > > > >>>>>>>> I agree to accept this as WG doc. > > > > > >>>>>>>> > > > > > >>>>>>>> I also agree with Romain and Vijay. > > > > > >>>>>>>> We don't need extension to DHAAD. > > > > > >>>>>>>> Since MR can act as MN, MR should be able to bootstrap > with > > > the > > > > > >>>>>>>> same > > > > > >>>>>>>> mechanism of MIP (except for PD). > > > > > >>>>>>>> We should not bring DHAAD back in the bootstrap process > > > only > > > for > > > > > >>>>>>>> PD. > > > > > >>>>>>>> > > > > > >>>>>>>> regards, > > > > > >>>>>>>> ryuji > > > > > >>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>> On 2008/05/30, at 23:51, marcelo bagnulo braun wrote: > > > > > >>>>>>>> > > > > > >>>>>>>>> Hi, > > > > > >>>>>>>>> > > > > > >>>>>>>>> We would like to ask the WG what is their opinion about > > > accepting > > > > > >>>>>>>>> draft-droms-mext-nemo-pd-00.txt as the WG document for > the > > > Nemo PD > > > > > >>>>>>>>> deliverable included in our charter. > > > > > >>>>>>>>> > > > > > >>>>>>>>> Please provide comments so we cna make some progress on > > > this > > > long > > > > > >>>>>>>>> overdue deliverable > > > > > >>>>>>>>> > > > > > >>>>>>>>> thanks, Julien and marcelo > > > > > >>>>>>>>> -------- Mensaje original -------- > > > > > >>>>>>>>> Asunto: I-D > > > Action:draft-droms-mext-nemo-pd-00.txt > > > > > >>>>>>>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) > > > > > >>>>>>>>> De: Internet-Drafts@ietf.org > > > > > >>>>>>>>> Responder a: internet-drafts@ietf.org > > > > > >>>>>>>>> Para: i-d-announce@ietf.org > > > > > >>>>>>>>> > > > > > >>>>>>>>> > > > > > >>>>>>>>> > > > > > >>>>>>>>> A New Internet-Draft is available from the on-line > > > Internet-Drafts > > > > > >>>>>>>>> directories. > > > > > >>>>>>>>> > > > > > >>>>>>>>> Title : DHCPv6 Prefix Delegation for NEMO > > > > > >>>>>>>>> Author(s) : R. Droms, et al. > > > > > >>>>>>>>> Filename : draft-droms-mext-nemo-pd-00.txt > > > > > >>>>>>>>> Pages : 12 > > > > > >>>>>>>>> Date : 2008-05-30 > > > > > >>>>>>>>> > > > > > >>>>>>>>> One aspect of network mobility support is the assignment > > > of a > > > > > >>>>>>>>> prefix > > > > > >>>>>>>>> or prefixes to a Mobile Router (MR) for use on the links > > > in > > > the > > > > > >>>>>>>>> Mobile Network. DHCPv6 prefix delegation can be used for > > > this > > > > > >>>>>>>>> configuration task. > > > > > >>>>>>>>> > > > > > >>>>>>>>> A URL for this Internet-Draft is: > > > > > >>>>>>>>> > > > > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt > > > > > >>>>>>>>> > > > > > >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: > > > > > >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ > > > > > >>>>>>>>> > > > > > >>>>>>>>> Below is the data which will enable a MIME compliant mail > > > reader > > > > > >>>>>>>>> implementation to automatically retrieve the ASCII > version > > of > > > the > > > > > >>>>>>>>> Internet-Draft. > > > > > >>>>>>>>> > > > > > >>>>>>>>> > > > > > >>>>>>>>> Content-Type: text/plain > > > > > >>>>>>>>> Content-ID: <2008-05-30054232.I-D@ietf.org> > > > > > >>>>>>>>> > > > > > >>>>>>>>> > > > > > >>>>>>>>> > > > _______________________________________________ > > > > > >>>>>>>>> I-D-Announce mailing list > > > > > >>>>>>>>> I-D-Announce@ietf.org > > > > > >>>>>>>>> > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > > >>>>>>>>> Internet-Draft directories: > > > http://www.ietf.org/shadow.html > > > > > >>>>>>>>> or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > >>>>>>>>> > > > > > >>>>>>>>> > > > _______________________________________________ > > > > > >>>>>>>>> MEXT mailing list > > > > > >>>>>>>>> MEXT@ietf.org > > > > > >>>>>>>>> > https://www.ietf.org/mailman/listinfo/mext > > > > > >>>>>>>> > > > > > >>>>>>>> > > > _______________________________________________ > > > > > >>>>>>>> MEXT mailing list > > > > > >>>>>>>> MEXT@ietf.org > > > > > >>>>>>>> > https://www.ietf.org/mailman/listinfo/mext > > > > > >>>>>> > > > > > >>>>>> > _______________________________________________ > > > > > >>>>>> MEXT mailing list > > > > > >>>>>> MEXT@ietf.org > > > > > >>>>>> https://www.ietf.org/mailman/listinfo/mext > > > > > >>>>>> > > > > > >>>>> > _______________________________________________ > > > > > >>>>> MEXT mailing list > > > > > >>>>> MEXT@ietf.org > > > > > >>>>> https://www.ietf.org/mailman/listinfo/mext > > > > > >>>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>> > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > MEXT mailing list > > > > > MEXT@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 11 08:38:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271D13A6879; Wed, 11 Jun 2008 08:38:40 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A1D93A6879 for ; Wed, 11 Jun 2008 08:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbM+-lWOn7sK for ; Wed, 11 Jun 2008 08:38:34 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 5CC603A6835 for ; Wed, 11 Jun 2008 08:38:34 -0700 (PDT) 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 <0K2B00K8324ZFD@usaga04-in.huawei.com> for mext@ietf.org; Wed, 11 Jun 2008 10:38:59 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K2B00IPU24XA0@usaga04-in.huawei.com> for mext@ietf.org; Wed, 11 Jun 2008 10:38:59 -0500 (CDT) Date: Wed, 11 Jun 2008 10:38:57 -0500 From: Frank Xia To: Jean-Michel Combes Message-id: <00df01c8cbd9$43c513b0$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <48401470.40706@it.uc3m.es> <006301c8c7fd$fa43f4b0$5c0c7c0a@china.huawei.com> <006001c8c81d$e5581160$5c0c7c0a@china.huawei.com> <004901c8c825$a9ad9650$5c0c7c0a@china.huawei.com> <729b68be0806061630i7d88afa2w235dad4bafe74daa@mail.gmail.com> <010301c8ca40$270a6710$5c0c7c0a@china.huawei.com> <729b68be0806090905n1c48163fw11a75825994ca73@mail.gmail.com> <000b01c8ca59$c65c3190$5c0c7c0a@china.huawei.com> <729b68be0806110827k5ac05aa3hed4a9146d2ed95e2@mail.gmail.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi JMC Thank for your response, please see my inline comments... BR Frank ----- Original Message ----- From: "Jean-Michel Combes" To: "Frank Xia" Cc: "fan zhao" ; ; "Julien Laganier" Sent: Wednesday, June 11, 2008 10:27 AM Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > Hi Frank, > > At first I assume this is the HA that delegates the MNPs. > > 2008/6/9, Frank Xia : >> Hi JMC >> >> Firstly, the certificate issuing party is not supposed to be HA, so >> the certificate does not mandatorily get from the HA. > > Agree. The HA has just to provide the cert. > >> Or, how does the HA get the certificate of the MR? > > HA may be the Certificate Authority or a Registration Authority. Frank=>IMHO, it seems to be impossible. In extreme case, there are probably thousands of HA in the a administrative domain. (In 3GPP, if a serving gateway and a PDN gateway are collocated, the distributed HA network is possible) > >> >> Secondly, if the prefix information can't be sychronized between >> the certificate issuing party and the HA, the prefix should not >> included in the certificate. > > AFAIK, the HA is always aware of the delegated MNPs: in explicit mode > with the Prefix Table and in implicit mode where it is assumed the HA > knows the MNPs in using a specific mechanism > >> >> There are same concerns with PMIPv6 when you insist that >> the certificate should be delegated from the HA. > > IMHO, this is the simplest solution when we assume this is the HA/LMA > that delegates the prefixes. > > Best regards. > >> >> There is no perfect solution but compromised solution. >> >> BR >> Frank >> >> ----- Original Message ----- From: "Jean-Michel Combes" >> >> To: "Frank Xia" >> Cc: "fan zhao" ; ; "Julien >> Laganier" >> >> Sent: Monday, June 09, 2008 11:05 AM >> >> Subject: Re: [MEXT] Adoption of >> draft-droms-mext-nemo-pd-00.txt? >> >> >> >> > Hi Frank, >> > >> > If SEND is deployed in the NEMO network (i.e. MR's ingress interface), >> > at the same time the HA has to provide the MNPs, it has to provide the >> > Router Authorization Certificate linked to the MNPs. >> > >> > There is no relationship between IKE and SEND, by the way. >> > >> > Best regards. >> > >> > JMC. >> > >> > 2008/6/9, Frank Xia : >> > >> > > Hi Jean-Michel >> > > >> > > Even in SEND, IMHO, it is not necessary for HA to >> > > provide Router Authorization Certificate because >> > > HA and MR have authenticated each other using >> > > IKE, etc. >> > > >> > > Anyway, this scenario is not clear. >> > > >> > > BR >> > > Frank >> > > >> > > ----- Original Message ----- From: "Jean-Michel Combes" >> > > >> > > To: "Frank Xia" >> > > Cc: "fan zhao" ; ; "Julien >> Laganier" >> > > >> > > Sent: Friday, June 06, 2008 6:30 PM >> > > >> > > Subject: Re: [MEXT] Adoption of >> > > draft-droms-mext-nemo-pd-00.txt? >> > > >> > > >> > > >> > > > Hi, >> > > > >> > > > Don't forget that people may want to deploy SEND and so you will >> > > > have >> > > > to provide Router Authorization Certificate too in that case. >> > > > AFAIK, for the moment, there is no proposal to provide such >> > > > certificates with PBU/PBA and so you will have another mechanism. >> > > > The >> > > > consequence is that you will loose the advantage in time you gained >> > > > in >> > > > piggybacking the delegated prefixes in the PBU/PBA ... >> > > > >> > > > This is not the case with PMIP because the LMA is aware of the >> > > > prefixes assigned to the MAGs and during the set up of >> > > > >> > > > 2008/6/7, Frank Xia : >> > > > >> > > > > Hi Fan >> > > > > >> > > > > Please check my reply... >> > > > > >> > > > > >> > > > > BR >> > > > > Frank >> > > > > >> > > > > ----- Original Message ----- >> > > > > From: "fan zhao" >> > > > > To: "Frank Xia" >> > > > > Cc: "Ryuji Wakikawa" ; "Julien >> > > > > Laganier" >> > > > > ; >> > > > > >> > > > > Sent: Friday, June 06, 2008 5:22 PM >> > > > > Subject: Re: [MEXT] Adoption of >> > > draft-droms-mext-nemo-pd-00.txt? >> > > > > >> > > > > >> > > > > > Hi Frank, >> > > > > > >> > > > > > Please see below.. >> > > > > > >> > > > > > On Fri, Jun 6, 2008 at 2:40 PM, Frank Xia >> >> > > wrote: >> > > > > >> Hi Fan >> > > > > >> >> > > > > >> Please see my reply... >> > > > > >> >> > > > > >> BR >> > > > > >> Frank >> > > > > >> >> > > > > >> ----- Original Message ----- From: "fan zhao" > > >> >> > > > > >> To: "Frank Xia" >> > > > > >> Cc: "Ryuji Wakikawa" ; "Julien > > >> Laganier" >> > > > > >> ; >> > > > > >> Sent: Friday, June 06, 2008 3:33 PM >> > > > > >> Subject: Re: [MEXT] Adoption of >> > > draft-droms-mext-nemo-pd-00.txt? >> > > > > >> >> > > > > >> >> > > > > >>> Hi Frank, >> > > > > >>> >> > > > > >>> Please see below. >> > > > > >>> >> > > > > >>> On Fri, Jun 6, 2008 at 10:51 AM, Frank Xia > > >> >> > > > > >>> wrote: >> > > > > >>>> >> > > > > >>>> Hi Fan, Ryuji and other colleagues. >> > > > > >>>> >> > > > > >>>> Agreed. >> > > > > >>>> >> > > > > >>>> IMHO,There are two ways for prefix delegation in Nemo, >> > > > > >>>> that is, overlay and integrated modes. >> > > > > >>>> >> > > > > >>>> DHCP based PD is a overlay solution which introduce >> > > > > redundancy >> > > > > >>>> while trying to reduce impact on NEMO itself. >> > > > > >>>> >> > > > > >>>> I favor the integrated mode in which Prefix Delegation is >> > > integrated >> > > > > >>>> into >> > > > > >>>> NEMO operations >> > > > > >>> >> > > > > >>> I agree that signaling overhead can be reduced if multiple >> > > _related_ >> > > > > >>> requests/responses >> > > > > >>> are piggybacked together, e.g. during one message exchange. >> > > > > For >> > > the >> > > MR >> > > > > >>> to work, it >> > > > > >>> needs both a HoA/HNP and a MNP. Besides >> > > > > requesting/registering >> > > the >> > > > > >>> MNP, there is >> > > > > >>> no much difference between the operation of the MN and that >> > > > > of >> > > the >> > > MR. >> > > > > >>> Furthermore, >> > > > > >>> the MR can request the MNP during the establishment of IPSec >> > > > > SA >> > > when >> > > > > >>> it is at either home link or foreign link. >> > > > > >> >> > > > > >> Frank=>For adressing in NEMO, there are two categories >> > > > > >> nodes for addressing, that is, MRs and hosts behind MRs. >> > > > > >> >> > > > > >> IKE can be used for MR's addressing, while it probabaly >> > > > > >> can't be used for host addressing (PD) without extension of >> > > > > IKE. >> > > > > > >> > > > > > Fan> We can simply define a new attribute carried in the >> > > > > > CFG_REQUEST/CFG_REPLY >> > > > > > configuration payload during the IKE_AUTH exchange. >> > > > > >> > > > > Frank=>It couples PD with IKE procedure. How does the >> > > > > MR renew/release/renumber the prefixes after IKE_AUTH exchange? >> > > > > Anyway, IKE is not solely for MIP, IMHO, it is not proper to >> > > > > extend for this purpose. >> > > > > >> > > > > IMO, the compromised way is to use BA/BU which >> > > > > is in line with PMIP thoughtway. >> > > > > >> > > > > >> > > > > > >> > > > > > >> > > > > >> >> > > > > >>> >> > > > > >>>> because prefix management is an integrated part >> > > > > >>>> of NEMO. >> > > > > >>>> PMIPv6 follow the same philosophy. >> > > > > >>> >> > > > > >>> If I understand correctly, PMIP is a slightly different case >> > > > > > >> > from >> > > > > >>> DSMIPv6/NEMO. >> > > > > >>> Because the connection, such as the IPSec SA, between the >> > > > > MAG > >> > and >> > > the >> > > > > >>> LMA >> > > > > >>> is already in place long before the MN attaches to the MAG, >> > > > > it >> > > makes >> > > > > >>> sense >> > > > > >>> for >> > > > > >>> the MAG to request the HNP for the MN during the PBU/PBA > > >> exchange. >> > > With >> > > > > >>> DSMIPv6, the MN requests the HoA/HNP during the >> > > > > establishment >> of >> > > the >> > > > > >>> IPSec >> > > > > >>> SA, therefore the MR should request the MNP during this > > >> procedure >> > > as >> > > > > >>> well. >> > > > > >> >> > > > > >> Frank=>It is true there is difference between PMIP and NEMO. >> > > > > >> I just do an analogy. What I want to say is it makes sense >> > > > > if >> > > we >> > > > > >> integrate >> > > > > >> PD >> > > > > >> into NEMO. >> > > > > > >> > > > > > Fan> OK. >> > > > > > >> > > > > > Sincerely, >> > > > > > fan >> > > > > > >> > > > > >> >> > > > > >>> >> > > > > >>> What do you think? >> > > > > >>> >> > > > > >>> Sincerely, >> > > > > >>> fan >> > > > > >>> >> > > > > >>>> >> > > > > >>>> BR >> > > > > >>>> Frank >> > > > > >>>> >> > > > > >>>> ----- Original Message ----- From: "fan zhao" >> > > >> > > > > >>>> To: "Ryuji Wakikawa" >> > > > > >>>> Cc: "Julien Laganier" ; > > >> >> > > > > >>>> Sent: Friday, June 06, 2008 12:18 PM >> > > > > >>>> Subject: Re: [MEXT] Adoption of >> > > draft-droms-mext-nemo-pd-00.txt? >> > > > > >>>> >> > > > > >>>> >> > > > > >>>>> Hi Ryuji and et al, >> > > > > >>>>> >> > > > > >>>>> Sorry for jumping in. >> > > > > >>>>> I agree with Ryuji that the DHCP based PD procedure >> introduces >> > > > > >>>>> redundancy. >> > > > > >>>>> IMHO, the MR can request a MNP together with a HNP/HoA >> > > > > when >> > > > > >>>>> establishing >> > > > > >>>>> the IPSec SA with the HA. IMO, this is simpler. Do I miss >> > > something? >> > > > > >>>>> Thanks. >> > > > > >>>>> >> > > > > >>>>> Sincerely, >> > > > > >>>>> fan >> > > > > >>>>> >> > > > > >>>>> >> > > > > >>>>> On Wed, Jun 4, 2008 at 5:37 PM, Ryuji Wakikawa >> > > > > >>>>> >> > > > > >>>>> wrote: >> > > > > >>>>>> >> > > > > >>>>>> Hello Pascal, >> > > > > >>>>>> >> > > > > >>>>>> Sorry for late response. We have interop event in Tokyo >> > > > > and >> > > tested >> > > > > >>>>>> HAHA there;-) >> > > > > >>>>>> >> > > > > >>>>>> On 2008/06/03, at 17:08, Pascal Thubert (pthubert) wrote: >> > > > > >>>>>> >> > > > > >>>>>>> Hi Ryuji: >> > > > > >>>>>>> >> > > > > >>>>>>> I agree that PD should not impact bootstrap. These are >> > > > > and >> > > should be >> > > > > >>>>>>> kept unrelated. >> > > > > >>>>>>> >> > > > > >>>>>>> We must be able to extend a RFC 3963 MR with PD without >> > > > > > > >> forcing >> > > the >> > > > > >>>>>>> bootstrap process in the picture. So I agree not to >> > > > > bring > >> > DHAAD >> > > back >> > > > > >>>>>>> into the bootstrap... >> > > > > >>>>>> >> > > > > >>>>>> we agree then.. >> > > > > >>>>>> >> > > > > >>>>>>> But I think that PD is NOT a bootstrap process. It is >> > > > > post >> > > bootstrap >> > > > > >>>>>>> and >> > > > > >>>>>>> can reoccur many times in the life of the MR. >> > > > > >>>>>>> >> > > > > >>>>>>> Until we define a new process and rev 3775 and 3963, we >> > > > > > > >> should >> > > stay >> > > > > >>>>>>> consistent and simple in what we are doing. >> > > > > >>>>>> >> > > > > >>>>>> DHCP-PD can surely impact to the bootstrap process. >> > > > > >>>>>> >> > > > > >>>>>> Let's say MR boots up as a MN with RFC5026 first. >> > > > > >>>>>> Then, it tries to get a MNP for NEMO. >> > > > > >>>>>> >> > > > > >>>>>> If the current HA is not PD-enabled and DHAAD returns > > >> different >> > > HA, >> > > > > >>>>>> MR must de-register the binding from the current HA and >> tries > > to >> > > > > >>>>>> start >> > > > > >>>>>> all the registration process to the new HA. >> > > > > >>>>>> >> > > > > >>>>>> This seems very redundant operation.. >> > > > > >>>>>> I want to make the PD spec simple. >> > > > > >>>>>> >> > > > > >>>>>> regards >> > > > > >>>>>> ryuji >> > > > > >>>>>> >> > > > > >>>>>> >> > > > > >>>>>> >> > > > > >>>>>>> >> > > > > >>>>>>> >> > > > > >>>>>>> Pascal >> > > > > >>>>>>> >> > > > > >>>>>>>> -----Original Message----- >> > > > > >>>>>>>> From: mext-bounces@ietf.org >> > > > > [mailto:mext-bounces@ietf.org] >> > > On >> > > > > >>>>>>>> Behalf Of >> > > > > >>>>>>> >> > > > > >>>>>>> Ryuji Wakikawa >> > > > > >>>>>>>> >> > > > > >>>>>>>> Sent: mardi 3 juin 2008 09:54 >> > > > > >>>>>>>> To: marcelo bagnulo braun >> > > > > >>>>>>>> Cc: Julien Laganier; mext@ietf.org >> > > > > >>>>>>>> Subject: Re: [MEXT] Adoption of >> > > draft-droms-mext-nemo-pd-00.txt? >> > > > > >>>>>>>> >> > > > > >>>>>>>> Hi Marcelo, >> > > > > >>>>>>>> >> > > > > >>>>>>>> I agree to accept this as WG doc. >> > > > > >>>>>>>> >> > > > > >>>>>>>> I also agree with Romain and Vijay. >> > > > > >>>>>>>> We don't need extension to DHAAD. >> > > > > >>>>>>>> Since MR can act as MN, MR should be able to bootstrap >> with >> > > the >> > > > > >>>>>>>> same >> > > > > >>>>>>>> mechanism of MIP (except for PD). >> > > > > >>>>>>>> We should not bring DHAAD back in the bootstrap process >> > > > > > >> > only >> > > for >> > > > > >>>>>>>> PD. >> > > > > >>>>>>>> >> > > > > >>>>>>>> regards, >> > > > > >>>>>>>> ryuji >> > > > > >>>>>>>> >> > > > > >>>>>>>> >> > > > > >>>>>>>> On 2008/05/30, at 23:51, marcelo bagnulo braun wrote: >> > > > > >>>>>>>> >> > > > > >>>>>>>>> Hi, >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> We would like to ask the WG what is their opinion >> > > > > about >> > > accepting >> > > > > >>>>>>>>> draft-droms-mext-nemo-pd-00.txt as the WG document for >> the >> > > Nemo PD >> > > > > >>>>>>>>> deliverable included in our charter. >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> Please provide comments so we cna make some progress >> > > > > on > >> > this >> > > long >> > > > > >>>>>>>>> overdue deliverable >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> thanks, Julien and marcelo >> > > > > >>>>>>>>> -------- Mensaje original -------- >> > > > > >>>>>>>>> Asunto: I-D >> > > Action:draft-droms-mext-nemo-pd-00.txt >> > > > > >>>>>>>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >> > > > > >>>>>>>>> De: Internet-Drafts@ietf.org >> > > > > >>>>>>>>> Responder a: internet-drafts@ietf.org >> > > > > >>>>>>>>> Para: i-d-announce@ietf.org >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> A New Internet-Draft is available from the on-line >> > > Internet-Drafts >> > > > > >>>>>>>>> directories. >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> Title : DHCPv6 Prefix Delegation for NEMO >> > > > > >>>>>>>>> Author(s) : R. Droms, et al. >> > > > > >>>>>>>>> Filename : draft-droms-mext-nemo-pd-00.txt >> > > > > >>>>>>>>> Pages : 12 >> > > > > >>>>>>>>> Date : 2008-05-30 >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> One aspect of network mobility support is the >> > > > > assignment >> > > of a >> > > > > >>>>>>>>> prefix >> > > > > >>>>>>>>> or prefixes to a Mobile Router (MR) for use on the >> > > > > links >> > > in >> > > the >> > > > > >>>>>>>>> Mobile Network. DHCPv6 prefix delegation can be used >> > > > > for >> > > this >> > > > > >>>>>>>>> configuration task. >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> A URL for this Internet-Draft is: >> > > > > >>>>>>>>> >> > > >> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> Internet-Drafts are also available by anonymous FTP >> > > > > at: >> > > > > >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> Below is the data which will enable a MIME compliant >> > > > > mail >> > > reader >> > > > > >>>>>>>>> implementation to automatically retrieve the ASCII >> version > > of >> > > the >> > > > > >>>>>>>>> Internet-Draft. >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> Content-Type: text/plain >> > > > > >>>>>>>>> Content-ID: <2008-05-30054232.I-D@ietf.org> >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> >> > > _______________________________________________ >> > > > > >>>>>>>>> I-D-Announce mailing list >> > > > > >>>>>>>>> I-D-Announce@ietf.org >> > > > > >>>>>>>>> >> > > https://www.ietf.org/mailman/listinfo/i-d-announce >> > > > > >>>>>>>>> Internet-Draft directories: > > >> http://www.ietf.org/shadow.html >> > > > > >>>>>>>>> or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> >> > > _______________________________________________ >> > > > > >>>>>>>>> MEXT mailing list >> > > > > >>>>>>>>> MEXT@ietf.org >> > > > > >>>>>>>>> >> https://www.ietf.org/mailman/listinfo/mext >> > > > > >>>>>>>> >> > > > > >>>>>>>> >> > > _______________________________________________ >> > > > > >>>>>>>> MEXT mailing list >> > > > > >>>>>>>> MEXT@ietf.org >> > > > > >>>>>>>> >> https://www.ietf.org/mailman/listinfo/mext >> > > > > >>>>>> >> > > > > >>>>>> >> _______________________________________________ >> > > > > >>>>>> MEXT mailing list >> > > > > >>>>>> MEXT@ietf.org >> > > > > >>>>>> https://www.ietf.org/mailman/listinfo/mext >> > > > > >>>>>> >> > > > > >>>>> >> _______________________________________________ >> > > > > >>>>> MEXT mailing list >> > > > > >>>>> MEXT@ietf.org >> > > > > >>>>> https://www.ietf.org/mailman/listinfo/mext >> > > > > >>>>> >> > > > > >>>> >> > > > > >>>> >> > > > > >>>> >> > > > > >>> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > > >> > > > > >> > > > > >> > > > > _______________________________________________ >> > > > > MEXT mailing list >> > > > > MEXT@ietf.org >> > > > > https://www.ietf.org/mailman/listinfo/mext >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > > >> > > >> > >> > >> >> >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From c.sarrailh@sdepa.com.fr Wed Jun 11 08:56:42 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117103A68E3; Wed, 11 Jun 2008 08:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -46.274 X-Spam-Level: X-Spam-Status: No, score=-46.274 tagged_above=-999 required=5 tests=[BAYES_80=2, FB_REPLICA_ROLEX=3.157, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_GENREP=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAQDotqmMovH; Wed, 11 Jun 2008 08:56:37 -0700 (PDT) Received: from 190-76-115-64.dyn.movilnet.com.ve (190-76-115-64.dyn.movilnet.com.ve [190.76.115.64]) by core3.amsl.com (Postfix) with SMTP id 24DEC3A68D2; Wed, 11 Jun 2008 08:55:55 -0700 (PDT) X-Originating-IP: 54.104.104.184 by smtp.190.76.115.64; Wed, 11 Jun 2008 11:56:16 -0500 Message-ID: From: "Yvonne Mckinley" Reply-To: "Yvonne Mckinley" To: nemo-archive@ietf.org Subject: Replica watches make great gifts Date: Wed, 11 Jun 2008 11:56:16 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit When it comes down to getting a replica Rolex watch, there is just one place that offers its visitors and customers the highest quality available: Prestige Replicas. This unparalleled online store specializes in top of the line replica watches with unsurpassed performance, and bearing every marking that the genuine timepieces have. Every replica watch that Prestige Replicas carries, is made of solid stainless steel and features a sapphire crystal glass. What's more, every Rolex in store displays the green Rolex sticker with model number and logo on it. Just because you're buying a replica, don't settle for a low quality product. There are only a handful of online stores that offer the highest quality Rolex replica watches and Prestige Replicas is among them, and with the lowest available prices! http://nawagofozag35.blogspot.com/ From netlmm-bounces@ietf.org Wed Jun 11 08:56:43 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D3713A6910 for ; Wed, 11 Jun 2008 08:56:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to netlmm awaits moderator approval From: netlmm-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Wed, 11 Jun 2008 08:56:42 -0700 Precedence: bulk X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETLMM working group discussion list X-List-Administrivia: yes Sender: netlmm-bounces@ietf.org Errors-To: netlmm-bounces@ietf.org Your mail to 'netlmm' with the subject Replica watches make great gifts Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netlmm/dac9d49aec7526ffd5d70e885fb24b1179b77f11 From netconf-bounces@ietf.org Wed Jun 11 08:56:43 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36CA13A6910 for ; Wed, 11 Jun 2008 08:56:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to Netconf awaits moderator approval From: netconf-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Wed, 11 Jun 2008 08:56:42 -0700 Precedence: bulk X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 List-Id: Network Configuration WG mailing list X-List-Administrivia: yes Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Your mail to 'Netconf' with the subject Replica watches make great gifts Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netconf/480993ced1af4a953067bb82bed5397bb13f0be7 From nfsv4-bounces@ietf.org Wed Jun 11 08:56:43 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 405E23A6910 for ; Wed, 11 Jun 2008 08:56:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nfsv4 awaits moderator approval From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Wed, 11 Jun 2008 08:56:42 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org Your mail to 'nfsv4' with the subject Replica watches make great gifts Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nfsv4/edefbfdae7841ce20d72a6a5109b74efe055c40c From ngo-bounces@ietf.org Wed Jun 11 08:56:43 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 481783A6910 for ; Wed, 11 Jun 2008 08:56:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NGO awaits moderator approval From: ngo-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Wed, 11 Jun 2008 08:56:42 -0700 Precedence: bulk X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF X-List-Administrivia: yes Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Your mail to 'NGO' with the subject Replica watches make great gifts Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ngo/1a2100dad1825d1ec3d332ad0787b087e702877a From nsis-imp-bounces@ietf.org Wed Jun 11 08:56:43 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5108B3A6910 for ; Wed, 11 Jun 2008 08:56:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NSIS-imp awaits moderator approval From: nsis-imp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Wed, 11 Jun 2008 08:56:42 -0700 Precedence: bulk X-BeenThere: nsis-imp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for implementation questions for NSIS protocols X-List-Administrivia: yes Sender: nsis-imp-bounces@ietf.org Errors-To: nsis-imp-bounces@ietf.org Your mail to 'NSIS-imp' with the subject Replica watches make great gifts Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis-imp/52929c80c1b0fdee78e0d1b9d91308943847396c From nsis-bounces@ietf.org Wed Jun 11 08:56:43 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BFFB3A6910 for ; Wed, 11 Jun 2008 08:56:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nsis awaits moderator approval From: nsis-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Wed, 11 Jun 2008 08:56:43 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Your mail to 'nsis' with the subject Replica watches make great gifts Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis/58ebfe940184443091c1dbcf216ae260b3469b39 From ntdp-bounces@ietf.org Wed Jun 11 08:56:43 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AE4B3A6919 for ; Wed, 11 Jun 2008 08:56:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NTDP awaits moderator approval From: ntdp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Wed, 11 Jun 2008 08:56:43 -0700 Precedence: bulk X-BeenThere: ntdp@ietf.org X-Mailman-Version: 2.1.9 List-Id: define standards for the purpose of scripting of network testing equipment X-List-Administrivia: yes Sender: ntdp-bounces@ietf.org Errors-To: ntdp-bounces@ietf.org Your mail to 'NTDP' with the subject Replica watches make great gifts Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ntdp/44336b75ab2a18c0f615f2b1ecc000669c45aaf9 From nemo-bounces@ietf.org Wed Jun 11 08:56:43 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B242D3A6936 for ; Wed, 11 Jun 2008 08:56:43 -0700 (PDT) Subject: The results of your email commands From: nemo-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1013830314==" Message-ID: Date: Wed, 11 Jun 2008 08:56:43 -0700 Precedence: bulk X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NEMO Working Group X-List-Administrivia: yes Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --===============1013830314== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://nawagofozag35.blogspot.com/ - Done. --===============1013830314== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nemo-request@core3.amsl.com Delivered-To: nemo-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117103A68E3; Wed, 11 Jun 2008 08:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -46.274 X-Spam-Level: X-Spam-Status: No, score=-46.274 tagged_above=-999 required=5 tests=[BAYES_80=2, FB_REPLICA_ROLEX=3.157, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_GENREP=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAQDotqmMovH; Wed, 11 Jun 2008 08:56:37 -0700 (PDT) Received: from 190-76-115-64.dyn.movilnet.com.ve (190-76-115-64.dyn.movilnet.com.ve [190.76.115.64]) by core3.amsl.com (Postfix) with SMTP id 24DEC3A68D2; Wed, 11 Jun 2008 08:55:55 -0700 (PDT) X-Originating-IP: 54.104.104.184 by smtp.190.76.115.64; Wed, 11 Jun 2008 11:56:16 -0500 Message-ID: From: "Yvonne Mckinley" Reply-To: "Yvonne Mckinley" To: nemo-archive@ietf.org Subject: Replica watches make great gifts Date: Wed, 11 Jun 2008 11:56:16 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit When it comes down to getting a replica Rolex watch, there is just one place that offers its visitors and customers the highest quality available: Prestige Replicas. This unparalleled online store specializes in top of the line replica watches with unsurpassed performance, and bearing every marking that the genuine timepieces have. Every replica watch that Prestige Replicas carries, is made of solid stainless steel and features a sapphire crystal glass. What's more, every Rolex in store displays the green Rolex sticker with model number and logo on it. Just because you're buying a replica, don't settle for a low quality product. There are only a handful of online stores that offer the highest quality Rolex replica watches and Prestige Replicas is among them, and with the lowest available prices! http://nawagofozag35.blogspot.com/ --===============1013830314==-- From nsis-bounces@ietf.org Wed Jun 11 08:56:43 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71013A6950 for ; Wed, 11 Jun 2008 08:56:43 -0700 (PDT) Subject: The results of your email commands From: nsis-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0297087542==" Message-ID: Date: Wed, 11 Jun 2008 08:56:43 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============0297087542== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://nawagofozag35.blogspot.com/ - Done. --===============0297087542== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nsis-request@core3.amsl.com Delivered-To: nsis-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117103A68E3; Wed, 11 Jun 2008 08:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -46.274 X-Spam-Level: X-Spam-Status: No, score=-46.274 tagged_above=-999 required=5 tests=[BAYES_80=2, FB_REPLICA_ROLEX=3.157, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_GENREP=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAQDotqmMovH; Wed, 11 Jun 2008 08:56:37 -0700 (PDT) Received: from 190-76-115-64.dyn.movilnet.com.ve (190-76-115-64.dyn.movilnet.com.ve [190.76.115.64]) by core3.amsl.com (Postfix) with SMTP id 24DEC3A68D2; Wed, 11 Jun 2008 08:55:55 -0700 (PDT) X-Originating-IP: 54.104.104.184 by smtp.190.76.115.64; Wed, 11 Jun 2008 11:56:16 -0500 Message-ID: From: "Yvonne Mckinley" Reply-To: "Yvonne Mckinley" To: nemo-archive@ietf.org Subject: Replica watches make great gifts Date: Wed, 11 Jun 2008 11:56:16 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit When it comes down to getting a replica Rolex watch, there is just one place that offers its visitors and customers the highest quality available: Prestige Replicas. This unparalleled online store specializes in top of the line replica watches with unsurpassed performance, and bearing every marking that the genuine timepieces have. Every replica watch that Prestige Replicas carries, is made of solid stainless steel and features a sapphire crystal glass. What's more, every Rolex in store displays the green Rolex sticker with model number and logo on it. Just because you're buying a replica, don't settle for a low quality product. There are only a handful of online stores that offer the highest quality Rolex replica watches and Prestige Replicas is among them, and with the lowest available prices! http://nawagofozag35.blogspot.com/ --===============0297087542==-- From nfsv4-bounces@ietf.org Wed Jun 11 08:56:43 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE8E13A6936 for ; Wed, 11 Jun 2008 08:56:43 -0700 (PDT) Subject: The results of your email commands From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0411801476==" Message-ID: Date: Wed, 11 Jun 2008 08:56:43 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org --===============0411801476== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://nawagofozag35.blogspot.com/ - Done. --===============0411801476== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nfsv4-request@core3.amsl.com Delivered-To: nfsv4-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117103A68E3; Wed, 11 Jun 2008 08:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -46.274 X-Spam-Level: X-Spam-Status: No, score=-46.274 tagged_above=-999 required=5 tests=[BAYES_80=2, FB_REPLICA_ROLEX=3.157, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_GENREP=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAQDotqmMovH; Wed, 11 Jun 2008 08:56:37 -0700 (PDT) Received: from 190-76-115-64.dyn.movilnet.com.ve (190-76-115-64.dyn.movilnet.com.ve [190.76.115.64]) by core3.amsl.com (Postfix) with SMTP id 24DEC3A68D2; Wed, 11 Jun 2008 08:55:55 -0700 (PDT) X-Originating-IP: 54.104.104.184 by smtp.190.76.115.64; Wed, 11 Jun 2008 11:56:16 -0500 Message-ID: From: "Yvonne Mckinley" Reply-To: "Yvonne Mckinley" To: nemo-archive@ietf.org Subject: Replica watches make great gifts Date: Wed, 11 Jun 2008 11:56:16 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit When it comes down to getting a replica Rolex watch, there is just one place that offers its visitors and customers the highest quality available: Prestige Replicas. This unparalleled online store specializes in top of the line replica watches with unsurpassed performance, and bearing every marking that the genuine timepieces have. Every replica watch that Prestige Replicas carries, is made of solid stainless steel and features a sapphire crystal glass. What's more, every Rolex in store displays the green Rolex sticker with model number and logo on it. Just because you're buying a replica, don't settle for a low quality product. There are only a handful of online stores that offer the highest quality Rolex replica watches and Prestige Replicas is among them, and with the lowest available prices! http://nawagofozag35.blogspot.com/ --===============0411801476==-- From mext-bounces@ietf.org Wed Jun 11 09:52:34 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C15453A6824; Wed, 11 Jun 2008 09:52:34 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C70A3A6824 for ; Wed, 11 Jun 2008 09:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJyAWbGaRg9D for ; Wed, 11 Jun 2008 09:52:32 -0700 (PDT) Received: from web84311.mail.re1.yahoo.com (web84311.mail.re1.yahoo.com [69.147.74.190]) by core3.amsl.com (Postfix) with SMTP id 125C73A6781 for ; Wed, 11 Jun 2008 09:52:31 -0700 (PDT) Received: (qmail 28178 invoked by uid 60001); 11 Jun 2008 16:52:57 -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=kNp8+YeOlB94KEKFRCLY5udBpZpw/3sZQvJgyyd1c5V3YvHov3lx1kLe0g9qHQV851yraHHK9/68J++ISHah5UzOyEXjV02vETJhv39a9KuMdz7pbQFgODwpulNdD+w1mB5coSJRIQuhzPWLL0rW2SUsBaiGQSdBk4nLX2j7IUY=; X-YMail-OSG: fNaMeq8VM1njAy5r26FO9ll37b_wXB3.6u05QqKS9wOXqwKOH4tLrM_t005Q5bJvHGIhXHa8UGifYPY3B159L4nfyukY7FqTLxpnHGTDfz1p2EV1EAAV2vKLQ_w- Received: from [206.16.17.212] by web84311.mail.re1.yahoo.com via HTTP; Wed, 11 Jun 2008 09:52:57 PDT X-Mailer: YahooMailRC/975.41 YahooMailWebService/0.7.185 Date: Wed, 11 Jun 2008 09:52:57 -0700 (PDT) From: Behcet Sarikaya To: Jean-Michel Combes MIME-Version: 1.0 Message-ID: <469774.27815.qm@web84311.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 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="===============1472446787==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1472446787== Content-Type: multipart/alternative; boundary="0-1099505279-1213203177=:27815" --0-1099505279-1213203177=:27815 Content-Type: text/plain; charset=us-ascii Jean-Michel, Regarding the certificates for the delegated prefixes, there is an individual draft in DHC WG. This draft proposes to add certificate option to DHCPv6 PD. Once this draft goes through, the certificates will become part of DHCPv6 PD. At this moment, we don't know. So I think it is early to talk about this issue. Regards, Behcet ----- Original Message ---- From: Jean-Michel Combes To: Frank Xia Cc: Julien Laganier ; mext@ietf.org Sent: Wednesday, June 11, 2008 10:27:23 AM Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Hi Frank, At first I assume this is the HA that delegates the MNPs. 2008/6/9, Frank Xia : > Hi JMC > > Firstly, the certificate issuing party is not supposed to be HA, so > the certificate does not mandatorily get from the HA. Agree. The HA has just to provide the cert. > Or, how does the HA get the certificate of the MR? HA may be the Certificate Authority or a Registration Authority. > > Secondly, if the prefix information can't be sychronized between > the certificate issuing party and the HA, the prefix should not > included in the certificate. AFAIK, the HA is always aware of the delegated MNPs: in explicit mode with the Prefix Table and in implicit mode where it is assumed the HA knows the MNPs in using a specific mechanism > > There are same concerns with PMIPv6 when you insist that > the certificate should be delegated from the HA. IMHO, this is the simplest solution when we assume this is the HA/LMA that delegates the prefixes. Best regards. > > There is no perfect solution but compromised solution. > > BR > Frank > > ----- Original Message ----- From: "Jean-Michel Combes" > > To: "Frank Xia" > Cc: "fan zhao" ; ; "Julien Laganier" > > Sent: Monday, June 09, 2008 11:05 AM > > Subject: Re: [MEXT] Adoption of > draft-droms-mext-nemo-pd-00.txt? > > > > > Hi Frank, > > > > If SEND is deployed in the NEMO network (i.e. MR's ingress interface), > > at the same time the HA has to provide the MNPs, it has to provide the > > Router Authorization Certificate linked to the MNPs. > > > > There is no relationship between IKE and SEND, by the way. > > > > Best regards. > > > > JMC. > > > > 2008/6/9, Frank Xia : > > > > > Hi Jean-Michel > > > > > > Even in SEND, IMHO, it is not necessary for HA to > > > provide Router Authorization Certificate because > > > HA and MR have authenticated each other using > > > IKE, etc. > > > > > > Anyway, this scenario is not clear. > > > > > > BR > > > Frank > > > > > > ----- Original Message ----- From: "Jean-Michel Combes" > > > > > > To: "Frank Xia" > > > Cc: "fan zhao" ; ; "Julien > Laganier" > > > > > > Sent: Friday, June 06, 2008 6:30 PM > > > > > > Subject: Re: [MEXT] Adoption of > > > draft-droms-mext-nemo-pd-00.txt? > > > > > > > > > > > > > Hi, > > > > > > > > Don't forget that people may want to deploy SEND and so you will have > > > > to provide Router Authorization Certificate too in that case. > > > > AFAIK, for the moment, there is no proposal to provide such > > > > certificates with PBU/PBA and so you will have another mechanism. The > > > > consequence is that you will loose the advantage in time you gained in > > > > piggybacking the delegated prefixes in the PBU/PBA ... > > > > > > > > This is not the case with PMIP because the LMA is aware of the > > > > prefixes assigned to the MAGs and during the set up of > > > > > > > > 2008/6/7, Frank Xia : > > > > > > > > > Hi Fan > > > > > > > > > > Please check my reply... > > > > > > > > > > > > > > > BR > > > > > Frank > > > > > snipped the rest of this huge mail. --0-1099505279-1213203177=:27815 Content-Type: text/html; charset=us-ascii
Jean-Michel,
  Regarding the certificates for the delegated prefixes, there is an individual draft in DHC WG. This draft proposes to add certificate option to DHCPv6 PD.
  Once this draft goes through, the certificates will become part of DHCPv6 PD.
  At this moment, we don't know. So I think it is early to talk about this issue.

Regards,

Behcet

----- Original Message ----
From: Jean-Michel Combes <jeanmichel.combes@gmail.com>
To: Frank Xia <xiayangsong@huawei.com>
Cc: Julien Laganier <julien.IETF@laposte.net>; mext@ietf.org
Sent: Wednesday, June 11, 2008 10:27:23 AM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

Hi Frank,

At first I assume this is the HA that delegates the MNPs.

2008/6/9, Frank Xia <xiayangsong@huawei.com>:
> Hi JMC
>
>  Firstly, the certificate issuing party is not supposed to be HA, so
>  the certificate does not mandatorily get from the HA.

Agree. The HA has just to provide the cert.

>  Or, how does the HA get  the certificate of the MR?

HA may be the Certificate Authority or a Registration Authority.

>
>  Secondly, if the prefix information can't be sychronized between
>  the certificate issuing party and the HA, the prefix should not
>  included in the certificate.

AFAIK, the HA is always aware of the delegated MNPs: in explicit mode
with the Prefix Table and in implicit mode where it is assumed the HA
knows the MNPs in using a specific mechanism

>
>  There are same concerns with PMIPv6 when  you insist that
>  the certificate should be delegated from the HA.

IMHO, this is the simplest solution when we assume this is the HA/LMA
that delegates the prefixes.

Best regards.

>
>  There is no perfect solution but compromised solution.
>
>  BR
>  Frank
>
>  ----- Original Message ----- From: "Jean-Michel Combes"
> <jeanmichel.combes@gmail.com>
>  To: "Frank Xia" <xiayangsong@huawei.com>
>  Cc: "fan zhao" <fanzhao828@gmail.com>; <mext@ietf.org>; "Julien Laganier"
> <julien.IETF@laposte.net>
>  Sent: Monday, June 09, 2008 11:05 AM
>
>  Subject: Re: [MEXT] Adoption of
> draft-droms-mext-nemo-pd-00.txt?
>
>
>
> > Hi Frank,
> >
> > If SEND is deployed in the NEMO network (i.e. MR's ingress interface),
> > at the same time the HA has to provide the MNPs, it has to provide the
> > Router Authorization Certificate linked to the MNPs.
> >
> > There is no relationship between IKE and SEND, by the way.
> >
> > Best regards.
> >
> > JMC.
> >
> > 2008/6/9, Frank Xia <xiayangsong@huawei.com>:
> >
> > > Hi Jean-Michel
> > >
> > >  Even in SEND,  IMHO, it is not necessary for HA to
> > >  provide Router Authorization Certificate because
> > >  HA and MR have authenticated each other using
> > >  IKE, etc.
> > >
> > >  Anyway, this scenario is not clear.
> > >
> > >  BR
> > >  Frank
> > >
> > >  ----- Original Message ----- From: "Jean-Michel Combes"
> > > <jeanmichel.combes@gmail.com>
> > >  To: "Frank Xia" <xiayangsong@huawei.com>
> > >  Cc: "fan zhao" <fanzhao828@gmail.com>; <mext@ietf.org>; "Julien
> Laganier"
> > > <julien.IETF@laposte.net>
> > >  Sent: Friday, June 06, 2008 6:30 PM
> > >
> > >  Subject: Re: [MEXT] Adoption of
> > > draft-droms-mext-nemo-pd-00.txt?
> > >
> > >
> > >
> > > > Hi,
> > > >
> > > > Don't forget that people may want to deploy SEND and so you will have
> > > > to provide Router Authorization Certificate too in that case.
> > > > AFAIK, for the moment, there is no proposal to provide such
> > > > certificates with PBU/PBA and so you will have another mechanism. The
> > > > consequence is that you will loose the advantage in time you gained in
> > > > piggybacking the delegated prefixes in the PBU/PBA ...
> > > >
> > > > This is not the case with PMIP because the LMA is aware of the
> > > > prefixes assigned to the MAGs and during the set up of
> > > >
> > > > 2008/6/7, Frank Xia <xiayangsong@huawei.com>:
> > > >
> > > > > Hi Fan
> > > > >
> > > > >  Please check my reply...
> > > > >
> > > > >
> > > > >  BR
> > > > >  Frank
> > > > >
snipped the rest of this huge mail.


--0-1099505279-1213203177=:27815-- --===============1472446787== 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://www.ietf.org/mailman/listinfo/mext --===============1472446787==-- From c.sampson@erskineanderskine.com Fri Jun 13 01:46:50 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2163A67B6; Fri, 13 Jun 2008 01:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -77.105 X-Spam-Level: X-Spam-Status: No, score=-77.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44AXrbts8sbo; Fri, 13 Jun 2008 01:46:49 -0700 (PDT) Received: from ppp-58-9-171-23.revip2.asianet.co.th (ppp-58-9-171-23.revip2.asianet.co.th [58.9.171.23]) by core3.amsl.com (Postfix) with SMTP id 8F2F13A6B4C; Fri, 13 Jun 2008 01:46:31 -0700 (PDT) X-Originating-IP: 50.151.203.65 by smtp.58.9.171.23; Fri, 13 Jun 2008 04:47:00 -0500 Message-ID: From: "Harrison Waldron" Reply-To: "Harrison Waldron" To: multi6-archive@ietf.org Subject: Replica watches make great gifts Date: Fri, 13 Jun 2008 04:47:00 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Prestige Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://bynalabakiw82.blogspot.com/ As you are probably aware of, Prestige Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Prestige Replicas today! http://bynalabakiw82.blogspot.com/ From mext-bounces@ietf.org Fri Jun 13 02:59:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1382228C15D; Fri, 13 Jun 2008 02:59:51 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4C33A6B65 for ; Fri, 13 Jun 2008 02:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.074 X-Spam-Level: X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id No35fgTXoGcs for ; Fri, 13 Jun 2008 02:59:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9D2C23A6B64 for ; Fri, 13 Jun 2008 02:59:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,637,1204498800"; d="scan'208";a="11595589" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Jun 2008 12:00:17 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5DA0HQH021657; Fri, 13 Jun 2008 12:00:17 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5DA0H3S010538; Fri, 13 Jun 2008 10:00:17 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); Fri, 13 Jun 2008 12:00:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 Jun 2008 11:59:34 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05D16A6D@xmb-ams-337.emea.cisco.com> In-Reply-To: <947302.14203.qm@web84310.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Thread-Index: AcjLLthIeCaKsxTaR1m9nJqtcjuXMACC8ZKA References: <947302.14203.qm@web84310.mail.re1.yahoo.com> From: "Pascal Thubert (pthubert)" To: "Behcet Sarikaya" , "Vijay Devarapalli" X-OriginalArrivalTime: 13 Jun 2008 10:00:17.0564 (UTC) FILETIME=[4859DDC0:01C8CD3C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9005; t=1213351217; x=1214215217; 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]=20Adoption=20of=20draft-droms-me xt-nemo-pd-00.txt? |Sender:=20; bh=lgJFuPXxe1/tBWWAuOS3pY7tFvkMm0MSck4oECdAI54=; b=GY+OGtWh5YZfls7x8if5cOqyewy2nFwwZcxh9P7CRohC1vnhKGcEJ3cyD7 MzS61YN1mUveWcU6wpRj233nNXsfA94zzSX/mFHS1WTPRgvmbng08WzPH37a qi7Y9UjONV; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Behcet: I think we really have to serialize: at the moment the consensus is one and= only one draft, that is based on DHCP-PD. I would not play on words on wha= t that consensus means in a lawyer fashion. Honestly I think it's pretty cl= ear. = In this thread, Vijay is referring to the NEMO based solution, and I agree = with him that it would be the proper alternate. NEMO had reached a consensu= s of supporting both ways but having 2 solutions seemed to cause delay to t= he advancement of any solution. = Once the DHCP based solution is advanced enough, I hope we consider deploye= ments that require a different or simpler solution, and at that time, we mi= ght want to couple your work on the back end with http://tools.ietf.org/id/= draft-ietf-nemo-prefix-delegation-02.txt. That would make a lot of sense to= me. But for the time being, we need to answer the chairs about supporting a pro= posed draft for WG doc. Pascal ________________________________________ From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Beh= cet Sarikaya Sent: mardi 10 juin 2008 21:19 To: Vijay Devarapalli Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Hi Vijay, =A0 Pls. see inline. Regards, Behcet ----- Original Message ---- From: Vijay Devarapalli To: fan zhao ; Alexandru Petrescu Cc: Julien Laganier ; mext@ietf.org Sent: Tuesday, June 10, 2008 1:22:20 PM Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Hello Fan, *If* we are not going to be using DCHP for the mobile router to obtain mobile network prefix(es) from the home agent, I would prefer the BU/BAck exchange rather than modifying/extending IKEv2. = [behcet] You mean other than RFC 5026? The mobile router could just request for the mobile network prefix(es) in the BU and get the information in the BAck. = Vijay > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On = > Behalf Of fan zhao > Sent: Tuesday, June 10, 2008 2:48 AM > To: Alexandru Petrescu > Cc: mext@ietf.org; Julien Laganier > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > = > Hi Alex, > = > Thanks for your reply. Sorry I could not reply you earlier. > = > On Tue, Jun 10, 2008 at 2:05 AM, Alexandru Petrescu > wrote: > > Hi Fan and thank you for the other private email, I take = > advantage of this > > to reply publicly. > > > > fan zhao wrote: > >> > >> Hi Julien, Marcelo et al, > >> > >>> The question at this stage is whether we want to make the only > >>> proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft. > > > > WEll I agree in principle, provided authors are open to = > feedback from > > implementation and ready to modify it further. > > > >> IMHO, the DHCP-PD solution leads to additional signaling overhead; > >> furthermore, using the DHCP Authentication Option = > introduces another > >> layer of overhead/redundancy. Therefore, my oponion is = > DHCP-PD should > >> not be the only solution. > > > > Well DHCP-PD through the secured MR-HA tunnel wouldn't use = > DHCP auth option. > I agree. The secured MR-HA tunnel relies on the IPSec SA. The IPSec SA > is established > when the MR powers up. > During the IPSec SA establishment with the HA, the MR can request its > home address and the > MNP using the configuration payload. > = > > > >> RFC 5026 describes the procedure for the MN to dynamically = > obtain the > >>=A0 home address from the network using the IKEv2. As defined in RFC > >> 3753, a MN could be either a MR or MH. Therefore it is natural to > >> define extensions in the IKEv2 for the MR to request the MNP, which > >> is more efficient and secure. > > > > I'm not sure using IKEv2 to obtain MNP is more efficient = > than DHCP, at least > > because IKEv2 has much more roundtrips than DHCP, so it = > could be considered > > heavier (or less efficient). > = > Alex, the following is the comparison between the DHCP-PD and = > the IKE-PD. > = > DHCP-PD: > Assume that the MR is not at the home link, when the MR = > powers up using CMIP, > it follows the bootstrapping procedure as a MN: first, it obtains a > local IP address as CoA; > second, it obtains the IP address of the HA; third, it establishes the > IPSec SA with the HA, > during this procedure, the MR obtains a HoA; fourth, the MR compares > the HoA with > the previously configured IP address, i.e CoA and the MR determines > that it is not at home; > therefore it sends a BU to the HA to reg the binding between HoA and > CoA and receives a BA; fifth, > based on its configuration, the MR realizes it should act as a MR and > obtain a MNP. With the > DHCP based approach, the MR sends a DHCP solicit message to the HA and > the MR receives > a DHCP reply message. Now the PD is completed. > = > IKE-PD: > Assume that the MR is not at home link, ... first, it obtains a local > IP address as CoA; > second, it obtains the IP address of the HA; third, it establishes the > IPSec SA with the HA, > during this procedure, the MR obtains a HoA and a MNP based its > configuration; fourth, the MR compares the HoA with > the previously configured IP address, i.e CoA and the MR determines > that it is not at home; > therefore it sends a BU to the HA to register the binding between HoA > and MNP and CoA and receives a BA. > = > Note that we conclude before the home link detection is based on the > IKE. Therefore, the MN also > performs 1) to 4) when it is on its home link. So with the IKE-PD, the > MN does not need to send and > receive the DHCP messages. > = > It is also not as simple as saving two messages. > Consider this case: the MN needs to set up an additional IPSec child > SA to protect the data traffic. > This is done after the IPSec SA is performed. With the DHCP-PD, if the > MN performs the Child SA > establishment for the traffic from/to itself before the DHCP-PD, then > after DHCP-PD, the MN needs to > set up another child SA to protect the traffic to/from the MNNs. If > the MN performs the Child SA > establishment for the traffic from/to itself after the DHCP-PD, this > means the commnucation between > MN and CN is delayed. therefore, when the MN handovers from a PMIP > domain to a target access network > using CMIP. DHCP-PD would result in more delay. > With the IKE-PD, since the MN knows its HoA and MNP at the same time, > it can immediately set > up one Child SA to protect the traffic from/to itself and the MNNs. > = > Do I miss something? Thanks. > = > Sincerely, > fan > = > > > > Alex > > > >> > >> Thanks. > >> > >> Sincerely, fan > >> > >> > >> > >> > >> On Tue, Jun 10, 2008 at 12:11 AM, Julien Laganier > >> wrote: > >>> > >>> On Friday 06 June 2008, Frank Xia wrote: > >>>> > >>>> Hi Fan, Ryuji and other colleagues. > >>>> > >>>> Agreed. > >>>> > >>>> IMHO,There are two ways for prefix delegation in Nemo, that is, > >>>> overlay and integrated modes. > >>>> > >>>> DHCP based PD is a overlay solution which introduce = > redundancy while > >>>> trying to reduce impact on NEMO itself. > >>>> > >>>> I favor the integrated mode in which Prefix Delegation is > >>>> integrated into NEMO operations because prefix management is an > >>>> integrated part of NEMO.=A0 PMIPv6 follow the same philosophy. > >>> > >>> Hello Frank et. al. > >>> > >>> > >>> > >>> We are not going to challenge your technical arguments. We have a > >>> WG consensus on developing *one* solution based on *DHCPv6 PD*, so > >>> this is discussion is in our opinion out of scope since there are > >>> no reasons to revert the WG consensus. > >>> > >>> The question at this stage is whether we want to make the only > >>> proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft. > >>> > >>> Thanks in advance for your understanding. > >>> > >>> Regards, > >>> > >>> -- julien & marcelo, MEXT chairs > >>> > >>> > >> _______________________________________________ MEXT mailing list > >> MEXT@ietf.org https://www.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://www.ietf.org/mailman/listinfo/mext > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 13 03:33:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB2673A6984; Fri, 13 Jun 2008 03:33:51 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2240C3A6984 for ; Fri, 13 Jun 2008 03:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.245 X-Spam-Level: X-Spam-Status: No, score=-5.245 tagged_above=-999 required=5 tests=[AWL=1.354, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upcmZyPq2yIM for ; Fri, 13 Jun 2008 03:33:49 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 5641C3A6810 for ; Fri, 13 Jun 2008 03:33:49 -0700 (PDT) Received: from dummyhost17.it.uc3m.es (unknown [163.117.139.230])by smtp03.uc3m.es (Postfix) with ESMTP id 455713D85C4for ; Fri, 13 Jun 2008 12:34:19 +0200 (CEST) Message-ID: <48524D2B.3030304@it.uc3m.es> Date: Fri, 13 Jun 2008 12:34:19 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: mext X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-17.2530 TC:1F TRN:17 TV:5.5.1026(15968.006) 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) Subject: [MEXT] [Fwd: MEXT - Requested sessions have been scheduled for IETF 72] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org -------- Mensaje original -------- Asunto: MEXT - Requested sessions have been scheduled for IETF 72 Fecha: Thu, 12 Jun 2008 14:01:45 -0700 (PDT) De: IETF Secretariat Para: marcelo@it.uc3m.es CC: julien.ietf@laposte.net, jari.arkko@piuha.net, townsley@cisco.com, session-request@ietf.org Dear Marcelo Bagnulo, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the information of sessions that you have requested. MEXT Session 1 (2 hours) Monday, Afternoon Session II 1520-1720 Room Name: Convention 1 ---------------------------------------------- MEXT Session 2 (2 hours) Tuesday, Afternoon Session I 1300-1500 Room Name: Convention 2 ---------------------------------------------- _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 13 08:41:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCC843A67F5; Fri, 13 Jun 2008 08:41:49 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BC273A67A4 for ; Fri, 13 Jun 2008 08:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmbuJ0DvnpEE for ; Fri, 13 Jun 2008 08:41:46 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by core3.amsl.com (Postfix) with ESMTP id 12F0D3A67F5 for ; Fri, 13 Jun 2008 08:41:45 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id y36so103388ugd.46 for ; Fri, 13 Jun 2008 08:42:17 -0700 (PDT) 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=VV1YAv0XazysYsZykbiKUA/Dz4RqHX3RjOopStnpcqw=; b=aWYyy3EKugEln8mLPbAW5Y96mn2Iz3/T6MWMCftMXacj7Pn/PKHAVAwCRmuZQsqV18 WgLqvkTUyPtGlth8J2dAwS1XKm0J4tliibV2Pivgzf+TJI7MM92DyMhmKqFwbJusqOp8 95BC358tJQY2QQSnTSQu0GU36r8Y+/H6mWdzg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:sender; b=weEJSmVDfE77LIxLeQ/WjVKTocxM9rMLRoEkjlkPItLfneATxg3YUkJiBJ1s/7jFmv UocYzrG4+ElSGdedmKx3V6dWmCKNmX0Jk4g9eULZGP6KJZv6Ba69v5hg50sjJjqqCmmx c+DjSIGcxwRaseX+zTExvVPKKTEd/rAXdLAa8= Received: by 10.210.81.10 with SMTP id e10mr2681901ebb.44.1213371737021; Fri, 13 Jun 2008 08:42:17 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id i6sm4932323gve.4.2008.06.13.08.42.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Jun 2008 08:42:16 -0700 (PDT) From: Julien Laganier To: draft-droms-mext-nemo-pd@tools.ietf.org Date: Fri, 13 Jun 2008 17:42:14 +0200 User-Agent: KMail/1.9.9 References: <48401470.40706@it.uc3m.es> In-Reply-To: <48401470.40706@it.uc3m.es> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806131742.16099.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as a WG draft corresponding to the Nemo Prefix Delegation work item. Authors, please resubmit the draft as WG draft under the name: draft-ietf-mext-nemo-pd-00.txt Note: you can use the online I-D submission tool to make it faster: Thanks. --julien & marcelo, MEXT chairs. On Friday 30 May 2008, marcelo bagnulo braun wrote: > Hi, > > We would like to ask the WG what is their opinion about accepting > draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD > deliverable included in our charter. > > Please provide comments so we cna make some progress on this long > overdue deliverable > > thanks, Julien and marcelo > > -------- Mensaje original -------- > Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt > Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) > De: Internet-Drafts@ietf.org > Responder a: internet-drafts@ietf.org > Para: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : DHCPv6 Prefix Delegation for NEMO > Author(s) : R. Droms, et al. > Filename : draft-droms-mext-nemo-pd-00.txt > Pages : 12 > Date : 2008-05-30 > > One aspect of network mobility support is the assignment of a prefix > or prefixes to a Mobile Router (MR) for use on the links in the > Mobile Network. DHCPv6 prefix delegation can be used for this > configuration task. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Jun 15 05:29:22 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ACD228C0FE; Sun, 15 Jun 2008 05:29:22 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F16C528C0FE for ; Sun, 15 Jun 2008 05:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Asd0Orb+szT2 for ; Sun, 15 Jun 2008 05:29:19 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 5737C28C0FA for ; Sun, 15 Jun 2008 05:29:18 -0700 (PDT) Received: from [128.96.58.166] (vpntnlA166.research.telcordia.com [128.96.58.166]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id m5FCTupa016946; Sun, 15 Jun 2008 08:29:56 -0400 (EDT) Message-ID: <48550B35.1010703@research.telcordia.com> Date: Sun, 15 Jun 2008 08:29:41 -0400 From: Ashutosh Dutta User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4843B64E.8040307@it.uc3m.es> In-Reply-To: <4843B64E.8040307@it.uc3m.es> Cc: charliep@computer.org, Julien Laganier , mext@ietf.org Subject: Re: [MEXT] RFC3775 update - Simultaneous Mobility X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org marcelo bagnulo braun wrote: > Hi, > > In last IETF we said that we will accept input for RFC3775 changes for > about 3 months and then try to wrap up this issues. > > This is reminder of that plan and that proposals for changes for RFC3775 > are accepted till the 15 of june. > > After that we will go through the proposed changes and try to reach > consensus on each of the proposed changes (including the text to be > included and removed) in the ml. > > After that we will ask the authors of rfc3775 to submit a 3775bis > including the accepted changes and go to WGLC. > > Regards, Julien and marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext Hi Marcelo, I would like to request to consider looking into this issue as part of = the effort for the proposed changes to RFC 3775. Regards Ashutosh -------- Original Message -------- Subject: Re: [MEXT] simultaneous mobility Date: Sat, 29 Mar 2008 10:02:37 +0100 From: marcelo bagnulo To: Ashutosh Dutta CC: Dr. Daniel Wong , mext@ietf.org References: = <7db42a3e0803270046r5d034eb0sfc1568dbe77606f7@mail.gmail.com> = <47EB5C43.1040408@it.uc3m.es> <47ED5A13.4070609@research.telcordia.com> Hi Ashutosh, i would suggest you to suggest what text need to be changed in rfc3775 to solve this issue and send it to the list so people can comment regards, marcelo Ashutosh Dutta escribi=F3: > Marcelo, > As per your suggestion and brief discussion during IETF > meeting, I looked at RFC 3775. However, I have not seen anywhere about > the fall back option if the mobile is already operating in RO mode. > Section 11.8 in RFC 3775 discusses about the re-transmission of > Care-of Test Init messages and Binding Update that may go on > indefinitely. > > "The retransmissions by the mobile node MUST use an exponential back- > off process in which the timeout period is doubled upon each > retransmission, until either the node receives a response or the > timeout period reaches the value MAX_BINDACK_TIMEOUT. The mobile > node MAY continue to send these messages at this slower rate > indefinitely." > > > However, if the retransmission goes on for indefinitely due to > simultaneous mobility and there is no fall back option, it might > affect the real-time communication because of the delayed RO. Thus, we > will probably need to find some solution either by specifying it as > part of RFC 3775bis or some other solution. > > It would be good to have some discussion on how to take care of this > specific problem. > > Regards > Ashutosh > > marcelo bagnulo wrote: >>> b) it was suggested that it is not a problem when route optimization >>> signaling is lost, because it will then fall back to bidirectional >>> tunneling. However, once the communication session has been started >>> and route optimization is in use, there is no mechanism specified in >>> RFC 3775 to fall back to bidirectional tunneling (I'll let Ashutosh >>> comment more on this point). Perhaps the introduction of such a >>> fallback mechanism could be considered a candidate solution. >>> >> FWIW, imho this is how i would expect RFC3775 should behave, so imho >> this is simply something that was not fully specified in rfc3775. >> I would treat it as an update in rfc3775bis >> >> regards, marcelo >> >> >> >>> thanks >>> Daniel >>> >>> -- >>> Dr. Daniel Wong >>> Assistant Professor >>> Malaysia University of Science and Technology >>> ** check out my book on wireless IP at >>> http://www.must.edu.my/~dwong/book.html >>> ** >>> = ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Jun 15 07:43:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86C2D3A6915; Sun, 15 Jun 2008 07:43:52 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509D33A68A5 for ; Sun, 15 Jun 2008 07:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.974, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6V17RWJ7wMP for ; Sun, 15 Jun 2008 07:43:49 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id A227E3A687E for ; Sun, 15 Jun 2008 07:43:47 -0700 (PDT) Received: from localhost (webcartero01.uc3m.es [163.117.136.131])by smtp03.uc3m.es (Postfix) with ESMTP id 3068C3DD95C;Sun, 15 Jun 2008 16:44:23 +0200 (CEST) Received: from 221.45.217.87.dynamic.jazztel.es(221.45.217.87.dynamic.jazztel.es [87.217.45.221]) by webcartero01.uc3m.es(Horde MIME library) with HTTP; Sun, 15 Jun 2008 16:44:21 +0200 Message-ID: <20080615164421.rtkgtgdu88wgg0gk@webcartero01.uc3m.es> Date: Sun, 15 Jun 2008 16:44:21 +0200 From: MARCELO BAGNULO BRAUN To: Ashutosh Dutta References: <4843B64E.8040307@it.uc3m.es><48550B35.1010703@research.telcordia.com> In-Reply-To: <48550B35.1010703@research.telcordia.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-40.8223 TC:1F TRN:79 TV:5.5.1026(15972.007) 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) Cc: charliep@computer.org, Julien Laganier , mext@ietf.org Subject: Re: [MEXT] RFC3775 update - Simultaneous Mobility X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ashutosh, in order to consider that input, you should submit it in the folllwing form= at: - OLD TEXT in rfc 3775 that you want to change - NEW TEXT that you want to include in rfc3775bis replacing the old text - motivations for the change I would ask you to do this soon, cause we are closing the window for = submitting changes regards, marcelo Ashutosh Dutta dijo: > marcelo bagnulo braun wrote: > > Hi, > > > > In last IETF we said that we will accept input for RFC3775 changes for > > about 3 months and then try to wrap up this issues. > > > > This is reminder of that plan and that proposals for changes for RFC3775 > > are accepted till the 15 of june. > > > > After that we will go through the proposed changes and try to reach > > consensus on each of the proposed changes (including the text to be > > included and removed) in the ml. > > > > After that we will ask the authors of rfc3775 to submit a 3775bis > > including the accepted changes and go to WGLC. > > > > Regards, Julien and marcelo > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > Hi Marcelo, > > I would like to request to consider looking into this issue as part = > of the effort for the proposed changes to RFC 3775. > > Regards > Ashutosh > > -------- Original Message -------- > Subject: Re: [MEXT] simultaneous mobility > Date: Sat, 29 Mar 2008 10:02:37 +0100 > From: marcelo bagnulo > To: Ashutosh Dutta > CC: Dr. Daniel Wong , mext@ietf.org > References: = > <7db42a3e0803270046r5d034eb0sfc1568dbe77606f7@mail.gmail.com> = > <47EB5C43.1040408@it.uc3m.es> = > <47ED5A13.4070609@research.telcordia.com> > > Hi Ashutosh, > > i would suggest you to suggest what text need to be changed in rfc3775 > to solve this issue and send it to the list so people can comment > > regards, marcelo > > > > Ashutosh Dutta escribi=F3: > > Marcelo, > > As per your suggestion and brief discussion during IETF > > meeting, I looked at RFC 3775. However, I have not seen anywhere about > > the fall back option if the mobile is already operating in RO mode. > > Section 11.8 in RFC 3775 discusses about the re-transmission of > > Care-of Test Init messages and Binding Update that may go on > > indefinitely. > > > > "The retransmissions by the mobile node MUST use an exponential back- > > off process in which the timeout period is doubled upon each > > retransmission, until either the node receives a response or the > > timeout period reaches the value MAX_BINDACK_TIMEOUT. The mobile > > node MAY continue to send these messages at this slower rate > > indefinitely." > > > > > > However, if the retransmission goes on for indefinitely due to > > simultaneous mobility and there is no fall back option, it might > > affect the real-time communication because of the delayed RO. Thus, we > > will probably need to find some solution either by specifying it as > > part of RFC 3775bis or some other solution. > > > > It would be good to have some discussion on how to take care of this > > specific problem. > > > > Regards > > Ashutosh > > > > marcelo bagnulo wrote: > >>> b) it was suggested that it is not a problem when route optimization > >>> signaling is lost, because it will then fall back to bidirectional > >>> tunneling. However, once the communication session has been started > >>> and route optimization is in use, there is no mechanism specified in > >>> RFC 3775 to fall back to bidirectional tunneling (I'll let Ashutosh > >>> comment more on this point). Perhaps the introduction of such a > >>> fallback mechanism could be considered a candidate solution. > >>> > >> FWIW, imho this is how i would expect RFC3775 should behave, so imho > >> this is simply something that was not fully specified in rfc3775. > >> I would treat it as an update in rfc3775bis > >> > >> regards, marcelo > >> > >> > >> > >>> thanks > >>> Daniel > >>> > >>> -- > >>> Dr. Daniel Wong > >>> Assistant Professor > >>> Malaysia University of Science and Technology > >>> ** check out my book on wireless IP at > >>> http://www.must.edu.my/~dwong/book.html > >>> ** > >>> ---------------------------------------------------------------------= --- > >>> > >>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext > >>> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > > > > > > > > -- = ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Jun 15 20:03:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C44793A6864; Sun, 15 Jun 2008 20:03:52 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A114F3A6864 for ; Sun, 15 Jun 2008 20:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goxEkg6pdLTN for ; Sun, 15 Jun 2008 20:03:50 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 3AD003A685E for ; Sun, 15 Jun 2008 20:03:46 -0700 (PDT) Received: from [128.96.58.166] (vpntnlA166.research.telcordia.com [128.96.58.166]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id m5G342jv018396; Sun, 15 Jun 2008 23:04:02 -0400 (EDT) Message-ID: <4855D812.3090403@research.telcordia.com> Date: Sun, 15 Jun 2008 23:03:46 -0400 From: Ashutosh Dutta User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: MARCELO BAGNULO BRAUN References: <4843B64E.8040307@it.uc3m.es><48550B35.1010703@research.telcordia.com> <20080615164421.rtkgtgdu88wgg0gk@webcartero01.uc3m.es> In-Reply-To: <20080615164421.rtkgtgdu88wgg0gk@webcartero01.uc3m.es> Cc: charliep@computer.org, Julien Laganier , Wong Kuok Shoong , mext@ietf.org Subject: Re: [MEXT] RFC3775 update - Simultaneous Mobility X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Marcelo, Daniel Wong and I suggest to add the following new Text to RFC = 3775. We do not want to change any existing old text, but would like to = add the following text in section 11.8 after second paragraph in page 137. /new In certain scenarios such as in case of simultaneous mobility where both correspondent host and mobile host move at the same time, route optimization may not complete because of failed return routability procedures or failed binding updates. In such cases, the mobile SHOULD have the fall back option to resume bidirectional tunneling in order to avoid long delays in communication. Such an option could occur after a suitable timeout period. new/ Motivation: The simultaneous mobility problem statement draft http://www.ietf.org/internet-drafts/draft-wong-mext-simultaneous-ps-00.txt = that was presented in 71 IETF at Philadelphia describes how return = routability and binding update may get affected due to simultaneous = mobility of the communicating hosts. Currently, RFC 3775 does not = provide any guidelines regarding how to take care of the simultaneous = mobility problem. During the draft presentation in IETF it was suggested = to investigate RFC 3775 and propose alternative solutions to take care = of this problem. One suggested solution was to add some provision for = fall back option in 3775 and other approach would be to provide some = extension. Since there is an attempt to produce the 3775-bis draft, this = proposed text may be considered. Regards Ashutosh MARCELO BAGNULO BRAUN wrote: > Hi Ashutosh, > = > in order to consider that input, you should submit it in the folllwing = > format: > = > - OLD TEXT in rfc 3775 that you want to change > - NEW TEXT that you want to include in rfc3775bis replacing the old text > - motivations for the change > = > I would ask you to do this soon, cause we are closing the window for = > submitting changes > = > regards, marcelo > = > = > Ashutosh Dutta dijo: > = >> marcelo bagnulo braun wrote: >> > Hi, >> > >> > In last IETF we said that we will accept input for RFC3775 changes for >> > about 3 months and then try to wrap up this issues. >> > >> > This is reminder of that plan and that proposals for changes for = >> RFC3775 >> > are accepted till the 15 of june. >> > >> > After that we will go through the proposed changes and try to reach >> > consensus on each of the proposed changes (including the text to be >> > included and removed) in the ml. >> > >> > After that we will ask the authors of rfc3775 to submit a 3775bis >> > including the accepted changes and go to WGLC. >> > >> > Regards, Julien and marcelo >> > >> > _______________________________________________ >> > MEXT mailing list >> > MEXT@ietf.org >> > https://www.ietf.org/mailman/listinfo/mext >> >> Hi Marcelo, >> >> I would like to request to consider looking into this issue as = >> part of the effort for the proposed changes to RFC 3775. >> >> Regards >> Ashutosh >> >> -------- Original Message -------- >> Subject: Re: [MEXT] simultaneous mobility >> Date: Sat, 29 Mar 2008 10:02:37 +0100 >> From: marcelo bagnulo >> To: Ashutosh Dutta >> CC: Dr. Daniel Wong , mext@ietf.org >> References: = >> <7db42a3e0803270046r5d034eb0sfc1568dbe77606f7@mail.gmail.com> = >> <47EB5C43.1040408@it.uc3m.es> <47ED5A13.4070609@research.telcordia.com> >> >> Hi Ashutosh, >> >> i would suggest you to suggest what text need to be changed in rfc3775 >> to solve this issue and send it to the list so people can comment >> >> regards, marcelo >> >> >> >> Ashutosh Dutta escribi=F3: >> > Marcelo, >> > As per your suggestion and brief discussion during IETF >> > meeting, I looked at RFC 3775. However, I have not seen anywhere about >> > the fall back option if the mobile is already operating in RO mode. >> > Section 11.8 in RFC 3775 discusses about the re-transmission of >> > Care-of Test Init messages and Binding Update that may go on >> > indefinitely. >> > >> > "The retransmissions by the mobile node MUST use an exponential back- >> > off process in which the timeout period is doubled upon each >> > retransmission, until either the node receives a response or the >> > timeout period reaches the value MAX_BINDACK_TIMEOUT. The mobile >> > node MAY continue to send these messages at this slower rate >> > indefinitely." >> > >> > >> > However, if the retransmission goes on for indefinitely due to >> > simultaneous mobility and there is no fall back option, it might >> > affect the real-time communication because of the delayed RO. Thus, we >> > will probably need to find some solution either by specifying it as >> > part of RFC 3775bis or some other solution. >> > >> > It would be good to have some discussion on how to take care of this >> > specific problem. >> > >> > Regards >> > Ashutosh >> > >> > marcelo bagnulo wrote: >> >>> b) it was suggested that it is not a problem when route optimization >> >>> signaling is lost, because it will then fall back to bidirectional >> >>> tunneling. However, once the communication session has been started >> >>> and route optimization is in use, there is no mechanism specified in >> >>> RFC 3775 to fall back to bidirectional tunneling (I'll let Ashutosh >> >>> comment more on this point). Perhaps the introduction of such a >> >>> fallback mechanism could be considered a candidate solution. >> >>> >> >> FWIW, imho this is how i would expect RFC3775 should behave, so imho >> >> this is simply something that was not fully specified in rfc3775. >> >> I would treat it as an update in rfc3775bis >> >> >> >> regards, marcelo >> >> >> >> >> >> >> >>> thanks >> >>> Daniel >> >>> >> >>> -- >> >>> Dr. Daniel Wong >> >>> Assistant Professor >> >>> Malaysia University of Science and Technology >> >>> ** check out my book on wireless IP at >> >>> http://www.must.edu.my/~dwong/book.html >> >>> ** >> >>> = >> ------------------------------------------------------------------------ >> >>> >> >>> >> >>> _______________________________________________ >> >>> MEXT mailing list >> >>> MEXT@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/mext >> >>> >> >> >> >> _______________________________________________ >> >> MEXT mailing list >> >> MEXT@ietf.org >> >> https://www.ietf.org/mailman/listinfo/mext >> > >> >> >> >> >> >> > = > = > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Jun 15 20:19:41 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4B5428C0F2; Sun, 15 Jun 2008 20:19:41 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4404E28C0F2 for ; Sun, 15 Jun 2008 20:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49bNJoKFyVBb for ; Sun, 15 Jun 2008 20:19:38 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 46B423A686E for ; Sun, 15 Jun 2008 20:19:37 -0700 (PDT) Received: from [124.190.105.201] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1K85Fu-0000H6-Iv; Mon, 16 Jun 2008 13:19:43 +1000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Mon, 16 Jun 2008 13:17:54 +1000 From: Hesham Soliman To: Ashutosh Dutta , MARCELO BAGNULO BRAUN Message-ID: Thread-Topic: [MEXT] RFC3775 update - Simultaneous Mobility Thread-Index: AcjPX5DncM7LvHzcHkWG5xKZ3WVFhw== In-Reply-To: <4855D812.3090403@research.telcordia.com> Mime-version: 1.0 Cc: charliep@computer.org, mext@ietf.org, Wong Kuok Shoong , Julien Laganier Subject: Re: [MEXT] RFC3775 update - Simultaneous Mobility X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I think the text is not clear enough for specification language. Comments inline > In certain scenarios such as in case of simultaneous mobility where > both correspondent host and mobile host move at the same time, route > optimization may not complete because of failed return routability > procedures or failed binding updates. In such cases, the mobile SHOULD =3D> ^^ node > have the fall back option to resume bidirectional tunneling in order =3D> Need to reword this, perhaps remove "have the" and "option" > to avoid long delays in communication. Such an option could occur > after a suitable timeout period. new/ =3D> What's the timeout period? Do you retry RO in parallel? Or retry RO on= ce before falling back to bidirectional tunnelling? There are several variations that can be done. I think falling back permanently to bidirectional tunnelling should be the last resort. Hesham > = > Motivation: The simultaneous mobility problem statement draft > http://www.ietf.org/internet-drafts/draft-wong-mext-simultaneous-ps-00.txt > that was presented in 71 IETF at Philadelphia describes how return > routability and binding update may get affected due to simultaneous > mobility of the communicating hosts. Currently, RFC 3775 does not > provide any guidelines regarding how to take care of the simultaneous > mobility problem. During the draft presentation in IETF it was suggested > to investigate RFC 3775 and propose alternative solutions to take care > of this problem. One suggested solution was to add some provision for > fall back option in 3775 and other approach would be to provide some > extension. Since there is an attempt to produce the 3775-bis draft, this > proposed text may be considered. > = > Regards > Ashutosh > = > = > = > = > MARCELO BAGNULO BRAUN wrote: >> Hi Ashutosh, >> = >> in order to consider that input, you should submit it in the folllwing >> format: >> = >> - OLD TEXT in rfc 3775 that you want to change >> - NEW TEXT that you want to include in rfc3775bis replacing the old text >> - motivations for the change >> = >> I would ask you to do this soon, cause we are closing the window for >> submitting changes >> = >> regards, marcelo >> = >> = >> Ashutosh Dutta dijo: >> = >>> marcelo bagnulo braun wrote: >>>> Hi, >>>> = >>>> In last IETF we said that we will accept input for RFC3775 changes for >>>> about 3 months and then try to wrap up this issues. >>>> = >>>> This is reminder of that plan and that proposals for changes for >>> RFC3775 >>>> are accepted till the 15 of june. >>>> = >>>> After that we will go through the proposed changes and try to reach >>>> consensus on each of the proposed changes (including the text to be >>>> included and removed) in the ml. >>>> = >>>> After that we will ask the authors of rfc3775 to submit a 3775bis >>>> including the accepted changes and go to WGLC. >>>> = >>>> Regards, Julien and marcelo >>>> = >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> = >>> Hi Marcelo, >>> = >>> I would like to request to consider looking into this issue as >>> part of the effort for the proposed changes to RFC 3775. >>> = >>> Regards >>> Ashutosh >>> = >>> -------- Original Message -------- >>> Subject: Re: [MEXT] simultaneous mobility >>> Date: Sat, 29 Mar 2008 10:02:37 +0100 >>> From: marcelo bagnulo >>> To: Ashutosh Dutta >>> CC: Dr. Daniel Wong , mext@ietf.org >>> References: = >>> <7db42a3e0803270046r5d034eb0sfc1568dbe77606f7@mail.gmail.com> >>> <47EB5C43.1040408@it.uc3m.es> <47ED5A13.4070609@research.telcordia.com> >>> = >>> Hi Ashutosh, >>> = >>> i would suggest you to suggest what text need to be changed in rfc3775 >>> to solve this issue and send it to the list so people can comment >>> = >>> regards, marcelo >>> = >>> = >>> = >>> Ashutosh Dutta escribi=F3: >>>> Marcelo, >>>> As per your suggestion and brief discussion during IETF >>>> meeting, I looked at RFC 3775. However, I have not seen anywhere about >>>> the fall back option if the mobile is already operating in RO mode. >>>> Section 11.8 in RFC 3775 discusses about the re-transmission of >>>> Care-of Test Init messages and Binding Update that may go on >>>> indefinitely. >>>> = >>>> "The retransmissions by the mobile node MUST use an exponential back- >>>> off process in which the timeout period is doubled upon each >>>> retransmission, until either the node receives a response or the >>>> timeout period reaches the value MAX_BINDACK_TIMEOUT. The mobile >>>> node MAY continue to send these messages at this slower rate >>>> indefinitely." >>>> = >>>> = >>>> However, if the retransmission goes on for indefinitely due to >>>> simultaneous mobility and there is no fall back option, it might >>>> affect the real-time communication because of the delayed RO. Thus, we >>>> will probably need to find some solution either by specifying it as >>>> part of RFC 3775bis or some other solution. >>>> = >>>> It would be good to have some discussion on how to take care of this >>>> specific problem. >>>> = >>>> Regards >>>> Ashutosh >>>> = >>>> marcelo bagnulo wrote: >>>>>> b) it was suggested that it is not a problem when route optimization >>>>>> signaling is lost, because it will then fall back to bidirectional >>>>>> tunneling. However, once the communication session has been started >>>>>> and route optimization is in use, there is no mechanism specified in >>>>>> RFC 3775 to fall back to bidirectional tunneling (I'll let Ashutosh >>>>>> comment more on this point). Perhaps the introduction of such a >>>>>> fallback mechanism could be considered a candidate solution. >>>>>> = >>>>> FWIW, imho this is how i would expect RFC3775 should behave, so imho >>>>> this is simply something that was not fully specified in rfc3775. >>>>> I would treat it as an update in rfc3775bis >>>>> = >>>>> regards, marcelo >>>>> = >>>>> = >>>>> = >>>>>> thanks >>>>>> Daniel >>>>>> = >>>>>> -- >>>>>> Dr. Daniel Wong >>>>>> Assistant Professor >>>>>> Malaysia University of Science and Technology >>>>>> ** check out my book on wireless IP at >>>>>> http://www.must.edu.my/~dwong/book.html >>>>>> ** >>>>>> = >>> ------------------------------------------------------------------------ >>>>>> = >>>>>> = >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> = >>>>> = >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> = >>> = >>> = >>> = >>> = >>> = >>> = >> = >> = >> = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 16 05:44:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C9FB28C119; Mon, 16 Jun 2008 05:44:51 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 333CD28C119 for ; Mon, 16 Jun 2008 05:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLrTl+5SjElh for ; Mon, 16 Jun 2008 05:44:46 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by core3.amsl.com (Postfix) with ESMTP id 7C8EF28C112 for ; Mon, 16 Jun 2008 05:44:45 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id y36so365763ugd.46 for ; Mon, 16 Jun 2008 05:45:25 -0700 (PDT) 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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:sender; bh=//vKTyjkMRB8OWdneJO3sA7W/5lL18HHnbgRhWPM4l8=; b=oKYRtxBdxIfUaFkY5htKpn6gp3FnkBYQDJHJdzPln6VwTN/3Pdvo7hYrDtnCOQrRLB jbXi3kXpKKhfV4raCxubAlXbvUobTCNg5n5TVgpVxIYzH0DmafZev9WVGzTGAlDk2Vi8 rqIGTLouqm24+7OIWKejow0B2SLuKTPRKSZtQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id:sender; b=tqHdv5waGe+45SmkbBICipItRVJ6ltp+t4E+FH3aSrT2zSuDcufnE/OZTCQgN9WZak yngJPNQc5qyFsOJnWr71XZWmRe663E7u1lXOprq7JJ113nrE6vDGun1cwytS7ppKLSaq XiF2ZCZjvSCsP6GTACTVd9tdAKpEM6dOVnXaY= Received: by 10.210.58.17 with SMTP id g17mr6037690eba.190.1213620325540; Mon, 16 Jun 2008 05:45:25 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id t12sm10365858gvd.10.2008.06.16.05.45.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Jun 2008 05:45:24 -0700 (PDT) From: Julien Laganier To: marcelo bagnulo braun , mext@ietf.org Date: Mon, 16 Jun 2008 14:45:21 +0200 User-Agent: KMail/1.9.9 References: <483D5A50.1000208@it.uc3m.es> <20080603104511.GA3314@kafka.verkstad.net> <200806051742.39799.julien.IETF@laposte.net> In-Reply-To: <200806051742.39799.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806161445.22033.julien.IETF@laposte.net> Subject: Re: [MEXT] Generic Signaling Message / Name of generic "notification" (Was: Scope of generic notification) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, It seems we have reach an agreement on the ML w.r.t. the way forward for "notification"/"revocation" work items: - The working group will specify MIPv6 Generic Signalling Message (MGSM), using at least two different MH type values, one w/ IPsec protection (protect) and the other w/o IPsec protection (bypass). The MGSM shall be used whenever possible to implement future MIPv6 signalling. Different consumers of the MGSM will be distinguished based on the MGSM subtype value they use. - The MIPv6 Binding Revocation will be based on MGSM. --julien and marcelo, MEXT chairs On Thursday 05 June 2008, Julien Laganier wrote: > On Tuesday 03 June 2008, Michael Eriksson wrote: > > - I don't particularly like the "notification" part of GNM's name, > > as I think it will should be used for more than notifications. > > Folks, > > > > What Michael said above rang a bell :) > > How about calling the new framework "MIPv6 Generic Signaling Message > (MGSM), and defines two MH types, one requiring IPsec, the other not. > > Then we would distinguish different types of messages (Revocation, > Flow Distribution Rules, Heartbeat, etc.) based on a subtype inside > the Generic Signaling Message. > > I think that should satisfy everybody: > - the IPsec SPD needs only one set of rules for each of the MH types > (bypass, and protect). > - a MGSM consumer (e.g. Revocation, Distribution Rules) simply > specify the MH type it chooses depending on whether or not it > requires IPsec protection. > - a MGSM consumer allocates one or more MGSM subtypes for each new > message necessary to implement the consumer's functionality. > - a MGSM consumer specifies processing (sending, receiving, state > machines...) for these subtyped messages. > > What do you think? > > --julien > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 16 16:56:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65B203A6917; Mon, 16 Jun 2008 16:56:51 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9E9C3A68AA for ; Mon, 16 Jun 2008 16:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLMONh++9Myy for ; Mon, 16 Jun 2008 16:56:47 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 02FF33A68C7 for ; Mon, 16 Jun 2008 16:56:46 -0700 (PDT) Received: from [128.96.58.166] (vpntnlA166.research.telcordia.com [128.96.58.166]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id m5GNuSK5027932; Mon, 16 Jun 2008 19:56:34 -0400 (EDT) Message-ID: <4856FD9E.6000707@research.telcordia.com> Date: Mon, 16 Jun 2008 19:56:14 -0400 From: Ashutosh Dutta User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Cc: charliep@computer.org, mext@ietf.org, Wong Kuok Shoong , Julien Laganier Subject: Re: [MEXT] RFC3775 update - Simultaneous Mobility X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hesham, thanks for the useful feedback. Please find the revised text = taking into account your suggestions. Even with the inclusion of similar = text that defines the provision of fall back to bidirectional tunneling = mode, we still need to have a mechanism in place that will allow the = mobile to start the bi-directional tunneling in parallel when the mobile = has started the session with RO mode. Also, what is the expected behavior of the mobile node and correspondent = node when both bi-directional tunneling and RO procedures run in parallel? Thanks Ashutosh /new In certain scenarios such as in case of simultaneous mobility where both correspondent host and mobile host move at the same time, route optimization may not complete because of failed return routability procedures or failed binding updates. In such cases, the mobile node = SHOULD fall back to resume normal bidirectional tunneling in order to avoid long delays in communication. The mobile node may run the = bidirectional tunneling in parallel with the route optimization = procedure until the RO procedure is successful. Bidirectional tunneling = will start after RO procedure is not successful within a timeout period = of MAX_RO_FAILURE (needs to be defined) and may continue to be the = dafault option for that session if the RO procedure does not complete = within the specified final timeout value of MAX_BINDACK_TIMEOUT. new/ Hesham Soliman wrote: > I think the text is not clear enough for specification language. Comments > inline > = > = >> In certain scenarios such as in case of simultaneous mobility where >> both correspondent host and mobile host move at the same time, route >> optimization may not complete because of failed return routability >> procedures or failed binding updates. In such cases, the mobile SHOULD > =3D> ^^ node >> have the fall back option to resume bidirectional tunneling in order > = > =3D> Need to reword this, perhaps remove "have the" and "option" > = >> to avoid long delays in communication. Such an option could occur >> after a suitable timeout period. new/ > = > =3D> What's the timeout period? Do you retry RO in parallel? Or retry RO = once > before falling back to bidirectional tunnelling? There are several > variations that can be done. I think falling back permanently to > bidirectional tunnelling should be the last resort. > = > Hesham > = >> Motivation: The simultaneous mobility problem statement draft >> http://www.ietf.org/internet-drafts/draft-wong-mext-simultaneous-ps-00.t= xt >> that was presented in 71 IETF at Philadelphia describes how return >> routability and binding update may get affected due to simultaneous >> mobility of the communicating hosts. Currently, RFC 3775 does not >> provide any guidelines regarding how to take care of the simultaneous >> mobility problem. During the draft presentation in IETF it was suggested >> to investigate RFC 3775 and propose alternative solutions to take care >> of this problem. One suggested solution was to add some provision for >> fall back option in 3775 and other approach would be to provide some >> extension. Since there is an attempt to produce the 3775-bis draft, this >> proposed text may be considered. >> >> Regards >> Ashutosh >> >> >> >> >> MARCELO BAGNULO BRAUN wrote: >>> Hi Ashutosh, >>> >>> in order to consider that input, you should submit it in the folllwing >>> format: >>> >>> - OLD TEXT in rfc 3775 that you want to change >>> - NEW TEXT that you want to include in rfc3775bis replacing the old text >>> - motivations for the change >>> >>> I would ask you to do this soon, cause we are closing the window for >>> submitting changes >>> >>> regards, marcelo >>> >>> >>> Ashutosh Dutta dijo: >>> >>>> marcelo bagnulo braun wrote: >>>>> Hi, >>>>> >>>>> In last IETF we said that we will accept input for RFC3775 changes for >>>>> about 3 months and then try to wrap up this issues. >>>>> >>>>> This is reminder of that plan and that proposals for changes for >>>> RFC3775 >>>>> are accepted till the 15 of june. >>>>> >>>>> After that we will go through the proposed changes and try to reach >>>>> consensus on each of the proposed changes (including the text to be >>>>> included and removed) in the ml. >>>>> >>>>> After that we will ask the authors of rfc3775 to submit a 3775bis >>>>> including the accepted changes and go to WGLC. >>>>> >>>>> Regards, Julien and marcelo >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> Hi Marcelo, >>>> >>>> I would like to request to consider looking into this issue as >>>> part of the effort for the proposed changes to RFC 3775. >>>> >>>> Regards >>>> Ashutosh >>>> >>>> -------- Original Message -------- >>>> Subject: Re: [MEXT] simultaneous mobility >>>> Date: Sat, 29 Mar 2008 10:02:37 +0100 >>>> From: marcelo bagnulo >>>> To: Ashutosh Dutta >>>> CC: Dr. Daniel Wong , mext@ietf.org >>>> References: = >>>> <7db42a3e0803270046r5d034eb0sfc1568dbe77606f7@mail.gmail.com> >>>> <47EB5C43.1040408@it.uc3m.es> <47ED5A13.4070609@research.telcordia.com> >>>> >>>> Hi Ashutosh, >>>> >>>> i would suggest you to suggest what text need to be changed in rfc3775 >>>> to solve this issue and send it to the list so people can comment >>>> >>>> regards, marcelo >>>> >>>> >>>> >>>> Ashutosh Dutta escribi=F3: >>>>> Marcelo, >>>>> As per your suggestion and brief discussion during IETF >>>>> meeting, I looked at RFC 3775. However, I have not seen anywhere about >>>>> the fall back option if the mobile is already operating in RO mode. >>>>> Section 11.8 in RFC 3775 discusses about the re-transmission of >>>>> Care-of Test Init messages and Binding Update that may go on >>>>> indefinitely. >>>>> >>>>> "The retransmissions by the mobile node MUST use an exponential back- >>>>> off process in which the timeout period is doubled upon each >>>>> retransmission, until either the node receives a response or the >>>>> timeout period reaches the value MAX_BINDACK_TIMEOUT. The mobile >>>>> node MAY continue to send these messages at this slower rate >>>>> indefinitely." >>>>> >>>>> >>>>> However, if the retransmission goes on for indefinitely due to >>>>> simultaneous mobility and there is no fall back option, it might >>>>> affect the real-time communication because of the delayed RO. Thus, we >>>>> will probably need to find some solution either by specifying it as >>>>> part of RFC 3775bis or some other solution. >>>>> >>>>> It would be good to have some discussion on how to take care of this >>>>> specific problem. >>>>> >>>>> Regards >>>>> Ashutosh >>>>> >>>>> marcelo bagnulo wrote: >>>>>>> b) it was suggested that it is not a problem when route optimization >>>>>>> signaling is lost, because it will then fall back to bidirectional >>>>>>> tunneling. However, once the communication session has been started >>>>>>> and route optimization is in use, there is no mechanism specified in >>>>>>> RFC 3775 to fall back to bidirectional tunneling (I'll let Ashutosh >>>>>>> comment more on this point). Perhaps the introduction of such a >>>>>>> fallback mechanism could be considered a candidate solution. >>>>>>> >>>>>> FWIW, imho this is how i would expect RFC3775 should behave, so imho >>>>>> this is simply something that was not fully specified in rfc3775. >>>>>> I would treat it as an update in rfc3775bis >>>>>> >>>>>> regards, marcelo >>>>>> >>>>>> >>>>>> >>>>>>> thanks >>>>>>> Daniel >>>>>>> >>>>>>> -- >>>>>>> Dr. Daniel Wong >>>>>>> Assistant Professor >>>>>>> Malaysia University of Science and Technology >>>>>>> ** check out my book on wireless IP at >>>>>>> http://www.must.edu.my/~dwong/book.html >>>>>>> ** >>>>>>> >>>> ----------------------------------------------------------------------= -- >>>>>>> >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>>> >>>> >>>> >>> >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > = > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 17 00:01:31 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B81813A6A53; Tue, 17 Jun 2008 00:01:31 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 12B143A69E1; Mon, 16 Jun 2008 21:41:55 -0700 (PDT) From: The IESG To: IETF Announcement list Mime-Version: 1.0 Message-Id: <20080617044156.12B143A69E1@core3.amsl.com> Date: Mon, 16 Jun 2008 21:41:56 -0700 (PDT) X-Mailman-Approved-At: Tue, 17 Jun 2008 00:01:30 -0700 Cc: mext@ietf.org, julien.ietf@laposte.net Subject: [MEXT] WG Action: RECHARTER: Mobility EXTensions for IPv6 (mext) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org The charter of the Mobility EXTensions for IPv6 (mext) working group in the Internet Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. Mobility EXTensions for IPv6 (mext) ----------------------------------- Last Modified: 2008-05-08 Additional information is available at tools.ietf.org/wg/mext Chair(s): Julien Laganier (julien.ietf@laposte.net) Marcelo Bagnulo (marcelo@it.uc3m.es) Internet Area Director(s): Jari Arkko (jari.arkko@piuha.net) Mark Townsley (townsley@cisco.com) Internet Area Advisor: Jari Arkko (jari.arkko@piuha.net) Mailing Lists: General Discussion: mext@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/mext Archive: http://www1.ietf.org/mail-archive/web/mext/current 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, (A.6) support for AAA is needed as a continuation of earlier work on bootstrapping, (A.7) revocation of binding, (A.8) generic notification message format and (A.9) extended DMSIP home network support . 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. (A.7) Binding Revocation for IP Mobility: Define a binding revocation mechanism for Mobile IPv6 and its extensions. This mechanism can be used by any entity involved in the base Mobile IPv6 protocol or one of its extensions to request its corresponding entity to terminate either one, multiple or all binding cache entries. (A.8) 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. (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6 assumes the home network to be dual stack providing simultaneous IPv6 and IPv4 network access. It is proposed to extend DSMIPv6 to support home networks which provides IPv4, or IPv6 respectively, direct network access only, but where virtual IPv6 home network connectivity, or virtual IPv4 home network connectivity respectively, may be obtained by tunneling to the HA. The latter shall be obtained by DSMIPv6 operation using the v4HoA address as Care-of-address for the v6HoA address, and vice versa, the v6HoA address as care-of-address for the v4HoA address. 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). (C.2) Virtual Home Link configuration for Mobile IPv6: A proposal has been made on Mobile IPv6 home link configuration on virtual links. The proposal does not describe any new protocol, but provides the operational and configuration details and additionally provides implementation guidance for achieving this configuration. 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 INT and SEC 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 Dec 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard. Dec 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational. Dec 2007 Submit Multiple CoA Registration to IESG Done Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard Feb 2008 Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational. Feb 2008 Submit -00 draft on Route Optimization needs for Personal Mobile Router Feb 2008 Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments Feb 2008 Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments Mar 2008 Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard Done Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard May 2008 Submit final doc on Route Optimization needs for Personal Mobile Router, 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 Aircraft and Spacecraft Deployments, for Informational May 2008 Submit -00 draft for solution to aircraft/spacecraft problem Jun 2008 Determine how to proceed with remaining automotive/Personal Mobile Router solutions Jun 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. June 08 Submit 00 draft on Binding Revocation Jul 2008 Submit Analysis of the use of Multiple Simultaneous Care-of Addresses and Home Agent addresses, for Informational Jul 2008 Submit Multiple Interfaces Motivations and Scenario to IESG, for Informational Aug 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Aug 2008 Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard Oct 2008 Submit Flow/binding policy transport to IESG, for Proposed Standard Oct 2008 Submit Flow/binding policy format to IESG, for Proposed Standard Oct 08 Submit 00 draft on Generic Notification Oct 08 Submit draft on Binding Revocation to IESG 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 08 Submit 00 draft on Virtual Home link configuration Dec 08 Submit 00 draft on Extended DSMIPv6 Home Network support 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. Jan 09 Submit draft on Generic Notification to IESG Mar 09 Submit draft on Virtual Home link configuration to IESG May 09 Submit draft on Extended DSMIPv6 Home Network support to IESG _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 17 00:01:32 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 422823A6A68; Tue, 17 Jun 2008 00:01:32 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2C83A6A2D for ; Mon, 16 Jun 2008 23:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSQ8Bi6PGyzt for ; Mon, 16 Jun 2008 23:29:53 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by core3.amsl.com (Postfix) with ESMTP id 530843A6853 for ; Mon, 16 Jun 2008 23:29:52 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so2022945and.122 for ; Mon, 16 Jun 2008 23:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=LjbXf9lJ65FrTiBvJ4QH2g+trOhfhWSihkp/ocjZQoE=; b=wtRw3JhTCiAPlWScP3wuDoZrp0bXRtGqO8UThZChLLiL8TwcujP1OTr9q7sHwPqnEc 9VqoeaPJmNtbesASNcAS00EfKdYVkZ8K6y5LFPP5ts9COPhyJvYcJbuvOQ3id+IjBkFm aMHsi/o9epPcoHAtD8ZlGwisBc2oY1uFdh1Jk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=jm8u07X8cAa8qjBJ7u55NiRkN250sdwujHVmCXn41EEfaf1/Ol4VUjx3APM9N3vqYK 0G23ju4yNF7Hs/1jaoF/45tKlTM84zDHzWDnABOJ17FAjc2MWXlUR/paamrO7Hrw/iRz W1SqOzwgkd+0xHZg1O0vllxgtzlflDimTXgu8= Received: by 10.100.41.1 with SMTP id o1mr10027638ano.10.1213684229347; Mon, 16 Jun 2008 23:30:29 -0700 (PDT) Received: by 10.101.67.19 with HTTP; Mon, 16 Jun 2008 23:30:29 -0700 (PDT) Message-ID: <53905c00806162330r5a4d5cc2kd603674d3672677b@mail.gmail.com> Date: Mon, 16 Jun 2008 23:30:29 -0700 From: "Daniel Wong" To: "Ashutosh Dutta" In-Reply-To: <4856FD9E.6000707@research.telcordia.com> MIME-Version: 1.0 Content-Disposition: inline References: <4856FD9E.6000707@research.telcordia.com> X-Google-Sender-Auth: 3ab780a62701e785 X-Mailman-Approved-At: Tue, 17 Jun 2008 00:01:30 -0700 Cc: charliep@computer.org, Julien Laganier , mext@ietf.org Subject: Re: [MEXT] RFC3775 update - Simultaneous Mobility X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Thanks, Hesham, for your insightful comments. Indeed, when Ashutosh and I were discussing about how this type of fallback solution (fallback from route optimization to reverse tunneling in cases where route optimization messages are getting lost due to simultaneous mobility or other reasons), it seems there are a number of possible ways to proceed, and they have their various pros and cons. For example, continuing to retry RO while falling back on reverse tunneling in parallel might be faster, but might have some new tricky protocol and timing issues that need to be carefully thought through. We would need to specify the correspondent host, home agent and mobile host behaviors carefully. If it is not done in parallel (say, it stops trying RO after one retry, and just falls back to reverse tunneling), then it may or may not have to use reverse tunneling for the rest of the session. maybe it could try RO again the next time it moves or something. Daniel On Mon, Jun 16, 2008 at 4:56 PM, Ashutosh Dutta wrote: > Hesham, thanks for the useful feedback. Please find the revised text taki= ng > into account your suggestions. Even with the inclusion of similar text th= at > defines the provision of fall back to bidirectional tunneling mode, we st= ill > need to have a mechanism in place that will allow the mobile to start the > bi-directional tunneling in parallel when the mobile has started the sess= ion > with RO mode. > > Also, what is the expected behavior of the mobile node and correspondent > node when both bi-directional tunneling and RO procedures run in parallel? > > Thanks > Ashutosh > > /new > In certain scenarios such as in case of simultaneous mobility where > both correspondent host and mobile host move at the same time, route > optimization may not complete because of failed return routability > procedures or failed binding updates. In such cases, the mobile node SHOU= LD > fall back to resume normal bidirectional tunneling in order > to avoid long delays in communication. The mobile node may run the > bidirectional tunneling in parallel with the route optimization procedure > until the RO procedure is successful. Bidirectional tunneling will start > after RO procedure is not successful within a timeout period of > MAX_RO_FAILURE (needs to be defined) and may continue to be the dafault > option for that session if the RO procedure does not complete within the > specified final timeout value of MAX_BINDACK_TIMEOUT. new/ > > > Hesham Soliman wrote: >> >> I think the text is not clear enough for specification language. Comments >> inline >> >> >>> In certain scenarios such as in case of simultaneous mobility where >>> both correspondent host and mobile host move at the same time, route >>> optimization may not complete because of failed return routability >>> procedures or failed binding updates. In such cases, the mobile SHOULD >> >> =3D> ^^ no= de >>> >>> have the fall back option to resume bidirectional tunneling in order >> >> =3D> Need to reword this, perhaps remove "have the" and "option" >> >>> to avoid long delays in communication. Such an option could occur >>> after a suitable timeout period. new/ >> >> =3D> What's the timeout period? Do you retry RO in parallel? Or retry RO >> once >> before falling back to bidirectional tunnelling? There are several >> variations that can be done. I think falling back permanently to >> bidirectional tunnelling should be the last resort. >> >> Hesham >> >>> Motivation: The simultaneous mobility problem statement draft >>> >>> http://www.ietf.org/internet-drafts/draft-wong-mext-simultaneous-ps-00.= txt >>> that was presented in 71 IETF at Philadelphia describes how return >>> routability and binding update may get affected due to simultaneous >>> mobility of the communicating hosts. Currently, RFC 3775 does not >>> provide any guidelines regarding how to take care of the simultaneous >>> mobility problem. During the draft presentation in IETF it was suggested >>> to investigate RFC 3775 and propose alternative solutions to take care >>> of this problem. One suggested solution was to add some provision for >>> fall back option in 3775 and other approach would be to provide some >>> extension. Since there is an attempt to produce the 3775-bis draft, this >>> proposed text may be considered. >>> >>> Regards >>> Ashutosh >>> >>> >>> >>> >>> MARCELO BAGNULO BRAUN wrote: >>>> >>>> Hi Ashutosh, >>>> >>>> in order to consider that input, you should submit it in the folllwing >>>> format: >>>> >>>> - OLD TEXT in rfc 3775 that you want to change >>>> - NEW TEXT that you want to include in rfc3775bis replacing the old te= xt >>>> - motivations for the change >>>> >>>> I would ask you to do this soon, cause we are closing the window for >>>> submitting changes >>>> >>>> regards, marcelo >>>> >>>> >>>> Ashutosh Dutta dijo: >>>> >>>>> marcelo bagnulo braun wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> In last IETF we said that we will accept input for RFC3775 changes f= or >>>>>> about 3 months and then try to wrap up this issues. >>>>>> >>>>>> This is reminder of that plan and that proposals for changes for >>>>> >>>>> RFC3775 >>>>>> >>>>>> are accepted till the 15 of june. >>>>>> >>>>>> After that we will go through the proposed changes and try to reach >>>>>> consensus on each of the proposed changes (including the text to be >>>>>> included and removed) in the ml. >>>>>> >>>>>> After that we will ask the authors of rfc3775 to submit a 3775bis >>>>>> including the accepted changes and go to WGLC. >>>>>> >>>>>> Regards, Julien and marcelo >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> Hi Marcelo, >>>>> >>>>> I would like to request to consider looking into this issue as >>>>> part of the effort for the proposed changes to RFC 3775. >>>>> >>>>> Regards >>>>> Ashutosh >>>>> >>>>> -------- Original Message -------- >>>>> Subject: Re: [MEXT] simultaneous mobility >>>>> Date: Sat, 29 Mar 2008 10:02:37 +0100 >>>>> From: marcelo bagnulo >>>>> To: Ashutosh Dutta >>>>> CC: Dr. Daniel Wong , mext@ietf.org >>>>> References: >>>>> <7db42a3e0803270046r5d034eb0sfc1568dbe77606f7@mail.gmail.com> >>>>> <47EB5C43.1040408@it.uc3m.es> <47ED5A13.4070609@research.telcordia.co= m> >>>>> >>>>> Hi Ashutosh, >>>>> >>>>> i would suggest you to suggest what text need to be changed in rfc3775 >>>>> to solve this issue and send it to the list so people can comment >>>>> >>>>> regards, marcelo >>>>> >>>>> >>>>> >>>>> Ashutosh Dutta escribi=F3: >>>>>> >>>>>> Marcelo, >>>>>> As per your suggestion and brief discussion during IETF >>>>>> meeting, I looked at RFC 3775. However, I have not seen anywhere abo= ut >>>>>> the fall back option if the mobile is already operating in RO mode. >>>>>> Section 11.8 in RFC 3775 discusses about the re-transmission of >>>>>> Care-of Test Init messages and Binding Update that may go on >>>>>> indefinitely. >>>>>> >>>>>> "The retransmissions by the mobile node MUST use an exponential back- >>>>>> off process in which the timeout period is doubled upon each >>>>>> retransmission, until either the node receives a response or the >>>>>> timeout period reaches the value MAX_BINDACK_TIMEOUT. The mobile >>>>>> node MAY continue to send these messages at this slower rate >>>>>> indefinitely." >>>>>> >>>>>> >>>>>> However, if the retransmission goes on for indefinitely due to >>>>>> simultaneous mobility and there is no fall back option, it might >>>>>> affect the real-time communication because of the delayed RO. Thus, = we >>>>>> will probably need to find some solution either by specifying it as >>>>>> part of RFC 3775bis or some other solution. >>>>>> >>>>>> It would be good to have some discussion on how to take care of this >>>>>> specific problem. >>>>>> >>>>>> Regards >>>>>> Ashutosh >>>>>> >>>>>> marcelo bagnulo wrote: >>>>>>>> >>>>>>>> b) it was suggested that it is not a problem when route optimizati= on >>>>>>>> signaling is lost, because it will then fall back to bidirectional >>>>>>>> tunneling. However, once the communication session has been started >>>>>>>> and route optimization is in use, there is no mechanism specified = in >>>>>>>> RFC 3775 to fall back to bidirectional tunneling (I'll let Ashutosh >>>>>>>> comment more on this point). Perhaps the introduction of such a >>>>>>>> fallback mechanism could be considered a candidate solution. >>>>>>>> >>>>>>> FWIW, imho this is how i would expect RFC3775 should behave, so imho >>>>>>> this is simply something that was not fully specified in rfc3775. >>>>>>> I would treat it as an update in rfc3775bis >>>>>>> >>>>>>> regards, marcelo >>>>>>> >>>>>>> >>>>>>> >>>>>>>> thanks >>>>>>>> Daniel >>>>>>>> >>>>>>>> -- >>>>>>>> Dr. Daniel Wong >>>>>>>> Assistant Professor >>>>>>>> Malaysia University of Science and Technology >>>>>>>> ** check out my book on wireless IP at >>>>>>>> http://www.must.edu.my/~dwong/book.html >>>>>>>> ** >>>>>>>> >>>>> >>>>> ---------------------------------------------------------------------= --- >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 17 04:15:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F69C28C114; Tue, 17 Jun 2008 04:15:04 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 68CE13A6A8C; Tue, 17 Jun 2008 04:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080617111501.68CE13A6A8C@core3.amsl.com> Date: Tue, 17 Jun 2008 04:15:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-pd-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : DHCPv6 Prefix Delegation for NEMO Author(s) : R. Droms, et al. Filename : draft-ietf-mext-nemo-pd-00.txt Pages : 12 Date : 2008-06-17 One aspect of network mobility support is the assignment of a prefix or prefixes to a Mobile Router (MR) for use on the links in the Mobile Network. DHCPv6 prefix delegation can be used for this configuration task. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-nemo-pd-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-17041246.I-D@ietf.org> --NextPart 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://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Tue Jun 17 05:05:55 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A1FE3A6872; Tue, 17 Jun 2008 05:05:55 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECF193A6872 for ; Tue, 17 Jun 2008 05:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFSsPg6A3yhG for ; Tue, 17 Jun 2008 05:05:53 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by core3.amsl.com (Postfix) with ESMTP id 819243A67D7 for ; Tue, 17 Jun 2008 05:05:52 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id y36so552564ugd.46 for ; Tue, 17 Jun 2008 05:06:34 -0700 (PDT) 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=ba5YxbUOUCbYNYtC2DcJpHsDmG1Uq4F615ZJno8N0UE=; b=moUnMo4F+/w4byv3ElL3As0iIgcjMBl/d3HZ1KEn7t/5zJyTultZU9lJ7d1LDoyH8k GWnemo+5nrPR2KXdB5npYaa972fw2ZWOEQReTLvcQV+1UVKQRf3Bt+v5qwqtLBjEAEo+ Pfur4eJSTxFMI4Bkb9Do3hgK/ak4VN5P/EduI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:sender; b=XPmQPhPb4ETI2WM/ztRCs57zrTN1vsOedhi6fIIErSYKphMnbHeg14mfRrH4XTqaKG IiPlo41ceX56/sokWSQFIN2Wvuy+XkWA3de5iXnCrv3kZ3FipDEbi9zy9zjses1a2Sx+ Qx0/x9JFoVZbxRCOVm4kWX5cShg5lKwf3DipQ= Received: by 10.210.16.10 with SMTP id 10mr7518017ebp.118.1213704392430; Tue, 17 Jun 2008 05:06:32 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id f13sm12091171gvd.2.2008.06.17.05.06.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Jun 2008 05:06:31 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Tue, 17 Jun 2008 14:06:30 +0200 User-Agent: KMail/1.9.9 References: <20080518154501.6316528C481@core3.amsl.com> In-Reply-To: <20080518154501.6316528C481@core3.amsl.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806171406.30276.julien.IETF@laposte.net> Subject: Re: [MEXT] I-D Action:draft-ietf-mext-flow-binding-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, We are chartered to produce a Flow/binding policy transport specification and we have a corresponding WG draft. To move forward with that work item it would be great if participants to this WG would review the draft. Thanks for your support. --julien & marcelo, MEXT chairs On Sunday 18 May 2008, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Mobility EXTensions for > IPv6 Working Group of the IETF. > > > Title : Flow Bindings in Mobile IPv6 and Nemo Basic > Support Author(s) : H. Soliman, et al. > Filename : draft-ietf-mext-flow-binding-00.txt > Pages : 32 > Date : 2008-05-16 > > This document introduces extensions to Mobile IPv6 [1] and Nemo Basic > Support [2] that allow nodes to bind one or more flows to a care-of > address. These extensions allow multihomed nodes to take full > advantage of the different properties associated with each of their > interfaces. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mext-flow-binding-00.t >xt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 17 05:43:14 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0317928C10E; Tue, 17 Jun 2008 05:43:14 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CE353A6A80 for ; Tue, 17 Jun 2008 05:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0aN0ehGv9BN for ; Tue, 17 Jun 2008 05:43:08 -0700 (PDT) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.181]) by core3.amsl.com (Postfix) with ESMTP id 3F4A53A698A for ; Tue, 17 Jun 2008 05:43:07 -0700 (PDT) Received: by ik-out-1112.google.com with SMTP id c28so4547014ika.5 for ; Tue, 17 Jun 2008 05:43:47 -0700 (PDT) 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-disposition:message-id :content-type:content-transfer-encoding:sender; bh=mTBdNdy+JGtgoNXYqOia5/2z/yXpYkb9lq0dW1YUgDk=; b=x743Vb5nNLPMw67Mw8yd0IYl4TKYfOa6bAFefbMjl/Jk5nIbxRjnq3aLu6BtPh0YxR f6VsiGeuyLQ1DsfgMdyurFcWZmTinsmiPpWJg6JFvn6a7c3HmEJvMCqFd9hsRiRSccct mtFWVLxEodtX5oRDHVAALj2dHVUZAdG12aEhw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:mime-version:content-disposition :message-id:content-type:content-transfer-encoding:sender; b=P6YeiBBNEHgwLIrofe0nuvHuQ5/LyCQcZU/ESLSCKFkTAqPuq+Y0pC5/6Q53KwCOoS L+Hfw+BzwmXVH2Q3RklZcb0eUR11H6X9sPgN6Bh0BqUXymbOXgae2udW0FQC2reUz9My OiO9DkhxeLjZdRU6eNpUbH36XFsYSiyGQdw5k= Received: by 10.210.138.7 with SMTP id l7mr7576777ebd.108.1213706626893; Tue, 17 Jun 2008 05:43:46 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id j8sm12111915gvb.1.2008.06.17.05.43.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Jun 2008 05:43:46 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Tue, 17 Jun 2008 14:43:46 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806171443.46977.julien.IETF@laposte.net> Subject: [MEXT] Adoption of FW docs as MEXT WG drafts X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, We are chartered to produce informational documents describing Mobile IPv6 Operation with Firewalls but so far we have no corresponding WG drafts. There are two individual submissions filling this hole together: - Guidelines for firewall vendors regarding MIPv6 traffic -Guidelines for firewall administrators regarding MIPv6 traffic They have been updated as per comments received during last IETF meeting and we agreed we would ask for their adoption as WG drafts. Hereby we'd like to request the WG participants to answer the following question: Shall the two drafts above be made WG drafts? Thank you for your support. --julien & marcelo, MEXT chairs. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 17 05:43:20 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90E9D28C167; Tue, 17 Jun 2008 05:43:20 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2471628C166 for ; Tue, 17 Jun 2008 05:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.662 X-Spam-Level: X-Spam-Status: No, score=-3.662 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHcYxlevZf78 for ; Tue, 17 Jun 2008 05:43:19 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 25A8928C167 for ; Tue, 17 Jun 2008 05:43:18 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (134.pool85-53-139.dynamic.orange.es [85.53.139.134])by smtp03.uc3m.es (Postfix) with ESMTP id AC7583EDFC7; Tue, 17 Jun 2008 14:44:01 +0200 (CEST) Message-ID: <4857B191.8090103@it.uc3m.es> Date: Tue, 17 Jun 2008 14:44:01 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: mext X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:7.0045 TC:1F TRN:7 TV:5.5.1026(15976.007) X-imss-scores: Clean:1.12907 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier Subject: [MEXT] call for agenda items for mext meeting at ietf72 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, we will be meeting at ietf72. If you want to present something, let us know Regards, julien and marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 17 08:07:02 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52C5428C18E; Tue, 17 Jun 2008 08:07:02 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53E4D3A6838 for ; Tue, 17 Jun 2008 08:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqtPU4q0Ozn6 for ; Tue, 17 Jun 2008 08:06:55 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id BAA3B3A6B16 for ; Tue, 17 Jun 2008 08:06:55 -0700 (PDT) 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 <0K2M009FA4ORDT@usaga04-in.huawei.com> for mext@ietf.org; Tue, 17 Jun 2008 10:07:40 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K2M00D7D4OP7T@usaga04-in.huawei.com> for mext@ietf.org; Tue, 17 Jun 2008 10:07:39 -0500 (CDT) Date: Tue, 17 Jun 2008 10:07:39 -0500 From: Frank Xia To: Julien Laganier , mext@ietf.org Message-id: <006201c8d08b$e2eca410$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <200806171443.46977.julien.IETF@laposte.net> Subject: Re: [MEXT] Adoption of FW docs as MEXT WG drafts X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Yes, the two drafts should be made WG drafts. BR Frank ----- Original Message ----- From: "Julien Laganier" To: Sent: Tuesday, June 17, 2008 7:43 AM Subject: [MEXT] Adoption of FW docs as MEXT WG drafts > Folks, > > We are chartered to produce informational documents describing Mobile > IPv6 Operation with Firewalls but so far we have no corresponding WG > drafts. > > There are two individual submissions filling this hole together: > > - Guidelines for firewall vendors regarding MIPv6 traffic > > > -Guidelines for firewall administrators regarding MIPv6 traffic > > > They have been updated as per comments received during last IETF meeting > and we agreed we would ask for their adoption as WG drafts. Hereby we'd > like to request the WG participants to answer the following question: > > Shall the two drafts above be made WG drafts? > > Thank you for your support. > > --julien & marcelo, MEXT chairs. > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 17 08:14:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BEF428C1A4; Tue, 17 Jun 2008 08:14:47 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51153A6B16 for ; Tue, 17 Jun 2008 08:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXFwBqbH-7X2 for ; Tue, 17 Jun 2008 08:14:44 -0700 (PDT) Received: from web84306.mail.re1.yahoo.com (web84306.mail.re1.yahoo.com [69.147.74.185]) by core3.amsl.com (Postfix) with SMTP id 28BEF3A6B45 for ; Tue, 17 Jun 2008 08:14:44 -0700 (PDT) Received: (qmail 35809 invoked by uid 60001); 17 Jun 2008 15:15:28 -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=UXyIG4VRoRjMe3qI0l92b6shvDPqiZF7E+c0EV3dTF7LLTu9U6gx2cVr7U8l9gSUiwF1a+4ZSXlXjtr4EhVxkv7ZNGl3CNPTjQalzueIYkzqJIaUY+tv2vQ5/hDlg1tzLatWLNGNeqQkboxxWYO15uW9D7Yzg/dViAHTKOeNt0M=; X-YMail-OSG: aat2wxAVM1mY.mYk8bl67PMuLliHjX3JMcrpqiUgOqDp7GGwK4.peXedKDbR0zNsvQ-- Received: from [206.16.17.212] by web84306.mail.re1.yahoo.com via HTTP; Tue, 17 Jun 2008 08:15:28 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.185 Date: Tue, 17 Jun 2008 08:15:28 -0700 (PDT) From: Behcet Sarikaya To: Julien Laganier MIME-Version: 1.0 Message-ID: <557224.35425.qm@web84306.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 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="===============0279355182==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0279355182== Content-Type: multipart/alternative; boundary="0-1295217272-1213715728=:35425" --0-1295217272-1213715728=:35425 Content-Type: text/plain; charset=us-ascii Hi Julien, It seems like draft-ietf-mext-nemo-pd-00.txt does not carry any changes based on the long and heated debates we had on draft-droms-mext-nemo-pd-00.txt. It is a keep-alive version. Is this what you expected from the authors? Regards, Behcet ----- Original Message ---- From: Julien Laganier To: draft-droms-mext-nemo-pd@tools.ietf.org Cc: mext@ietf.org Sent: Friday, June 13, 2008 10:42:14 AM Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Folks, We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as a WG draft corresponding to the Nemo Prefix Delegation work item. Authors, please resubmit the draft as WG draft under the name: draft-ietf-mext-nemo-pd-00.txt Note: you can use the online I-D submission tool to make it faster: Thanks. --julien & marcelo, MEXT chairs. On Friday 30 May 2008, marcelo bagnulo braun wrote: > Hi, > > We would like to ask the WG what is their opinion about accepting > draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD > deliverable included in our charter. > > Please provide comments so we cna make some progress on this long > overdue deliverable > > thanks, Julien and marcelo > > -------- Mensaje original -------- > Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt > Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) > De: Internet-Drafts@ietf.org > Responder a: internet-drafts@ietf.org > Para: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : DHCPv6 Prefix Delegation for NEMO > Author(s) : R. Droms, et al. > Filename : draft-droms-mext-nemo-pd-00.txt > Pages : 12 > Date : 2008-05-30 > > One aspect of network mobility support is the assignment of a prefix > or prefixes to a Mobile Router (MR) for use on the links in the > Mobile Network. DHCPv6 prefix delegation can be used for this > configuration task. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-1295217272-1213715728=:35425 Content-Type: text/html; charset=us-ascii
Hi Julien,
  It seems like draft-ietf-mext-nemo-pd-00.txt does not carry any changes based on the long and heated debates we had on draft-droms-mext-nemo-pd-00.txt. It is a keep-alive version.
  Is this what you expected from the authors?

Regards,

Behcet

----- Original Message ----
From: Julien Laganier <julien.IETF@laposte.net>
To: draft-droms-mext-nemo-pd@tools.ietf.org
Cc: mext@ietf.org
Sent: Friday, June 13, 2008 10:42:14 AM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

Folks,

We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as a WG
draft corresponding to the Nemo Prefix Delegation work item.

Authors, please resubmit the draft as WG draft under the name:

    draft-ietf-mext-nemo-pd-00.txt

Note: you can use the online I-D submission tool to make it faster:
<https://datatracker.ietf.org/idst/upload.cgi>

Thanks.

--julien & marcelo, MEXT chairs.

On Friday 30 May 2008, marcelo bagnulo braun wrote:
> Hi,
>
> We would like to ask the WG what is their opinion about accepting
> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD
> deliverable included in our charter.
>
> Please provide comments so we cna make some progress on this long
> overdue deliverable
>
> thanks, Julien and marcelo
>
> -------- Mensaje original --------
> Asunto:     I-D Action:draft-droms-mext-nemo-pd-00.txt
> Fecha:     Fri, 30 May 2008 05:45:01 -0700 (PDT)
> De:     Internet-Drafts@ietf.org
> Responder a:     internet-drafts@ietf.org
> Para:     i-d-announce@ietf.org
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>     Title          : DHCPv6 Prefix Delegation for NEMO
>     Author(s)      : R. Droms, et al.
>     Filename        : draft-droms-mext-nemo-pd-00.txt
>     Pages          : 12
>     Date            : 2008-05-30
>
> One aspect of network mobility support is the assignment of a prefix
> or prefixes to a Mobile Router (MR) for use on the links in the
> Mobile Network.  DHCPv6 prefix delegation can be used for this
> configuration task.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.


_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
--0-1295217272-1213715728=:35425-- --===============0279355182== 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://www.ietf.org/mailman/listinfo/mext --===============0279355182==-- From mext-bounces@ietf.org Tue Jun 17 13:17:36 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A71A828C115; Tue, 17 Jun 2008 13:17:36 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 764AC28C115 for ; Tue, 17 Jun 2008 13:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VG9a4Mh7KNm for ; Tue, 17 Jun 2008 13:17:34 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 4CC2828C0E2 for ; Tue, 17 Jun 2008 13:17:34 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id F0B031986E7; Tue, 17 Jun 2008 23:18:18 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id A6257198671; Tue, 17 Jun 2008 23:18:18 +0300 (EEST) Message-ID: <48581C31.5080200@piuha.net> Date: Tue, 17 Jun 2008 23:18:57 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Ashutosh Dutta References: <4843B64E.8040307@it.uc3m.es><48550B35.1010703@research.telcordia.com> <20080615164421.rtkgtgdu88wgg0gk@webcartero01.uc3m.es> <4855D812.3090403@research.telcordia.com> In-Reply-To: <4855D812.3090403@research.telcordia.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: mext@ietf.org Subject: Re: [MEXT] RFC3775 update - Simultaneous Mobility X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ashutosh, I think something may need to be done with respect to this issue, but I agree with Hesham that we are far from having the right text for it yet. I'm still struggling with the definition of the problem, actually. There are a couple of issues that interact: 1) Mobile nodes cannot send traffic from their new care-of address directly to a correspondent node before they have sent the RO BU to the it (Section 11.3.1). This cannot happen before they have executed the full return routability procedure. From this we can conclude that if there is any data traffic to the correspondent node, it will have to go through the correspondent node's home address and home agent. 2) What is the reaction of the correspondent node when it receives tunneled traffic? See Section 11.7.2. But return routability packets are exempt from this rule. 3) Whether the usual RO rules for the destination apply to RR packets or not; as far as I know there are no special rules for them. Did I miss anything? Based on the above, I have a few questions: - If we need to specify something new action on this, should this action be triggered by (a) data traffic or (b) lack of response to RR packets? - Or is it simply wrong to attempt to do the signaling to the peer's care-of address, maybe we should require doing it via the home address instead? - Why is this issue specific to simultaneous movement? Wouldn't it happen also if the peer rebooted and got a new address, as well? Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 18 02:00:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E03EE28C147; Wed, 18 Jun 2008 02:00:03 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02DC73A69FC for ; Wed, 18 Jun 2008 02:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpwG2Rk++j0g for ; Wed, 18 Jun 2008 02:00:01 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by core3.amsl.com (Postfix) with ESMTP id 61F4B3A6A97 for ; Wed, 18 Jun 2008 02:00:01 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id y36so746180ugd.46 for ; Wed, 18 Jun 2008 02:00:47 -0700 (PDT) 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=pN9RQN+GPQtIKBZajX37Y3zktku9J2LGgzyda9jA0XY=; b=OjDrvIfDPAylSPPbJQawMrTA6+ZGl2Tiiw9Q5LJLtM7a1Uj47EHgZpURcnbQsPJdAz CsrnpPYkS06B4hZsFqtN90Zpe6kb2+jec3yDsegXriDJXcwKpxoOjQDcQsQbJ8GTwcxV sfZDsF75xbb9VuRAGzlFKSl4zvDXJO02hIdfg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:sender; b=ZxsveVTfpTUp9azDQ9wLwnGkFi54M31lBTOjjbsG8rxzgd0o32NxFDm22Kh6fdykFk eh32HxYvn7pua0+4GWSspP8e0fa7A2sk4trRUCXYVJlSjpvsroG6hkFMj1wxY/tk1jk0 V4uxpHY0zoNkUFZ18nArZ6IY4AjfdgCcqSXDs= Received: by 10.210.79.14 with SMTP id c14mr276260ebb.181.1213779647562; Wed, 18 Jun 2008 02:00:47 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id g9sm13855824gvc.0.2008.06.18.02.00.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Jun 2008 02:00:46 -0700 (PDT) From: Julien Laganier To: Behcet Sarikaya Date: Wed, 18 Jun 2008 11:00:49 +0200 User-Agent: KMail/1.9.9 References: <557224.35425.qm@web84306.mail.re1.yahoo.com> In-Reply-To: <557224.35425.qm@web84306.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806181100.50199.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Behcet, I'm wondering what you're wondering about -- the message I sent (excerpt below) is quite explicit, isn't it? > We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as a > WG draft corresponding to the Nemo Prefix Delegation work item. > > Authors, please resubmit the draft as WG draft under the name: > > draft-ietf-mext-nemo-pd-00.txt --julien On Tuesday 17 June 2008, Behcet Sarikaya wrote: > Hi Julien, > It seems like draft-ietf-mext-nemo-pd-00.txt does not carry any > changes based on the long and heated debates we had on > draft-droms-mext-nemo-pd-00.txt. It is a keep-alive version. Is this > what you expected from the authors? > > Regards, > > Behcet > > > ----- Original Message ---- > From: Julien Laganier > To: draft-droms-mext-nemo-pd@tools.ietf.org > Cc: mext@ietf.org > Sent: Friday, June 13, 2008 10:42:14 AM > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > Folks, > > We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as a > WG draft corresponding to the Nemo Prefix Delegation work item. > > Authors, please resubmit the draft as WG draft under the name: > > draft-ietf-mext-nemo-pd-00.txt > > Note: you can use the online I-D submission tool to make it faster: > > > Thanks. > > --julien & marcelo, MEXT chairs. > > On Friday 30 May 2008, marcelo bagnulo braun wrote: > > Hi, > > > > We would like to ask the WG what is their opinion about accepting > > draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD > > deliverable included in our charter. > > > > Please provide comments so we cna make some progress on this long > > overdue deliverable > > > > thanks, Julien and marcelo > > > > -------- Mensaje original -------- > > Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt > > Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) > > De: Internet-Drafts@ietf.org > > Responder a: internet-drafts@ietf.org > > Para: i-d-announce@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : DHCPv6 Prefix Delegation for NEMO > > Author(s) : R. Droms, et al. > > Filename : draft-droms-mext-nemo-pd-00.txt > > Pages : 12 > > Date : 2008-05-30 > > > > One aspect of network mobility support is the assignment of a > > prefix or prefixes to a Mobile Router (MR) for use on the links in > > the Mobile Network. DHCPv6 prefix delegation can be used for this > > configuration task. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 18 06:34:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9A43A6A08; Wed, 18 Jun 2008 06:34:15 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34493A6A08 for ; Wed, 18 Jun 2008 06:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxEpPd1+98SC for ; Wed, 18 Jun 2008 06:34:13 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 7903B3A69A2 for ; Wed, 18 Jun 2008 06:34:10 -0700 (PDT) Received: from [128.96.58.166] (vpntnlA166.research.telcordia.com [128.96.58.166]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id m5IDYnOw010503; Wed, 18 Jun 2008 09:34:49 -0400 (EDT) Message-ID: <48590EEC.6000107@research.telcordia.com> Date: Wed, 18 Jun 2008 09:34:36 -0400 From: Ashutosh Dutta User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Jari Arkko References: <4843B64E.8040307@it.uc3m.es><48550B35.1010703@research.telcordia.com> <20080615164421.rtkgtgdu88wgg0gk@webcartero01.uc3m.es> <4855D812.3090403@research.telcordia.com> <48581C31.5080200@piuha.net> In-Reply-To: <48581C31.5080200@piuha.net> Cc: Wong Kuok Shoong , mext@ietf.org Subject: Re: [MEXT] RFC3775 update - Simultaneous Mobility X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Jari, Thanks for your clarifications and questions. Some of these were discussed in the mailing list after we posted the initial (00) draft on February 18. We took into consideration some of the comments from Killien and others and updated the draft just before the IETF in PA. However, the revised version was not submitted to IETF. You can still find the revised draft that has taken into account some of those comments and slides at the following location. http://argreenhouse.com/IETF/draft-wong-mext-simultaneous-ps-00e.txt http://argreenhouse.com/IETF/wong-dutta-mext-ietf71.ppt Daniel and I discussed your questions and suggestions. Please see the answers inline. Jari Arkko wrote: > Ashutosh, > > I think something may need to be done with respect to this issue, but I > agree with Hesham that we are far from having the right text for it yet. > I'm still struggling with the definition of the problem, actually. > > There are a couple of issues that interact: > > 1) Mobile nodes cannot send traffic from their new care-of address > directly to a correspondent node before they have sent the RO BU to the > it (Section 11.3.1). This cannot happen before they have executed the > full return routability procedure. From this we can conclude that if > there is any data traffic to the correspondent node, it will have to go > through the correspondent node's home address and home agent. > Ans: We are describing a scenario where the mobile is already in a session using Route Optimized mode and then it moves. In this case RR (or BU) messages may not complete for reasons such as simultaneous mobility giving rise to data loss as the data will be sent to the old destination address. > 2) What is the reaction of the correspondent node when it receives > tunneled traffic? See Section 11.7.2. But return routability packets are > exempt from this rule. Ans> We are referring to unsuccessful RR procedure here not the data traffic. > > 3) Whether the usual RO rules for the destination apply to RR packets or > not; as far as I know there are no special rules for them. Ans> RR signaling is sent to the home agent of the destination (home address of the destination), rather than directly to the destination address (as applied for data traffic). This reduces the likelihood of lost messages due to simultaneous mobility, for instance, but does not eliminate the possibility. Killien actually raised this good point during the mailing list discussion and we addressed that in the revised version of the draft. I am just quoting some sentences from the draft here. "In reality, as a Mobility Header message, the binding update MUST NOT be sent to any care-of address that the Mobile Host might have for a mobile Correspondent Host, but must be sent to the permanent home address of the mobile Correspondent Host. This binding update can then be forwarded by the mobile Correspondent Host's home agent to its current location. Similarly, Care-of-Test Init (CTI) and Home-Test Init (HTI), when sent to a Correspondent Host that is also mobile, MUST NOT be sent to the care-of address for that Correspondent Host, but both go to the home address, and thus, are forwarded to the Correspondent Host by the home agent of the Correspondent Host. Thus, this serves as an in-built defense against the simultaneous mobility problem, since the home agent of the receiving host is involved. The defense, however, is only partial, because it needs the Home Agent registration of the receiving host to be successfully completed before the control message can be properly forwarded to the receiving host. Therefore, the interval of time in which the receiving Mobile Host is vulnerable to the simultaneous mobility problem is from when it transitions to interrupted state, until it can obtain a care-of address and complete successful home registration." The draft has a picture showing the occurrence of this specific scenario. > Did I miss anything? Based on the above, I have a few questions: > > - If we need to specify something new action on this, should this action > be triggered by (a) data traffic or (b) lack of response to RR packets? Ans> It should be triggered by lack of response to RR packets. > - Or is it simply wrong to attempt to do the signaling to the peer's > care-of address, maybe we should require doing it via the home address > instead? Ans> Yes, it is better to do it via the home address. This reduces the likelihood of lost messages due to simultaneous mobility, for instance, but does not eliminate the possibility, as we had discussed in the MEXT meeting in IETF 71 and illustrated in the revised draft. Please see the excerpt from the draft on this issue described above. > - Why is this issue specific to simultaneous movement? Wouldn't it > happen also if the peer rebooted and got a new address, as well? Ans> I think this problem could be applied to other scenarios that you have described as well. Also, it is a matter of timing. > Jari Regards Ashutosh _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 18 07:11:56 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B7A13A69A2; Wed, 18 Jun 2008 07:11:56 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E62B93A69A2 for ; Wed, 18 Jun 2008 07:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.422 X-Spam-Level: X-Spam-Status: No, score=-6.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSzSabQFG5pM for ; Wed, 18 Jun 2008 07:11:54 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 069AD3A67E2 for ; Wed, 18 Jun 2008 07:11:53 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m5IECe0P002755; Wed, 18 Jun 2008 09:12:40 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jun 2008 09:12:57 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jun 2008 09:12:57 -0500 Message-ID: <4859180E.7060101@ericsson.com> Date: Wed, 18 Jun 2008 10:13:34 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Julien Laganier References: <200806171443.46977.julien.IETF@laposte.net> In-Reply-To: <200806171443.46977.julien.IETF@laposte.net> X-OriginalArrivalTime: 18 Jun 2008 14:12:57.0685 (UTC) FILETIME=[688D8050:01C8D14D] Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of FW docs as MEXT WG drafts X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I support the adoption of these drafts as WG items. Cheers Suresh Julien Laganier wrote: > Folks, > > We are chartered to produce informational documents describing Mobile > IPv6 Operation with Firewalls but so far we have no corresponding WG > drafts. > > There are two individual submissions filling this hole together: > > - Guidelines for firewall vendors regarding MIPv6 traffic > > > -Guidelines for firewall administrators regarding MIPv6 traffic > > > They have been updated as per comments received during last IETF meeting > and we agreed we would ask for their adoption as WG drafts. Hereby we'd > like to request the WG participants to answer the following question: > > Shall the two drafts above be made WG drafts? > > Thank you for your support. > > --julien & marcelo, MEXT chairs. > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 18 07:57:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 424453A6AD6; Wed, 18 Jun 2008 07:57:53 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DA503A67E2 for ; Wed, 18 Jun 2008 07:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3T2K-6CkHWW for ; Wed, 18 Jun 2008 07:57:47 -0700 (PDT) Received: from web84315.mail.re1.yahoo.com (web84315.mail.re1.yahoo.com [69.147.74.194]) by core3.amsl.com (Postfix) with SMTP id 886EA3A6AD8 for ; Wed, 18 Jun 2008 07:57:01 -0700 (PDT) Received: (qmail 32370 invoked by uid 60001); 18 Jun 2008 14:57:49 -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=VmzLUWCE0wHj4W+2mTe7Zz1WTbhsnsgFNPwS2fz9dTppe9pAphCtaGnjMhYfSP1yE7UsPAHBNkR/j1P5WU48l++U8UuDdj4BCUE/Tx7V2XGsdUcmUaPRq4x8ByWzxm/sTj9ECq3hDcbEgH83sjdf+SxwKor2h57DfzATyCed2v0=; X-YMail-OSG: ciT6e64VM1ljvUmtEZCXRvgJHL38ZWsTSses5sMIurwLoD9MggxmFcPyubBATDvjruTbPDaknJPFx6_a46L0BX2jaXd7YoGKXW_scirqfq5y9WTZDiH5USc- Received: from [206.16.17.212] by web84315.mail.re1.yahoo.com via HTTP; Wed, 18 Jun 2008 07:57:48 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.185 Date: Wed, 18 Jun 2008 07:57:48 -0700 (PDT) From: Behcet Sarikaya To: Julien Laganier MIME-Version: 1.0 Message-ID: <133778.32333.qm@web84315.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 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="===============0990528865==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0990528865== Content-Type: multipart/alternative; boundary="0-923895519-1213801068=:32333" --0-923895519-1213801068=:32333 Content-Type: text/plain; charset=us-ascii Well, I was just wondering if its coauthors agree with this text ? Regards, Behcet ----- Original Message ---- From: Julien Laganier To: Behcet Sarikaya Cc: mext@ietf.org Sent: Wednesday, June 18, 2008 4:00:49 AM Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Behcet, I'm wondering what you're wondering about -- the message I sent (excerpt below) is quite explicit, isn't it? > We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as a > WG draft corresponding to the Nemo Prefix Delegation work item. > > Authors, please resubmit the draft as WG draft under the name: > > draft-ietf-mext-nemo-pd-00.txt --julien On Tuesday 17 June 2008, Behcet Sarikaya wrote: > Hi Julien, > It seems like draft-ietf-mext-nemo-pd-00.txt does not carry any > changes based on the long and heated debates we had on > draft-droms-mext-nemo-pd-00.txt. It is a keep-alive version. Is this > what you expected from the authors? > > Regards, > > Behcet > > > ----- Original Message ---- > From: Julien Laganier > To: draft-droms-mext-nemo-pd@tools.ietf.org > Cc: mext@ietf.org > Sent: Friday, June 13, 2008 10:42:14 AM > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > Folks, > > We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as a > WG draft corresponding to the Nemo Prefix Delegation work item. > > Authors, please resubmit the draft as WG draft under the name: > > draft-ietf-mext-nemo-pd-00.txt > > Note: you can use the online I-D submission tool to make it faster: > > > Thanks. > > --julien & marcelo, MEXT chairs. > > On Friday 30 May 2008, marcelo bagnulo braun wrote: > > Hi, > > > > We would like to ask the WG what is their opinion about accepting > > draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD > > deliverable included in our charter. > > > > Please provide comments so we cna make some progress on this long > > overdue deliverable > > > > thanks, Julien and marcelo > > > > -------- Mensaje original -------- > > Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt > > Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) > > De: Internet-Drafts@ietf.org > > Responder a: internet-drafts@ietf.org > > Para: i-d-announce@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : DHCPv6 Prefix Delegation for NEMO > > Author(s) : R. Droms, et al. > > Filename : draft-droms-mext-nemo-pd-00.txt > > Pages : 12 > > Date : 2008-05-30 > > > > One aspect of network mobility support is the assignment of a > > prefix or prefixes to a Mobile Router (MR) for use on the links in > > the Mobile Network. DHCPv6 prefix delegation can be used for this > > configuration task. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext --0-923895519-1213801068=:32333 Content-Type: text/html; charset=us-ascii
Well, I was just wondering if its coauthors agree with this text ?

Regards,

Behcet

----- Original Message ----
From: Julien Laganier <julien.IETF@laposte.net>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: mext@ietf.org
Sent: Wednesday, June 18, 2008 4:00:49 AM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

Behcet,

I'm wondering what you're wondering about -- the message I sent (excerpt
below) is quite explicit, isn't it?

> We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as a
> WG draft corresponding to the Nemo Prefix Delegation work item.
>
> Authors, please resubmit the draft as WG draft under the name:
>
>    draft-ietf-mext-nemo-pd-00.txt

--julien

On Tuesday 17 June 2008, Behcet Sarikaya wrote:
> Hi Julien,
>  It seems like draft-ietf-mext-nemo-pd-00.txt does not carry any
> changes based on the long and heated debates we had on
> draft-droms-mext-nemo-pd-00.txt. It is a keep-alive version. Is this
> what you expected from the authors?
>
> Regards,
>
> Behcet
>
>
> ----- Original Message ----
> From: Julien Laganier <julien.IETF@laposte.net>
> To: draft-droms-mext-nemo-pd@tools.ietf.org
> Cc: mext@ietf.org
> Sent: Friday, June 13, 2008 10:42:14 AM
> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?
>
> Folks,
>
> We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as a
> WG draft corresponding to the Nemo Prefix Delegation work item.
>
> Authors, please resubmit the draft as WG draft under the name:
>
>    draft-ietf-mext-nemo-pd-00.txt
>
> Note: you can use the online I-D submission tool to make it faster:
> <https://datatracker.ietf.org/idst/upload.cgi>
>
> Thanks.
>
> --julien & marcelo, MEXT chairs.
>
> On Friday 30 May 2008, marcelo bagnulo braun wrote:
> > Hi,
> >
> > We would like to ask the WG what is their opinion about accepting
> > draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD
> > deliverable included in our charter.
> >
> > Please provide comments so we cna make some progress on this long
> > overdue deliverable
> >
> > thanks, Julien and marcelo
> >
> > -------- Mensaje original --------
> > Asunto:    I-D Action:draft-droms-mext-nemo-pd-00.txt
> > Fecha:    Fri, 30 May 2008 05:45:01 -0700 (PDT)
> > De:    Internet-Drafts@ietf.org
> > Responder a:    internet-drafts@ietf.org
> > Para:    i-d-announce@ietf.org
> >
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >    Title          : DHCPv6 Prefix Delegation for NEMO
> >    Author(s)      : R. Droms, et al.
> >    Filename        : draft-droms-mext-nemo-pd-00.txt
> >    Pages          : 12
> >    Date            : 2008-05-30
> >
> > One aspect of network mobility support is the assignment of a
> > prefix or prefixes to a Mobile Router (MR) for use on the links in
> > the Mobile Network.  DHCPv6 prefix delegation can be used for this
> > configuration task.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext


--0-923895519-1213801068=:32333-- --===============0990528865== 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://www.ietf.org/mailman/listinfo/mext --===============0990528865==-- From mext-bounces@ietf.org Wed Jun 18 08:28:41 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B2628C122; Wed, 18 Jun 2008 08:28:41 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF3D3A6AE9 for ; Wed, 18 Jun 2008 08:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOKPlKsK0MPH for ; Wed, 18 Jun 2008 08:28:39 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by core3.amsl.com (Postfix) with ESMTP id B747C3A67E2 for ; Wed, 18 Jun 2008 08:28:38 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id y36so809875ugd.46 for ; Wed, 18 Jun 2008 08:29:25 -0700 (PDT) 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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:sender; bh=X33WYVKcfm880rlFD1b0RG0xn0hWoG0gaXKoAtbKlzM=; b=JO1kPlwdVK4wR96arN02ReYKBqTN9iyO7uUtEUGHwGXVAUxX1NrQ1eh6TU1P1ruGr1 3KTgazDbXcuFx01j/99YlIeRsKjVQ8SsjLZTY8m+z+egfqBOIhF6wH7E+YyanBGMF9hC 3DSl3lT4gyIOoxSdT2DSMjARz9dlB3e3QqHYs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id:sender; b=spyCQCzQhuvvFTFgX5wFdEQRsSmXiF5CHJWXHdk653VGsc+gZtYqyus++EJR6MTFzt I5f964WzpLHZPt5QP0gIdElDuaN1JNS0QuLhFJY986wbAyTaawGXneoplxrAnSlnR6F3 dxaOq7qG19gppuhbk9ojYor23i2zNSsBeEMIM= Received: by 10.210.91.7 with SMTP id o7mr690881ebb.197.1213802965836; Wed, 18 Jun 2008 08:29:25 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id t2sm14524607gve.9.2008.06.18.08.29.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Jun 2008 08:29:24 -0700 (PDT) From: Julien Laganier To: mext@ietf.org, Behcet Sarikaya Date: Wed, 18 Jun 2008 17:29:27 +0200 User-Agent: KMail/1.9.9 References: <133778.32333.qm@web84315.mail.re1.yahoo.com> In-Reply-To: <133778.32333.qm@web84315.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806181729.27599.julien.IETF@laposte.net> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Wednesday 18 June 2008, Behcet Sarikaya wrote: > Well, I was just wondering if its coauthors agree with this text ? Well, then I'm still wondering what you're wondering about... Are you asking whether or not coauthors of the draft agree with the draft?! --julien > ----- Original Message ---- > From: Julien Laganier > To: Behcet Sarikaya > Cc: mext@ietf.org > Sent: Wednesday, June 18, 2008 4:00:49 AM > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > Behcet, > > I'm wondering what you're wondering about -- the message I sent > (excerpt below) is quite explicit, isn't it? > > > We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as > > a WG draft corresponding to the Nemo Prefix Delegation work item. > > > > Authors, please resubmit the draft as WG draft under the name: > > > > draft-ietf-mext-nemo-pd-00.txt > > --julien > > On Tuesday 17 June 2008, Behcet Sarikaya wrote: > > Hi Julien, > > It seems like draft-ietf-mext-nemo-pd-00.txt does not carry any > > changes based on the long and heated debates we had on > > draft-droms-mext-nemo-pd-00.txt. It is a keep-alive version. Is > > this what you expected from the authors? > > > > Regards, > > > > Behcet > > > > > > ----- Original Message ---- > > From: Julien Laganier > > To: draft-droms-mext-nemo-pd@tools.ietf.org > > Cc: mext@ietf.org > > Sent: Friday, June 13, 2008 10:42:14 AM > > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > > > Folks, > > > > We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as > > a WG draft corresponding to the Nemo Prefix Delegation work item. > > > > Authors, please resubmit the draft as WG draft under the name: > > > > draft-ietf-mext-nemo-pd-00.txt > > > > Note: you can use the online I-D submission tool to make it faster: > > > > > > Thanks. > > > > --julien & marcelo, MEXT chairs. > > > > On Friday 30 May 2008, marcelo bagnulo braun wrote: > > > Hi, > > > > > > We would like to ask the WG what is their opinion about accepting > > > draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo > > > PD deliverable included in our charter. > > > > > > Please provide comments so we cna make some progress on this long > > > overdue deliverable > > > > > > thanks, Julien and marcelo > > > > > > -------- Mensaje original -------- > > > Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt > > > Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) > > > De: Internet-Drafts@ietf.org > > > Responder a: internet-drafts@ietf.org > > > Para: i-d-announce@ietf.org > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. > > > > > > Title : DHCPv6 Prefix Delegation for NEMO > > > Author(s) : R. Droms, et al. > > > Filename : draft-droms-mext-nemo-pd-00.txt > > > Pages : 12 > > > Date : 2008-05-30 > > > > > > One aspect of network mobility support is the assignment of a > > > prefix or prefixes to a Mobile Router (MR) for use on the links > > > in the Mobile Network. DHCPv6 prefix delegation can be used for > > > this configuration task. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.t > > >xt > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 18 08:32:58 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F38B128C122; Wed, 18 Jun 2008 08:32:57 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C9228C1CD for ; Wed, 18 Jun 2008 08:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Sv5vfUAFkdb for ; Wed, 18 Jun 2008 08:32:54 -0700 (PDT) Received: from web84308.mail.re1.yahoo.com (web84308.mail.re1.yahoo.com [69.147.74.187]) by core3.amsl.com (Postfix) with SMTP id DFDD03A6AD8 for ; Wed, 18 Jun 2008 08:32:49 -0700 (PDT) Received: (qmail 89927 invoked by uid 60001); 18 Jun 2008 15:33:37 -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=wzqM6Pps+U1w7OHYBlonqdwTISbISZWogk/XLcY1MpBxcDzLM1R2kU7BpTxxsxVit9IpXSGZAUkr5Ubtt32+2kDdazg5KJySifemmYrn435GChpI7eEGLRqqvZvQauk6YIR07WiZxlWFqAkxQotjacofe/ZxQw4fDNW4lestLpg=; X-YMail-OSG: cIdCT5gVM1kpUSk26wrhm3CpdIk48FKrI5PMJMT62vmdpGepbp.OyQmSE4Acttn7WJ2kD93Pn7cIUozF5KWvHMlx8pOWcbMpnV7ISwAqWzHVFsy9UdJOyLw- Received: from [206.16.17.212] by web84308.mail.re1.yahoo.com via HTTP; Wed, 18 Jun 2008 08:33:37 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.185 Date: Wed, 18 Jun 2008 08:33:37 -0700 (PDT) From: Behcet Sarikaya To: Julien Laganier MIME-Version: 1.0 Message-ID: <608210.87781.qm@web84308.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 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="===============0776659747==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0776659747== Content-Type: multipart/alternative; boundary="0-2136260916-1213803217=:87781" --0-2136260916-1213803217=:87781 Content-Type: text/plain; charset=us-ascii Yes. The reason is simple, look at this draft: http://tools.ietf.org/id/draft-dupont-mext-dhaadharmful-00.txt Regards, Behcet ----- Original Message ---- From: Julien Laganier To: mext@ietf.org; Behcet Sarikaya Sent: Wednesday, June 18, 2008 10:29:27 AM Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? On Wednesday 18 June 2008, Behcet Sarikaya wrote: > Well, I was just wondering if its coauthors agree with this text ? Well, then I'm still wondering what you're wondering about... Are you asking whether or not coauthors of the draft agree with the draft?! --julien > ----- Original Message ---- > From: Julien Laganier > To: Behcet Sarikaya > Cc: mext@ietf.org > Sent: Wednesday, June 18, 2008 4:00:49 AM > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > Behcet, > > I'm wondering what you're wondering about -- the message I sent > (excerpt below) is quite explicit, isn't it? > > > We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as > > a WG draft corresponding to the Nemo Prefix Delegation work item. > > > > Authors, please resubmit the draft as WG draft under the name: > > > > draft-ietf-mext-nemo-pd-00.txt > > --julien > > On Tuesday 17 June 2008, Behcet Sarikaya wrote: > > Hi Julien, > > It seems like draft-ietf-mext-nemo-pd-00.txt does not carry any > > changes based on the long and heated debates we had on > > draft-droms-mext-nemo-pd-00.txt. It is a keep-alive version. Is > > this what you expected from the authors? > > > > Regards, > > > > Behcet > > > > > > ----- Original Message ---- > > From: Julien Laganier > > To: draft-droms-mext-nemo-pd@tools.ietf.org > > Cc: mext@ietf.org > > Sent: Friday, June 13, 2008 10:42:14 AM > > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > > > Folks, > > > > We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as > > a WG draft corresponding to the Nemo Prefix Delegation work item. > > > > Authors, please resubmit the draft as WG draft under the name: > > > > draft-ietf-mext-nemo-pd-00.txt > > > > Note: you can use the online I-D submission tool to make it faster: > > > > > > Thanks. > > > > --julien & marcelo, MEXT chairs. > > > > On Friday 30 May 2008, marcelo bagnulo braun wrote: > > > Hi, > > > > > > We would like to ask the WG what is their opinion about accepting > > > draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo > > > PD deliverable included in our charter. > > > > > > Please provide comments so we cna make some progress on this long > > > overdue deliverable > > > > > > thanks, Julien and marcelo > > > > > > -------- Mensaje original -------- > > > Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt > > > Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) > > > De: Internet-Drafts@ietf.org > > > Responder a: internet-drafts@ietf.org > > > Para: i-d-announce@ietf.org > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. > > > > > > Title : DHCPv6 Prefix Delegation for NEMO > > > Author(s) : R. Droms, et al. > > > Filename : draft-droms-mext-nemo-pd-00.txt > > > Pages : 12 > > > Date : 2008-05-30 > > > > > > One aspect of network mobility support is the assignment of a > > > prefix or prefixes to a Mobile Router (MR) for use on the links > > > in the Mobile Network. DHCPv6 prefix delegation can be used for > > > this configuration task. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.t > > >xt > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext --0-2136260916-1213803217=:87781 Content-Type: text/html; charset=us-ascii
Yes. The reason is simple, look at this draft:
http://tools.ietf.org/id/draft-dupont-mext-dhaadharmful-00.txt

Regards,

Behcet

----- Original Message ----
From: Julien Laganier <julien.IETF@laposte.net>
To: mext@ietf.org; Behcet Sarikaya <sarikaya@ieee.org>
Sent: Wednesday, June 18, 2008 10:29:27 AM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

On Wednesday 18 June 2008, Behcet Sarikaya wrote:
> Well, I was just wondering if its coauthors agree with this text ?

Well, then I'm still wondering what you're wondering about... Are you
asking whether or not coauthors of the draft agree with the draft?!

--julien

> ----- Original Message ----
> From: Julien Laganier <julien.IETF@laposte.net>
> To: Behcet Sarikaya <sarikaya@ieee.org>
> Cc: mext@ietf.org
> Sent: Wednesday, June 18, 2008 4:00:49 AM
> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?
>
> Behcet,
>
> I'm wondering what you're wondering about -- the message I sent
> (excerpt below) is quite explicit, isn't it?
>
> > We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as
> > a WG draft corresponding to the Nemo Prefix Delegation work item.
> >
> > Authors, please resubmit the draft as WG draft under the name:
> >
> >    draft-ietf-mext-nemo-pd-00.txt
>
> --julien
>
> On Tuesday 17 June 2008, Behcet Sarikaya wrote:
> > Hi Julien,
> >  It seems like draft-ietf-mext-nemo-pd-00.txt does not carry any
> > changes based on the long and heated debates we had on
> > draft-droms-mext-nemo-pd-00.txt. It is a keep-alive version. Is
> > this what you expected from the authors?
> >
> > Regards,
> >
> > Behcet
> >
> >
> > ----- Original Message ----
> > From: Julien Laganier <julien.IETF@laposte.net>
> > To: draft-droms-mext-nemo-pd@tools.ietf.org
> > Cc: mext@ietf.org
> > Sent: Friday, June 13, 2008 10:42:14 AM
> > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?
> >
> > Folks,
> >
> > We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as
> > a WG draft corresponding to the Nemo Prefix Delegation work item.
> >
> > Authors, please resubmit the draft as WG draft under the name:
> >
> >    draft-ietf-mext-nemo-pd-00.txt
> >
> > Note: you can use the online I-D submission tool to make it faster:
> > <https://datatracker.ietf.org/idst/upload.cgi>
> >
> > Thanks.
> >
> > --julien & marcelo, MEXT chairs.
> >
> > On Friday 30 May 2008, marcelo bagnulo braun wrote:
> > > Hi,
> > >
> > > We would like to ask the WG what is their opinion about accepting
> > > draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo
> > > PD deliverable included in our charter.
> > >
> > > Please provide comments so we cna make some progress on this long
> > > overdue deliverable
> > >
> > > thanks, Julien and marcelo
> > >
> > > -------- Mensaje original --------
> > > Asunto:    I-D Action:draft-droms-mext-nemo-pd-00.txt
> > > Fecha:    Fri, 30 May 2008 05:45:01 -0700 (PDT)
> > > De:    Internet-Drafts@ietf.org
> > > Responder a:    internet-drafts@ietf.org
> > > Para:    i-d-announce@ietf.org
> > >
> > >
> > >
> > > A New Internet-Draft is available from the on-line
> > > Internet-Drafts directories.
> > >
> > >    Title          : DHCPv6 Prefix Delegation for NEMO
> > >    Author(s)      : R. Droms, et al.
> > >    Filename        : draft-droms-mext-nemo-pd-00.txt
> > >    Pages          : 12
> > >    Date            : 2008-05-30
> > >
> > > One aspect of network mobility support is the assignment of a
> > > prefix or prefixes to a Mobile Router (MR) for use on the links
> > > in the Mobile Network.  DHCPv6 prefix delegation can be used for
> > > this configuration task.
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.t
> > >xt
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > > Below is the data which will enable a MIME compliant mail reader
> > > implementation to automatically retrieve the ASCII version of the
> > > Internet-Draft.
> >
> > _______________________________________________
> > MEXT mailing list
> > MEXT@ietf.org
> > https://www.ietf.org/mailman/listinfo/mext


--0-2136260916-1213803217=:87781-- --===============0776659747== 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://www.ietf.org/mailman/listinfo/mext --===============0776659747==-- From mext-bounces@ietf.org Wed Jun 18 09:19:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E822F3A6A5C; Wed, 18 Jun 2008 09:19:43 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F48328C0F3 for ; Wed, 18 Jun 2008 09:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoaRz2+W2vnq for ; Wed, 18 Jun 2008 09:19:41 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by core3.amsl.com (Postfix) with ESMTP id 7A4A13A6800 for ; Wed, 18 Jun 2008 09:19:40 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id y36so819412ugd.46 for ; Wed, 18 Jun 2008 09:20:27 -0700 (PDT) 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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:sender; bh=0sB9MLqv3PVxHk/5HRwTSD/W7k0qSQ8i47FLPSDeb3w=; b=wvWi72CmcMKUkk/HYGana3r0u1fRR7vWTQSYg1K9rJ7uuM5YmTaIChnG72xo4KJ/aK fE3y/oJR4ll/3yC0DA6ut0IJ5QbPxJwcCneGGDnt6FCdnO+SivJwnHcaKYUqdXba67tE f7pwRrcuMsrzMZgd80t6TF8nVK49LFay7e5SU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id:sender; b=e8izLUuj0gu8oeS4QkJ/icDD+0SSEfecznMFTt3EqNGkTPqjkZdbgpXt3TYvP9bkJJ 0AJVm0TkAn18ofA/jx/9B0LytCnGuss8YvVt6b6/bXdc/EL3UQrVzWMsdXhlHr5rFKIe 4lqmSonJcy9v1584hwwT2h7ZVEb6Yk2gwO0W8= Received: by 10.210.121.8 with SMTP id t8mr772096ebc.67.1213806027725; Wed, 18 Jun 2008 09:20:27 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id m5sm14686010gve.3.2008.06.18.09.20.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Jun 2008 09:20:26 -0700 (PDT) From: Julien Laganier To: mext@ietf.org, Behcet Sarikaya Date: Wed, 18 Jun 2008 18:20:28 +0200 User-Agent: KMail/1.9.9 References: <608210.87781.qm@web84308.mail.re1.yahoo.com> In-Reply-To: <608210.87781.qm@web84308.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806181820.28262.julien.IETF@laposte.net> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Behcet, if that is your question, guess you should ask the authors, not me. --julien On Wednesday 18 June 2008, Behcet Sarikaya wrote: > Yes. The reason is simple, look at this draft: > http://tools.ietf.org/id/draft-dupont-mext-dhaadharmful-00.txt > > Regards, > > Behcet > > > ----- Original Message ---- > From: Julien Laganier > To: mext@ietf.org; Behcet Sarikaya > Sent: Wednesday, June 18, 2008 10:29:27 AM > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > On Wednesday 18 June 2008, Behcet Sarikaya wrote: > > Well, I was just wondering if its coauthors agree with this text ? > > Well, then I'm still wondering what you're wondering about... Are you > asking whether or not coauthors of the draft agree with the draft?! > > --julien > > > ----- Original Message ---- > > From: Julien Laganier > > To: Behcet Sarikaya > > Cc: mext@ietf.org > > Sent: Wednesday, June 18, 2008 4:00:49 AM > > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > > > Behcet, > > > > I'm wondering what you're wondering about -- the message I sent > > (excerpt below) is quite explicit, isn't it? > > > > > We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt > > > as a WG draft corresponding to the Nemo Prefix Delegation work > > > item. > > > > > > Authors, please resubmit the draft as WG draft under the name: > > > > > > draft-ietf-mext-nemo-pd-00.txt > > > > --julien > > > > On Tuesday 17 June 2008, Behcet Sarikaya wrote: > > > Hi Julien, > > > It seems like draft-ietf-mext-nemo-pd-00.txt does not carry any > > > changes based on the long and heated debates we had on > > > draft-droms-mext-nemo-pd-00.txt. It is a keep-alive version. Is > > > this what you expected from the authors? > > > > > > Regards, > > > > > > Behcet > > > > > > > > > ----- Original Message ---- > > > From: Julien Laganier > > > To: draft-droms-mext-nemo-pd@tools.ietf.org > > > Cc: mext@ietf.org > > > Sent: Friday, June 13, 2008 10:42:14 AM > > > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > > > > > Folks, > > > > > > We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt > > > as a WG draft corresponding to the Nemo Prefix Delegation work > > > item. > > > > > > Authors, please resubmit the draft as WG draft under the name: > > > > > > draft-ietf-mext-nemo-pd-00.txt > > > > > > Note: you can use the online I-D submission tool to make it > > > faster: > > > > > > Thanks. > > > > > > --julien & marcelo, MEXT chairs. > > > > > > On Friday 30 May 2008, marcelo bagnulo braun wrote: > > > > Hi, > > > > > > > > We would like to ask the WG what is their opinion about > > > > accepting draft-droms-mext-nemo-pd-00.txt as the WG document > > > > for the Nemo PD deliverable included in our charter. > > > > > > > > Please provide comments so we cna make some progress on this > > > > long overdue deliverable > > > > > > > > thanks, Julien and marcelo > > > > > > > > -------- Mensaje original -------- > > > > Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt > > > > Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) > > > > De: Internet-Drafts@ietf.org > > > > Responder a: internet-drafts@ietf.org > > > > Para: i-d-announce@ietf.org > > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > Internet-Drafts directories. > > > > > > > > Title : DHCPv6 Prefix Delegation for NEMO > > > > Author(s) : R. Droms, et al. > > > > Filename : draft-droms-mext-nemo-pd-00.txt > > > > Pages : 12 > > > > Date : 2008-05-30 > > > > > > > > One aspect of network mobility support is the assignment of a > > > > prefix or prefixes to a Mobile Router (MR) for use on the links > > > > in the Mobile Network. DHCPv6 prefix delegation can be used > > > > for this configuration task. > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00 > > > >.t xt > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > Below is the data which will enable a MIME compliant mail > > > > reader implementation to automatically retrieve the ASCII > > > > version of the Internet-Draft. > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 18 11:15:59 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24EFA28C1DB; Wed, 18 Jun 2008 11:15:59 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32F9828C1DB for ; Wed, 18 Jun 2008 11:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdTqa58hEhQM for ; Wed, 18 Jun 2008 11:15:57 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 6AA2228C1D6 for ; Wed, 18 Jun 2008 11:15:57 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so5644450rvf.49 for ; Wed, 18 Jun 2008 11:16:43 -0700 (PDT) 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=2o8tuMkTRZTiS1CinfWmNX9PxdaWNrNgbAwuA643mbI=; b=cenwuZnfN3yHyQTQXD51O409/cKf/3kqc3US9dDmwbi8oTL3AWCEruWCgoq0KZoXtK KusckQSvErs6xuRSebNBAyebUmB7j7iY/zbXnotW/26yDu4IxWgYuH9ZB08T5SY+F46B zEfLX2dd8YTkqdKtSTrNk0hcdA3VA1dAUAe3Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=eUg/wOTp/AiaBGWDxMemCcNztr3aDIYv936KsS/UMIjtSEXbmf/pqmwfYyQ1h2haxw Qqk+FPXkIhZdWwAGKL8hwn/5naNcYmhe//DxR8cfL+YqQ/qeygRbrjbhThGlJoDI76Qw uc+kzdECsVydPpcl+fPxyz9TJE8n1Z0UNrRBU= Received: by 10.140.133.9 with SMTP id g9mr5673176rvd.235.1213813003646; Wed, 18 Jun 2008 11:16:43 -0700 (PDT) Received: by 10.141.189.15 with HTTP; Wed, 18 Jun 2008 11:16:43 -0700 (PDT) Message-ID: <729b68be0806181116w40985f20rb6580da10edd0705@mail.gmail.com> Date: Wed, 18 Jun 2008 20:16:43 +0200 From: "Jean-Michel Combes" To: "Julien Laganier" In-Reply-To: <200806171443.46977.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline References: <200806171443.46977.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of FW docs as MEXT WG drafts X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, it's OK for me these two drafts become WG drafts. Best regards. JMC. 2008/6/17, Julien Laganier : > Folks, > > We are chartered to produce informational documents describing Mobile > IPv6 Operation with Firewalls but so far we have no corresponding WG > drafts. > > There are two individual submissions filling this hole together: > > - Guidelines for firewall vendors regarding MIPv6 traffic > > > -Guidelines for firewall administrators regarding MIPv6 traffic > > > They have been updated as per comments received during last IETF meeting > and we agreed we would ask for their adoption as WG drafts. Hereby we'd > like to request the WG participants to answer the following question: > > Shall the two drafts above be made WG drafts? > > Thank you for your support. > > --julien & marcelo, MEXT chairs. > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 18 12:41:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2913A6A32; Wed, 18 Jun 2008 12:41:29 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 866323A6A32 for ; Wed, 18 Jun 2008 12:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrkRy6dDdqJx for ; Wed, 18 Jun 2008 12:41:27 -0700 (PDT) Received: from web84301.mail.re1.yahoo.com (web84301.mail.re1.yahoo.com [69.147.74.180]) by core3.amsl.com (Postfix) with SMTP id 1ACBE3A69D1 for ; Wed, 18 Jun 2008 12:41:27 -0700 (PDT) Received: (qmail 39895 invoked by uid 60001); 18 Jun 2008 19:42:15 -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=W9u8WReFh2Nqf7KV6MhY2i507vtezxn7vxZ0OirHJF+x5EH4Tr9fNBwQltSy/v3Yp06sdfKx+KrBrBonzIhEZy6YsNld0kEztV+A9jGE+XpTQx+ffSwRdbdTSIGUnB954Y0HgNySxUF8h2UdvxFk50NKQRJ7N5VBmf6xKsv4izA=; X-YMail-OSG: kMEG51wVM1mOt32412gt4rnGlHVPML6F_6_CZC.rLetGaSJhX7Wct0Xv7BKbtraiDQ-- Received: from [206.16.17.212] by web84301.mail.re1.yahoo.com via HTTP; Wed, 18 Jun 2008 12:42:15 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.185 Date: Wed, 18 Jun 2008 12:42:15 -0700 (PDT) From: Behcet Sarikaya To: Julien Laganier MIME-Version: 1.0 Message-ID: <120808.39139.qm@web84301.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of FW docs as MEXT WG drafts X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 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="===============0485755512==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0485755512== Content-Type: multipart/alternative; boundary="0-41111534-1213818135=:39139" --0-41111534-1213818135=:39139 Content-Type: text/plain; charset=us-ascii +1 ----- Original Message ---- From: Jean-Michel Combes To: Julien Laganier Cc: mext@ietf.org Sent: Wednesday, June 18, 2008 1:16:43 PM Subject: Re: [MEXT] Adoption of FW docs as MEXT WG drafts Hi, it's OK for me these two drafts become WG drafts. Best regards. JMC. 2008/6/17, Julien Laganier : > Folks, > > We are chartered to produce informational documents describing Mobile > IPv6 Operation with Firewalls but so far we have no corresponding WG > drafts. > > There are two individual submissions filling this hole together: > > - Guidelines for firewall vendors regarding MIPv6 traffic > > > -Guidelines for firewall administrators regarding MIPv6 traffic > > > They have been updated as per comments received during last IETF meeting > and we agreed we would ask for their adoption as WG drafts. Hereby we'd > like to request the WG participants to answer the following question: > > Shall the two drafts above be made WG drafts? > > Thank you for your support. > > --julien & marcelo, MEXT chairs. > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-41111534-1213818135=:39139 Content-Type: text/html; charset=us-ascii

+1
----- Original Message ----
From: Jean-Michel Combes <jeanmichel.combes@gmail.com>
To: Julien Laganier <julien.IETF@laposte.net>
Cc: mext@ietf.org
Sent: Wednesday, June 18, 2008 1:16:43 PM
Subject: Re: [MEXT] Adoption of FW docs as MEXT WG drafts

Hi,

it's OK for me these two drafts become WG drafts.

Best regards.

JMC.


2008/6/17, Julien Laganier <julien.IETF@laposte.net>:
> Folks,
>
>  We are chartered to produce informational documents describing Mobile
>  IPv6 Operation with Firewalls but so far we have no corresponding WG
>  drafts.
>
>  There are two individual submissions filling this hole together:
>
>  - Guidelines for firewall vendors regarding MIPv6 traffic
>  <http://www.ietf.org/internet-drafts/draft-krishnan-mip6-firewall-admin-04.txt>
>
>  -Guidelines for firewall administrators regarding MIPv6 traffic
>  <http://www.ietf.org/internet-drafts/draft-krishnan-mip6-firewall-admin-04.txt>
>
>  They have been updated as per comments received during last IETF meeting
>  and we agreed we would ask for their adoption as WG drafts. Hereby we'd
>  like to request the WG participants to answer the following question:
>
>  Shall the two drafts above be made WG drafts?
>
>  Thank you for your support.
>
>  --julien & marcelo, MEXT chairs.
>  _______________________________________________
>  MEXT mailing list
>  MEXT@ietf.org
>  https://www.ietf.org/mailman/listinfo/mext
>
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
--0-41111534-1213818135=:39139-- --===============0485755512== 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://www.ietf.org/mailman/listinfo/mext --===============0485755512==-- From mext-bounces@ietf.org Wed Jun 18 14:09:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6F543A6B7C; Wed, 18 Jun 2008 14:09:00 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E76CA3A6B7C for ; Wed, 18 Jun 2008 14:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PB3URF7J1KZp for ; Wed, 18 Jun 2008 14:08:59 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id CC7793A6AEC for ; Wed, 18 Jun 2008 14:08:58 -0700 (PDT) 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 m5IL9gH02979; Wed, 18 Jun 2008 21:09:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jun 2008 16:09:38 -0500 Message-ID: In-Reply-To: <200806171443.46977.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Adoption of FW docs as MEXT WG drafts Thread-Index: AcjQd9ZBPT2XLR6VTMiCINSaqcyShABD3EHg References: <200806171443.46977.julien.IETF@laposte.net> From: "Ahmad Muhanna" To: "Julien Laganier" , Subject: Re: [MEXT] Adoption of FW docs as MEXT WG drafts X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, I support these two drafts as wg docs. Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: Tuesday, June 17, 2008 7:44 AM > To: mext@ietf.org > Subject: [MEXT] Adoption of FW docs as MEXT WG drafts > > Folks, > > We are chartered to produce informational documents describing Mobile > IPv6 Operation with Firewalls but so far we have no > corresponding WG drafts. > > There are two individual submissions filling this hole together: > > - Guidelines for firewall vendors regarding MIPv6 traffic > > > -Guidelines for firewall administrators regarding MIPv6 > traffic > > > They have been updated as per comments received during last > IETF meeting and we agreed we would ask for their adoption as > WG drafts. Hereby we'd like to request the WG participants to > answer the following question: > > Shall the two drafts above be made WG drafts? > > Thank you for your support. > > --julien & marcelo, MEXT chairs. > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 19 04:21:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C4503A6990; Thu, 19 Jun 2008 04:21:03 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57DC93A6A76 for ; Thu, 19 Jun 2008 04:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7CfO-+Ea0am for ; Thu, 19 Jun 2008 04:21:00 -0700 (PDT) Received: from kafka.verkstad.net (kafka.verkstad.net [192.71.20.153]) by core3.amsl.com (Postfix) with ESMTP id 565F03A67F8 for ; Thu, 19 Jun 2008 04:21:00 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id B8792710AE4; Thu, 19 Jun 2008 13:21:49 +0200 (CEST) Date: Thu, 19 Jun 2008 13:21:49 +0200 From: Michael Eriksson To: mext@ietf.org Message-ID: <20080619112149.GA1915@kafka.verkstad.net> Mime-Version: 1.0 Content-Disposition: inline Subject: [MEXT] New MIPv6 flow routing draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Tjupp! I have just submitted draft-eriksson-mext-mipv6-routing-rules-00. It describes how to do flow routing for mobile nodes with multiple CoA registrations, by applying the generic flow distribution language in draft-larsson-mext-flow-distribution-rules-00 to MIPv6. It uses a new signaling mechanism, which separates rule updates from the handover management, and gives the possibility to send rules in a bidirectional manner (both MN->HA and HA->MN). We think that these are major and necessary advantages compared to existing solutions. The draft also shows a real-life use of the new MIPv6 Generic Signaling Messages (previously Generic Notification Messages). It introduces some suggestions for MGSMs: - Reserve some of the rejection code space in Acknowledgements for per request type codes, for example codes 192-255. - MN-CN signaling must also be protected. - Maybe we will need a way to increase the maximum size of MGSM above its current 2048 octet limit (which is inherited from HM). Feedback is very welcome! (We are entering the vacation season, so there may be some delay in responding.) Regards, Michael _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 19 09:04:01 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 660373A677C; Thu, 19 Jun 2008 09:04:01 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2E303A677C for ; Thu, 19 Jun 2008 09:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nm6zgzUPLPqh for ; Thu, 19 Jun 2008 09:03:59 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id BA84A3A66B4 for ; Thu, 19 Jun 2008 09:03:59 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id ED8CA1986FA; Thu, 19 Jun 2008 19:04:49 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 945E1198671; Thu, 19 Jun 2008 19:04:49 +0300 (EEST) Message-ID: <485A83CF.9010000@piuha.net> Date: Thu, 19 Jun 2008 19:05:35 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: draft-ietf-mext-aaa-ha-goals@tools.ietf.org References: <48450C23.2080004@it.uc3m.es> In-Reply-To: <48450C23.2080004@it.uc3m.es> X-Virus-Scanned: ClamAV using ClamSMTP Cc: Pasi Eronen , dime-chairs@tools.ietf.org, "mext@ietf.org" Subject: [MEXT] AD review of draft-ietf-mext-aaa-ha-goals-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I have done my AD review on this document. The document is ready to move forward, but I wanted to note something regarding requirement G2.12. This requirement says that it must be possible to support IKEv2 shared secret authentication. I can see some good and bad ways of implementing this in terms of the solutions. Is the solution already in some document? I think we want to pay close attention to how this requirement is fulfilled and make sure the architecture is right. (Sending keys vs. specific keys for this HA vs. asking the server to calculate an authentication value, binding of access keys to things that go across accesses, mandatory vs. optional confidentiality of transported keys, etc.) I will ask for early security review on the solutions. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 19 09:11:30 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E3BC3A67CF; Thu, 19 Jun 2008 09:11:30 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72A9D3A67CF for ; Thu, 19 Jun 2008 09:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4WwwBH7QyEX for ; Thu, 19 Jun 2008 09:11:28 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 43AB03A66B4 for ; Thu, 19 Jun 2008 09:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1213891939; x=1245427939; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:references:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20AD=20review=20of =20draft-ietf-mext-aaa-ha-goals-01|Date:=20Thu,=2019=20Ju n=202008=2009:12:11=20-0700|Message-ID:=20 |In-Reply-To:=20<485A83CF.9010000@piuha.net> |X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20[MEXT]=20AD=20review=20of=20draft-ietf-m ext-aaa-ha-goals-01|Thread-Index:=20AcjSJkQLVkHOjQ4eRhCLT 2XLNSZx1gAAD/Zg|References:=20<48450C23.2080004@it.uc3m.e s>=20<485A83CF.9010000@piuha.net>|From:=20"Giaretta,=20Ge rardo"=20|To:=20"Jari=20Arkko"=20< jari.arkko@piuha.net>,=0D=0A=20=20=20=20=20=20=20=20|Cc:=20"Pasi=20Er onen"=20,=20,=0D=0A=20=20=20=20=20=20=20=20 |X-OriginalArrivalTime:=2019=20Jun=202008=2016:12:14.0405 =20(UTC)=20FILETIME=3D[3CB40F50:01C8D227]|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5200,2160,5320"=3B=20a=3D"4063011"; bh=Ievz5w+Hi0MI6qXE5iUPBRUDEjVaiz8udEXm677l+CQ=; b=VaRzO4IBFHv5/PV40xkArrsnFmHNZsi8czPttYhxr3VzCdV7aUd2sOFj whvdzhPEizWrwA2+NC0hVHnISfTj+CA8tugrAPcIDmPhOrszqJsAopYM9 ADEDKpb2Ed3CFpr5G+UmiOJKZSOgEiQ1x1Z9HnFaLhQmhrf6gees+dlcY 8=; X-IronPort-AV: E=McAfee;i="5200,2160,5320"; a="4063011" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jun 2008 09:12:15 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m5JGCFk0016916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Jun 2008 09:12:15 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m5JGCE94027466; Thu, 19 Jun 2008 09:12:14 -0700 (PDT) Received: from NAEX12.na.qualcomm.com ([129.46.51.247]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Jun 2008 09:12:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jun 2008 09:12:11 -0700 Message-ID: In-Reply-To: <485A83CF.9010000@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] AD review of draft-ietf-mext-aaa-ha-goals-01 Thread-Index: AcjSJkQLVkHOjQ4eRhCLT2XLNSZx1gAAD/Zg References: <48450C23.2080004@it.uc3m.es> <485A83CF.9010000@piuha.net> From: "Giaretta, Gerardo" To: "Jari Arkko" , X-OriginalArrivalTime: 19 Jun 2008 16:12:14.0405 (UTC) FILETIME=[3CB40F50:01C8D227] Cc: Pasi Eronen , dime-chairs@tools.ietf.org, mext@ietf.org Subject: Re: [MEXT] AD review of draft-ietf-mext-aaa-ha-goals-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Jari, Thanks for the review. Concerning the solution, it is specified in http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-09.txt Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Jari Arkko > Sent: Thursday, June 19, 2008 9:06 AM > To: draft-ietf-mext-aaa-ha-goals@tools.ietf.org > Cc: Pasi Eronen; dime-chairs@tools.ietf.org; mext@ietf.org > Subject: [MEXT] AD review of draft-ietf-mext-aaa-ha-goals-01 > > I have done my AD review on this document. > > The document is ready to move forward, but I wanted to note something > regarding requirement G2.12. > > This requirement says that it must be possible to support IKEv2 shared > secret authentication. I can see some good and bad ways of implementing > this in terms of the solutions. Is the solution already in some document? > > I think we want to pay close attention to how this requirement is > fulfilled and make sure the architecture is right. (Sending keys vs. > specific keys for this HA vs. asking the server to calculate an > authentication value, binding of access keys to things that go across > accesses, mandatory vs. optional confidentiality of transported keys, > etc.) I will ask for early security review on the solutions. > > Jari > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 19 09:18:10 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C785628C1E5; Thu, 19 Jun 2008 09:18:10 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFDCC28C1DB for ; Thu, 19 Jun 2008 09:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.415 X-Spam-Level: X-Spam-Status: No, score=-3.415 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AN-ugDO6U7Hk for ; Thu, 19 Jun 2008 09:18:09 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id DB04928C11F for ; Thu, 19 Jun 2008 09:18:08 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (74.pool85-53-142.dynamic.orange.es [85.53.142.74])by smtp01.uc3m.es (Postfix) with ESMTP id E98716EEC0E; Thu, 19 Jun 2008 18:18:57 +0200 (CEST) Message-ID: <485A86E6.3030605@it.uc3m.es> Date: Thu, 19 Jun 2008 18:18:46 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Jari Arkko References: <48450C23.2080004@it.uc3m.es> <485A83CF.9010000@piuha.net> In-Reply-To: <485A83CF.9010000@piuha.net> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-18.1225 TC:1F TRN:35 TV:5.5.1026(15982.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) Cc: Pasi Eronen , dime-chairs@tools.ietf.org, draft-ietf-mext-aaa-ha-goals@tools.ietf.org, "mext@ietf.org" Subject: Re: [MEXT] AD review of draft-ietf-mext-aaa-ha-goals-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Jari, thanks for the feedback just to make sure, is there something you want us (either the MEXT WG or = the editors of the document) to do about this? regards, marcelo Jari Arkko escribi=F3: > I have done my AD review on this document. > > The document is ready to move forward, but I wanted to note something = > regarding requirement G2.12. > > This requirement says that it must be possible to support IKEv2 shared = > secret authentication. I can see some good and bad ways of implementing = > this in terms of the solutions. Is the solution already in some document? > > I think we want to pay close attention to how this requirement is = > fulfilled and make sure the architecture is right. (Sending keys vs. = > specific keys for this HA vs. asking the server to calculate an = > authentication value, binding of access keys to things that go across = > accesses, mandatory vs. optional confidentiality of transported keys, = > etc.) I will ask for early security review on the solutions. > > Jari > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 19 09:24:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58CE3A6940; Thu, 19 Jun 2008 09:24:53 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2131D3A6927 for ; Thu, 19 Jun 2008 09:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCpRY31VsJBW for ; Thu, 19 Jun 2008 09:24:48 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 2A7C13A690A for ; Thu, 19 Jun 2008 09:24:48 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id C6DE71986FA; Thu, 19 Jun 2008 19:25:38 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 64CE5198671; Thu, 19 Jun 2008 19:25:38 +0300 (EEST) Message-ID: <485A88B0.9080601@piuha.net> Date: Thu, 19 Jun 2008 19:26:24 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: marcelo bagnulo braun References: <48450C23.2080004@it.uc3m.es> <485A83CF.9010000@piuha.net> <485A86E6.3030605@it.uc3m.es> In-Reply-To: <485A86E6.3030605@it.uc3m.es> X-Virus-Scanned: ClamAV using ClamSMTP Cc: Pasi Eronen , dime-chairs@tools.ietf.org, draft-ietf-mext-aaa-ha-goals@tools.ietf.org, "mext@ietf.org" Subject: Re: [MEXT] AD review of draft-ietf-mext-aaa-ha-goals-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > just to make sure, is there something you want us (either the MEXT WG > or the editors of the document) to do about this? You should follow-up with security ADs (Cced) to make sure the review is happening. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 19 11:05:57 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD683A6A6F; Thu, 19 Jun 2008 11:05:57 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6E52C3A6A2C; Thu, 19 Jun 2008 11:05:56 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20080619180556.6E52C3A6A2C@core3.amsl.com> Date: Thu, 19 Jun 2008 11:05:56 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] Last Call: draft-ietf-mext-aaa-ha-goals (AAA Goals for Mobile IPv6) to Informational RFC X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org The IESG has received a request from the Mobility EXTensions for IPv6 WG (mext) to consider the following document: - 'AAA Goals for Mobile IPv6 ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-07-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mext-aaa-ha-goals-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16827&rfc_flag=0 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 20 00:29:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29F603A6983; Fri, 20 Jun 2008 00:29:16 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6667E3A6983 for ; Fri, 20 Jun 2008 00:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7knMLUMw1ZA for ; Fri, 20 Jun 2008 00:29:09 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9614A3A6904 for ; Fri, 20 Jun 2008 00:29:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,678,1204498800"; d="scan'208,217";a="12198814" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2008 09:29:02 +0200 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 m5K7T22t011609; Fri, 20 Jun 2008 09:29:02 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5K7T2g7015154; Fri, 20 Jun 2008 07:29:02 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jun 2008 09:29:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Jun 2008 09:28:25 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05DC3DE2@xmb-ams-337.emea.cisco.com> In-Reply-To: <608210.87781.qm@web84308.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Thread-Index: AcjRWMl3c2XQcjPfQ/O4sOqAfROytwBThYkQ References: <608210.87781.qm@web84308.mail.re1.yahoo.com> From: "Pascal Thubert (pthubert)" To: "Behcet Sarikaya" , "Julien Laganier" X-OriginalArrivalTime: 20 Jun 2008 07:29:02.0101 (UTC) FILETIME=[4FD85C50:01C8D2A7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17287; t=1213946942; x=1214810942; 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]=20Adoption=20of=20draft-droms-me xt-nemo-pd-00.txt? |Sender:=20; bh=fRttAm0nYoYfj2cRQmbR8BZUIIcssDd7SqfrjZx9v78=; b=OWOKc9jjbClq9386hWr4hhsu9V5HF31rwuoMCTevaM1VydBS3npcdb153g 8sS+0CV1O4gIjNen/66Q60F73jhJ5dJEyvc24ZFBTh8Jk/ArHStOhsgnOHTE HT510albRc; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2133988433==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============2133988433== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D2A7.4F9A1E27" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D2A7.4F9A1E27 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Behcet =20 The PD draft is consistent with its parent RFCs 3775 and 3963. If the group agrees in some future that DHAAD should be deprecated, then we'll need to revise all 3 documents. What's important IMHO is to keep them consistent. =20 Pascal ________________________________ From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: mercredi 18 juin 2008 17:34 To: Julien Laganier Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? =20 Yes. The reason is simple, look at this draft: http://tools.ietf.org/id/draft-dupont-mext-dhaadharmful-00.txt Regards, Behcet ----- Original Message ---- From: Julien Laganier To: mext@ietf.org; Behcet Sarikaya Sent: Wednesday, June 18, 2008 10:29:27 AM Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? On Wednesday 18 June 2008, Behcet Sarikaya wrote: > Well, I was just wondering if its coauthors agree with this text ? Well, then I'm still wondering what you're wondering about... Are you=20 asking whether or not coauthors of the draft agree with the draft?!=20 --julien > ----- Original Message ---- > From: Julien Laganier > To: Behcet Sarikaya > Cc: mext@ietf.org > Sent: Wednesday, June 18, 2008 4:00:49 AM > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > Behcet, > > I'm wondering what you're wondering about -- the message I sent > (excerpt below) is quite explicit, isn't it? > > > We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as > > a WG draft corresponding to the Nemo Prefix Delegation work item. > > > > Authors, please resubmit the draft as WG draft under the name: > > > > draft-ietf-mext-nemo-pd-00.txt > > --julien > > On Tuesday 17 June 2008, Behcet Sarikaya wrote: > > Hi Julien, > > It seems like draft-ietf-mext-nemo-pd-00.txt does not carry any > > changes based on the long and heated debates we had on > > draft-droms-mext-nemo-pd-00.txt. It is a keep-alive version. Is > > this what you expected from the authors? > > > > Regards, > > > > Behcet > > > > > > ----- Original Message ---- > > From: Julien Laganier > > To: draft-droms-mext-nemo-pd@tools.ietf.org > > Cc: mext@ietf.org > > Sent: Friday, June 13, 2008 10:42:14 AM > > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > > > Folks, > > > > We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as > > a WG draft corresponding to the Nemo Prefix Delegation work item. > > > > Authors, please resubmit the draft as WG draft under the name: > > > > draft-ietf-mext-nemo-pd-00.txt > > > > Note: you can use the online I-D submission tool to make it faster: > > > > > > Thanks. > > > > --julien & marcelo, MEXT chairs. > > > > On Friday 30 May 2008, marcelo bagnulo braun wrote: > > > Hi, > > > > > > We would like to ask the WG what is their opinion about accepting > > > draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo > > > PD deliverable included in our charter. > > > > > > Please provide comments so we cna make some progress on this long > > > overdue deliverable > > > > > > thanks, Julien and marcelo > > > > > > -------- Mensaje original -------- > > > Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt > > > Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) > > > De: Internet-Drafts@ietf.org > > > Responder a: internet-drafts@ietf.org > > > Para: i-d-announce@ietf.org > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. > > > > > > Title : DHCPv6 Prefix Delegation for NEMO > > > Author(s) : R. Droms, et al. > > > Filename : draft-droms-mext-nemo-pd-00.txt > > > Pages : 12 > > > Date : 2008-05-30 > > > > > > One aspect of network mobility support is the assignment of a > > > prefix or prefixes to a Mobile Router (MR) for use on the links > > > in the Mobile Network. DHCPv6 prefix delegation can be used for > > > this configuration task. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.t > > >xt > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext ------_=_NextPart_001_01C8D2A7.4F9A1E27 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Behcet

 

The PD draft is consistent with its = parent RFCs 3775 and 3963. If the group agrees in some future that DHAAD should = be deprecated, then we’ll need to revise all 3 documents. = What’s important IMHO is to keep them consistent.

 

Pascal

From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Behcet = Sarikaya
Sent: mercredi 18 juin = 2008 17:34
To: Julien Laganier
Cc: mext@ietf.org
Subject: Re: [MEXT] = Adoption of draft-droms-mext-nemo-pd-00.txt?

 

Yes. The = reason is simple, look at this draft:
http://tools.ietf.org/id/draft-dupont-mext-dhaadharmful-00.txt

Regards,

Behcet

----- Original = Message ----
From: Julien Laganier <julien.IETF@laposte.net>
To: mext@ietf.org; Behcet = Sarikaya <sarikaya@ieee.org>
Sent: Wednesday, June 18, 2008 10:29:27 AM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

On Wednesday 18 June 2008, Behcet = Sarikaya wrote:
> Well, I was just wondering if its coauthors agree with this text = ?

Well, then I'm still wondering what you're wondering about... Are you =
asking whether or not coauthors of the draft agree with the draft?!

--julien

> ----- Original Message ----
> From: Julien Laganier <julien.IETF@laposte.net>= ;
> To: Behcet Sarikaya = <sarikaya@ieee.org>
> Cc: mext@ietf.org
> Sent: Wednesday, June 18, 2008 4:00:49 AM
> Subject: Re: [MEXT] Adoption of = draft-droms-mext-nemo-pd-00.txt?
>
> Behcet,
>
> I'm wondering what you're wondering about -- the message I sent
> (excerpt below) is quite explicit, isn't it?
>
> > We have a WG consensus to adopt = draft-droms-mext-nemo-pd-00.txt as
> > a WG draft corresponding to the Nemo Prefix Delegation work = item.
> >
> > Authors, please resubmit the draft as WG draft under the = name:
> >
> >    draft-ietf-mext-nemo-pd-00.txt
>
> --julien
>
> On Tuesday 17 June 2008, Behcet = Sarikaya wrote:
> > Hi Julien,
> >  It seems like draft-ietf-mext-nemo-pd-00.txt does not = carry any
> > changes based on the long and heated debates we had on
> > draft-droms-mext-nemo-pd-00.txt. It is a keep-alive version. = Is
> > this what you expected from the authors?
> >
> > Regards,
> >
> > Behcet
> >
> >
> > ----- Original Message ----
> > From: Julien Laganier <julien.IETF@laposte.net>= ;
> > To: draft-droms-me= xt-nemo-pd@tools.ietf.org
> > Cc: mext@ietf.org
> > Sent: Friday, June 13, 2008 10:42:14 AM
> > Subject: Re: [MEXT] Adoption of = draft-droms-mext-nemo-pd-00.txt?
> >
> > Folks,
> >
> > We have a WG consensus to adopt = draft-droms-mext-nemo-pd-00.txt as
> > a WG draft corresponding to the Nemo Prefix Delegation work = item.
> >
> > Authors, please resubmit the draft as WG draft under the = name:
> >
> >    draft-ietf-mext-nemo-pd-00.txt
> >
> > Note: you can use the online I-D submission tool to make it = faster:
> > <https://datatracker.ietf.org/idst/upload.cgi> > >
> > Thanks.
> >
> > --julien & marcelo, MEXT chairs.
> >
> > On Friday 30 May 2008, marcelo bagnulo braun wrote:
> > > Hi,
> > >
> > > We would like to ask the WG what is their opinion about accepting
> > > draft-droms-mext-nemo-pd-00.txt as the WG document for = the Nemo
> > > PD deliverable included in our charter.
> > >
> > > Please provide comments so we cna make some progress on = this long
> > > overdue deliverable
> > >
> > > thanks, Julien and marcelo
> > >
> > > -------- Mensaje original --------
> > > Asunto:    I-D = Action:draft-droms-mext-nemo-pd-00.txt
> > > Fecha:    Fri, 30 May 2008 05:45:01 -0700 = (PDT)
> > > De:    Internet-Drafts@ietf.org<= br> > > > Responder a:    internet-drafts@ietf.org<= br> > > > Para:    i-d-announce@ietf.org
> > >
> > >
> > >
> > > A New Internet-Draft is available from the on-line
> > > Internet-Drafts directories.
> > >
> > >    Title          : = DHCPv6 Prefix Delegation for NEMO
> > >    Author(s)      : R. Droms, et = al.
> > >    Filename        : draft-droms-mext-nemo-pd-00.txt
> > >    Pages          : = 12
> > >    Date          =   : 2008-05-30
> > >
> > > One aspect of network mobility support is the assignment = of a
> > > prefix or prefixes to a Mobile Router (MR) for use on the = links
> > > in the Mobile = Network.  DHCPv6 prefix delegation can be used for
> > > this configuration task.
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-droms-mext-ne= mo-pd-00.t
> > >xt
> > >
> > > Internet-Drafts are also available by anonymous FTP = at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > > Below is the data which will enable a MIME compliant mail = reader
> > > implementation to automatically retrieve the ASCII = version of the
> > > Internet-Draft.
> >
> > _______________________________________________
> > MEXT mailing list
> > MEXT@ietf.org
> > https://www.ietf.org/mailman/listinfo/mext

------_=_NextPart_001_01C8D2A7.4F9A1E27-- --===============2133988433== 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://www.ietf.org/mailman/listinfo/mext --===============2133988433==-- From mext-bounces@ietf.org Fri Jun 20 07:40:34 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14EE3A68E3; Fri, 20 Jun 2008 07:40:34 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C2D3A68AD for ; Fri, 20 Jun 2008 07:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 823jWI8XASSa for ; Fri, 20 Jun 2008 07:40:32 -0700 (PDT) Received: from web84315.mail.re1.yahoo.com (web84315.mail.re1.yahoo.com [69.147.74.194]) by core3.amsl.com (Postfix) with SMTP id C99883A67B3 for ; Fri, 20 Jun 2008 07:40:31 -0700 (PDT) Received: (qmail 4891 invoked by uid 60001); 20 Jun 2008 14:40:24 -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=387Eh3z5h6kFh0nD2NYoWbpOeeGkh+GWe6V01lKQy27Qs+CdG4+AvJGWzgnJMTy6/mA4DlwkRO44jOZbqtGQA7DRuCFASgPhtDD0lrTxOfzuob9R6SHnXAKOieWfLUPMeioLytkhjB6HlHNIG+w0+gc0Z8lOtrRqypuMMnv7djU=; X-YMail-OSG: N_ffe_UVM1n7dh8NRhd.Z3zCTs.6f4srhHzqhtLrmZS_PyU3Jmii2Mm2esvAwq5yYmJAtacx1edtVB7MTkqxhikhdgcm9fUMd3D0_3.AkbfomHdYhgoY0Xw- Received: from [206.16.17.212] by web84315.mail.re1.yahoo.com via HTTP; Fri, 20 Jun 2008 07:40:24 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.185 Date: Fri, 20 Jun 2008 07:40:24 -0700 (PDT) From: Behcet Sarikaya To: "Pascal Thubert \(pthubert\)" MIME-Version: 1.0 Message-ID: <547706.3404.qm@web84315.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 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="===============1991286409==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1991286409== Content-Type: multipart/alternative; boundary="0-1333712011-1213972824=:3404" --0-1333712011-1213972824=:3404 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable Hi Pascal,=0A Maybe you are right but you'd better get Francis and several= others accept your argument.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A----- Origi= nal Message ----=0AFrom: Pascal Thubert (pthubert) =0AT= o: Behcet Sarikaya ; Julien Laganier =0ACc: mext@ietf.org=0ASent: Friday, June 20, 2008 2:28:25 AM=0ASubje= ct: RE: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?=0A=0A =0AHi Beh= cet=0A =0AThe PD draft is consistent with its parent=0ARFCs 3775 and 3963. = If the group agrees in some future that DHAAD should be=0Adeprecated, then = we=A2ll need to revise all 3 documents. What=A2s important=0AIMHO is to kee= p them consistent.=0A =0APascal=0A=0A________________________________=0A = =0AFrom:mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of = Behcet Sarikaya=0ASent: mercredi 18 juin 2008 17:34=0ATo: Julien Laganier= =0ACc: mext@ietf.org=0ASubject: Re: [MEXT] Adoption of=0Adraft-droms-mext-n= emo-pd-00.txt?=0A =0AYes. The reason is=0Asimple, look at this draft:=0Ahtt= p://tools.ietf.org/id/draft-dupont-mext-dhaadharmful-00.txt=0A=0ARegards,= =0A=0ABehcet=0A----- Original Message=0A----=0AFrom: Julien Laganier =0ATo: mext@ietf.org; Behcet Sarikaya =0A=0ASent: Wednesday, June 18, 2008 10:29:27 AM=0ASubject: Re: [MEXT] Ado= ption of draft-droms-mext-nemo-pd-00.txt?=0A=0AOn Wednesday 18 June 2008, B= ehcet Sarikaya =0Awrote:=0A> Well, I was just wondering if its coauthors ag= ree with this text ?=0A=0AWell, then I'm still wondering what you're wonder= ing about... Are you =0Aasking whether or not coauthors of the draft agree = with the draft?! =0A=0A--julien=0A=0A> ----- Original Message ----=0A> From= : Julien Laganier =0A> To: Behcet Sarikaya =0A> Cc: mext@ietf.org=0A> Sent: Wednesday, June 18, 2008 4:00:= 49 AM=0A> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?= =0A>=0A> Behcet,=0A>=0A> I'm wondering what you're wondering about -- the m= essage I sent=0A> (excerpt below) is quite explicit, isn't it?=0A>=0A> > We= have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as=0A> > a WG= draft corresponding to the Nemo Prefix Delegation work item.=0A> >=0A> > A= uthors, please resubmit the draft as WG draft under the name:=0A> >=0A> > = draft-ietf-mext-nemo-pd-00.txt=0A>=0A> --julien=0A>=0A> On Tuesday 17 Jun= e 2008, Behcet Sarikaya =0Awrote:=0A> > Hi Julien,=0A> > It seems like dra= ft-ietf-mext-nemo-pd-00.txt does not carry any=0A> > changes based on the l= ong and heated debates we had on=0A> > draft-droms-mext-nemo-pd-00.txt. It = is a keep-alive version. Is=0A> > this what you expected from the authors?= =0A> >=0A> > Regards,=0A> >=0A> > Behcet=0A> >=0A> >=0A> > ----- Original M= essage ----=0A> > From: Julien Laganier =0A> > To:= draft-droms-mext-nemo-pd@tools.ietf.org=0A> > Cc: mext@ietf.org=0A> > Sent= : Friday, June 13, 2008 10:42:14 AM=0A> > Subject: Re: [MEXT] Adoption of d= raft-droms-mext-nemo-pd-00.txt?=0A> >=0A> > Folks,=0A> >=0A> > We have a WG= consensus to adopt draft-droms-mext-nemo-pd-00.txt as=0A> > a WG draft cor= responding to the Nemo Prefix Delegation work item.=0A> >=0A> > Authors, pl= ease resubmit the draft as WG draft under the name:=0A> >=0A> > draft-ie= tf-mext-nemo-pd-00.txt=0A> >=0A> > Note: you can use the online I-D submiss= ion tool to make it faster:=0A> > =0A> >=0A> > Thanks.=0A> >=0A> > --julien & marcelo, MEXT chairs.=0A> = >=0A> > On Friday 30 May 2008, marcelo bagnulo braun wrote:=0A> > > Hi,=0A>= > >=0A> > > We would like to ask the WG what is their opinion about=0Aacce= pting=0A> > > draft-droms-mext-nemo-pd-00.txt as the WG document for the Ne= mo=0A> > > PD deliverable included in our charter.=0A> > >=0A> > > Please p= rovide comments so we cna make some progress on this=0Along=0A> > > overdue= deliverable=0A> > >=0A> > > thanks, Julien and marcelo=0A> > >=0A> > > ---= ----- Mensaje original --------=0A> > > Asunto: I-D Action:draft-droms-m= ext-nemo-pd-00.txt=0A> > > Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT)= =0A> > > De: Internet-Drafts@ietf.org=0A> > > Responder a: internet-d= rafts@ietf.org=0A> > > Para : i-d-announce@ietf.org=0A> > >=0A> > >=0A> = > >=0A> > > A New Internet-Draft is available from the on-line=0A> > > Inte= rnet-Drafts directories.=0A> > >=0A> > > Title : DHCPv6=0APrefi= x Delegation for NEMO=0A> > > Author(s) : R. Droms, et al.=0A> > > = Filename :=0Adraft-droms-mext-nemo-pd-00.txt=0A> > > Pages = : 12=0A> > > Date : 2008-05-30=0A> > >=0A> > > One aspe= ct of network mobility support is the assignment of a=0A> > > prefix or pre= fixes to a Mobile Router (MR) for use on the links=0A> > > in the Mobile Ne= twork. =0ADHCPv6 prefix delegation can be used for=0A> > > this configurati= on task.=0A> > >=0A> > > A URL for this Internet-Draft is:=0A> > > http://w= ww.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.t=0A> > >xt=0A> > >= =0A> > > Internet-Drafts are also available by anonymous FTP at:=0A> > > ft= p://ftp.ietf.org/internet-drafts/=0A> > >=0A> > > Below is the data which w= ill enable a MIME compliant mail reader=0A> > > implementation to automatic= ally retrieve the ASCII version of=0Athe=0A> > > Internet-Draft.=0A> >=0A> = > _______________________________________________=0A> > MEXT mailing list= =0A> > MEXT@ietf.org=0A> > https://www.ietf.org/mailman/listinfo/mext --0-1333712011-1213972824=:3404 Content-Type: text/html; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable
Hi Pascal,
  Maybe you are right but you'd bet= ter get Francis and several others accept your argument.

Regards,
Behcet

----- Original Message ----
From: Pascal Thub= ert (pthubert) <pthubert@cisco.com>
To: Behcet Sarikaya <sarika= ya@ieee.org>; Julien Laganier <julien.IETF@laposte.net>
Cc: mex= t@ietf.org
Sent: Friday, June 20, 2008 2:28:25 AM
Subject: RE: [MEXT]= Adoption of draft-droms-mext-nemo-pd-00.txt?

=0A=0A=0A =0A =0A=0A = =0A=0A =0A=0A=0A=0A=0A=0A
=0A=0A

Hi Behcet

=0A=0A

 

=0A=0A

The PD draft is consistent with its parent=0ARFCs 3775 a= nd 3963. If the group agrees in some future that DHAAD should be=0Adeprecat= ed, then we=A2ll need to revise all 3 documents. What=A2s important=0AIMHO = is to keep them consistent.

=0A=0A

=  

=0A=0A
= =0A=0A

Pascal

=0A=0A
=0A=0A
=0A=0A
=0A=0A
=0A=0A
=0A=0A
=0A=0A

= From:=0Amext-b= ounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Behcet Sarikaya
=0ASent: mercredi 18 juin 2008 17:34
=0A<= span style=3D"font-weight: bold;">To: Julien Laganier
=0A<= span style=3D"font-weight: bold;">Cc: mext@ietf.org
=0ASubject: Re: [MEXT] Adoption of= =0Adraft-droms-mext-nemo-pd-00.txt?

=0A=0A
=0A=0A

 

=0A=0A
=0A=0A
=0A= =0A

Yes. The reason is= =0Asimple, look at this draft:
=0Ahttp://tools.ietf.org/id/draft-dupont-= mext-dhaadharmful-00.txt
=0A
=0ARegards,
=0A
=0ABehcet

=0A=0A
=0A=0A

----- Original Message=0A----
=0AFrom: Julien Laganier <julien.= IETF@laposte.net>
=0ATo: mext@ietf.org; Behcet Sarikaya =0A<sarika= ya@ieee.org>
=0ASent: Wednesday, June 18, 2008 10:29:27 AM
=0ASubj= ect: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?
=0A
=0AO= n Wednesday 18 June 2008, Behcet Sarikaya =0Awrote:
=0A> Well, I was = just wondering if its coauthors agree with this text ?
=0A
=0AWell, t= hen I'm still wondering what you're wondering about... Are you
=0Aaskin= g whether or not coauthors of the draft agree with the draft?!
=0A
= =0A--julien
=0A
=0A> ----- Original Message ----
=0A> From: = Julien Laganier <julien.IE= TF@laposte.net>
=0A> To: Behcet Sarikaya <sarikaya@ieee.org>
=0A> Cc: mext@ietf.org
=0A> Sent: Wednesday, June 18, 2008 4:00:4= 9 AM
=0A> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00= .txt?
=0A>
=0A> Behcet,
=0A>
=0A> I'm wondering wha= t you're wondering about -- the message I sent
=0A> (excerpt below) i= s quite explicit, isn't it?
=0A>
=0A> > We have a WG consens= us to adopt draft-droms-mext-nemo-pd-00.txt as
=0A> > a WG draft c= orresponding to the Nemo Prefix Delegation work item.
=0A> >
= =0A> > Authors, please resubmit the draft as WG draft under the name:=
=0A> >
=0A> >    draft-ietf-mext-nemo-pd-00.tx= t
=0A>
=0A> --julien
=0A>
=0A> On Tuesday 17 June 2= 008, Behcet Sarikaya =0Awrote:
=0A> > Hi Julien,
=0A> >&n= bsp; It seems like draft-ietf-mext-nemo-pd-00.txt does not carry any
=0A= > > changes based on the long and heated debates we had on
=0A>= > draft-droms-mext-nemo-pd-00.txt. It is a keep-alive version. Is
= =0A> > this what you expected from the authors?
=0A> >
= =0A> > Regards,
=0A> >
=0A> > Behcet
=0A> >= ;
=0A> >
=0A> > ----- Original Message ----
=0A> &g= t; From: Julien Laganier <= julien.IETF@laposte.net>
=0A> > To: draft-droms-mext-nem= o-pd@tools.ietf.org
=0A> > Cc: mext@= ietf.org
=0A> > Sent: Friday, June 13, 2008 10:42:14 AM
=0A= > > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?<= br>=0A> >
=0A> > Folks,
=0A> >
=0A> > We h= ave a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as
=0A> &= gt; a WG draft corresponding to the Nemo Prefix Delegation work item.
= =0A> >
=0A> > Authors, please resubmit the draft as WG draft= under the name:
=0A> >
=0A> >    draft-ietf-me= xt-nemo-pd-00.txt
=0A> >
=0A> > Note: you can use the onl= ine I-D submission tool to make it faster:
=0A> > <https://datatracker.ietf.org/idst/upload.cgi>
=0A> >=0A> > Thanks.
=0A> >
=0A> > --julien & marce= lo, MEXT chairs.
=0A> >
=0A> > On Friday 30 May 2008, mar= celo bagnulo braun wrote:
=0A> > > Hi,
=0A> > >
= =0A> > > We would like to ask the WG what is their opinion about= =0Aaccepting
=0A> > > draft-droms-mext-nemo-pd-00.txt as the WG= document for the Nemo
=0A> > > PD deliverable included in our = charter.
=0A> > >
=0A> > > Please provide comments = so we cna make some progress on this=0Along
=0A> > > overdue de= liverable
=0A> > >
=0A> > > thanks, Julien and marc= elo
=0A> > >
=0A> > > -------- Mensaje original ---= -----
=0A> > > Asunto:    I-D Action:draft-droms-mext= -nemo-pd-00.txt
=0A> > > Fecha:    Fri, 30 May 2008 0= 5:45:01 -0700 (PDT)
=0A> > > De:    Internet-Drafts@ietf.org
=0A> >= > Responder a:    internet-drafts@ietf.org
=0A> > > Para :    = i-d-announce@ietf.org
=0A&= gt; > >
=0A> > >
=0A> > >
=0A> > >= ; A New Internet-Draft is available from the on-line
=0A> > > I= nternet-Drafts directories.
=0A> > >
=0A> > > =   Title          : DHCPv6=0APrefix Delegatio= n for NEMO
=0A> > >    Author(s)      = : R. Droms, et al.
=0A> > >    Filename    =     :=0Adraft-droms-mext-nemo-pd-00.txt
=0A> > > = ;   Pages          : 12
=0A> > >&= nbsp;   Date            : 2008-05-30
= =0A> > >
=0A> > > One aspect of network mobility suppo= rt is the assignment of a
=0A> > > prefix or prefixes to a Mobi= le Router (MR) for use on the links
=0A> > > in the Mobile Netw= ork. =0ADHCPv6 prefix delegation can be used for
=0A> > > = this configuration task.
=0A> > >
=0A> > > A URL fo= r this Internet-Draft is:
=0A> > > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00= .t
=0A> > >xt
=0A> > >
=0A> > > Int= ernet-Drafts are also available by anonymous FTP at:
=0A> > > <= a rel=3D"nofollow" target=3D"_blank" href=3D"ftp://ftp.ietf.org/internet-dr= afts/">ftp://ftp.ietf.org/internet-drafts/
=0A> > >
=0A&= gt; > > Below is the data which will enable a MIME compliant mail rea= der
=0A> > > implementation to automatically retrieve the ASCII= version of=0Athe
=0A> > > Internet-Draft.
=0A> >
= =0A> > _______________________________________________
=0A> >= ; MEXT mailing list
=0A> > MEXT@ietf.org=
=0A> > https://www.ietf.org/mailman/listinfo/m= ext
=0A
=0A

=0A=0A
=0A=0A
=0A=0A=0A=0A
=0A=0A
=0A=0A
--0-1333712011-1213972824=:3404-- --===============1991286409== 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://www.ietf.org/mailman/listinfo/mext --===============1991286409==-- From mext-bounces@ietf.org Fri Jun 20 11:25:57 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D8E63A69F9; Fri, 20 Jun 2008 11:25:57 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8BA33A67AD for ; Fri, 20 Jun 2008 11:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.864 X-Spam-Level: X-Spam-Status: No, score=0.864 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xoJOWiT-lTv for ; Fri, 20 Jun 2008 11:25:55 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 2B4F63A69F9 for ; Fri, 20 Jun 2008 11:25:54 -0700 (PDT) Received: from 208.54.15.189 ([208.54.15.189]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Jun 2008 18:25:51 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 20 Jun 2008 11:25:49 -0700 From: Vijay Devarapalli To: "Pascal Thubert (pthubert)" , Behcet Sarikaya , Julien Laganier Message-ID: Thread-Topic: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Thread-Index: AcjRWMl3c2XQcjPfQ/O4sOqAfROytwBThYkQABcMJX0= In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05DC3DE2@xmb-ams-337.emea.cisco.com> Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Pascal, I believe there was reasonable consensus on removing the DHAAD extensions in the NEMO prefix delegation document, when were discussing adoption of the draft as a WG document. Many had argued said there is no need to extend DHAAD in the first place for prefix delegation. Perhaps you missed those emails buried in the emails on DHAAD deprecation. So your argument below that since it is there in 3776 and 3963, it should be in the prefix delegation document, does not make sense to me. Vijay On 6/20/08 12:28 AM, "Pascal Thubert (pthubert)" wrote: > Hi Behcet > = > The PD draft is consistent with its parent RFCs 3775 and 3963. If the gro= up > agrees in some future that DHAAD should be deprecated, then we=B9ll need = to > revise all 3 documents. What=B9s important IMHO is to keep them consisten= t. > = > = > Pascal > = > = > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of B= ehcet > Sarikaya > Sent: mercredi 18 juin 2008 17:34 > To: Julien Laganier > Cc: mext@ietf.org > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > = > = > Yes. The reason is simple, look at this draft: > http://tools.ietf.org/id/draft-dupont-mext-dhaadharmful-00.txt > = > Regards, > = > Behcet > = > ----- Original Message ---- > From: Julien Laganier > To: mext@ietf.org; Behcet Sarikaya > Sent: Wednesday, June 18, 2008 10:29:27 AM > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > = > On Wednesday 18 June 2008, Behcet Sarikaya wrote: >> Well, I was just wondering if its coauthors agree with this text ? > = > Well, then I'm still wondering what you're wondering about... Are you > asking whether or not coauthors of the draft agree with the draft?! > = > --julien > = >> ----- Original Message ---- >> From: Julien Laganier >> To: Behcet Sarikaya >> Cc: mext@ietf.org >> Sent: Wednesday, June 18, 2008 4:00:49 AM >> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> = >> Behcet, >> = >> I'm wondering what you're wondering about -- the message I sent >> (excerpt below) is quite explicit, isn't it? >> = >>> We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as >>> a WG draft corresponding to the Nemo Prefix Delegation work item. >>> = >>> Authors, please resubmit the draft as WG draft under the name: >>> = >>> draft-ietf-mext-nemo-pd-00.txt >> = >> --julien >> = >> On Tuesday 17 June 2008, Behcet Sarikaya wrote: >>> Hi Julien, >>> It seems like draft-ietf-mext-nemo-pd-00.txt does not carry any >>> changes based on the long and heated debates we had on >>> draft-droms-mext-nemo-pd-00.txt. It is a keep-alive version. Is >>> this what you expected from the authors? >>> = >>> Regards, >>> = >>> Behcet >>> = >>> = >>> ----- Original Message ---- >>> From: Julien Laganier >>> To: draft-droms-mext-nemo-pd@tools.ietf.org >>> Cc: mext@ietf.org >>> Sent: Friday, June 13, 2008 10:42:14 AM >>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >>> = >>> Folks, >>> = >>> We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as >>> a WG draft corresponding to the Nemo Prefix Delegation work item. >>> = >>> Authors, please resubmit the draft as WG draft under the name: >>> = >>> draft-ietf-mext-nemo-pd-00.txt >>> = >>> Note: you can use the online I-D submission tool to make it faster: >>> >>> = >>> Thanks. >>> = >>> --julien & marcelo, MEXT chairs. >>> = >>> On Friday 30 May 2008, marcelo bagnulo braun wrote: >>>> Hi, >>>> = >>>> We would like to ask the WG what is their opinion about accepting >>>> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo >>>> PD deliverable included in our charter. >>>> = >>>> Please provide comments so we cna make some progress on this long >>>> overdue deliverable >>>> = >>>> thanks, Julien and marcelo >>>> = >>>> -------- Mensaje original -------- >>>> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt >>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >>>> De: Internet-Drafts@ietf.org >>>> Responder a: internet-drafts@ietf.org >>>> Para: i-d-announce@ietf.org >>>> = >>>> = >>>> = >>>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts directories. >>>> = >>>> Title : DHCPv6 Prefix Delegation for NEMO >>>> Author(s) : R. Droms, et al. >>>> Filename : draft-droms-mext-nemo-pd-00.txt >>>> Pages : 12 >>>> Date : 2008-05-30 >>>> = >>>> One aspect of network mobility support is the assignment of a >>>> prefix or prefixes to a Mobile Router (MR) for use on the links >>>> in the Mobile Network. DHCPv6 prefix delegation can be used for >>>> this configuration task. >>>> = >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.t >>>> xt >>>> = >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> = >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>> = >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext > = > = > = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From cachaporreiro@sfal.pt Fri Jun 20 14:35:12 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65DDD3A6861; Fri, 20 Jun 2008 14:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -72.274 X-Spam-Level: X-Spam-Status: No, score=-72.274 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SUB_PERFECT=0.725, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YtMe0sfVH26; Fri, 20 Jun 2008 14:35:11 -0700 (PDT) Received: from host-70-45-80-96.onelinkpr.net (host-70-45-80-96.onelinkpr.net [70.45.80.96]) by core3.amsl.com (Postfix) with SMTP id 4C6A73A67D1; Fri, 20 Jun 2008 14:35:06 -0700 (PDT) X-Originating-IP: 157.96.34.4 by smtp.70.45.80.96; Fri, 20 Jun 2008 17:35:08 -0500 Message-ID: From: "Violet Tapia" Reply-To: "Violet Tapia" To: nemo-archive@ietf.org Subject: Replica watch is a perfect gift Date: Fri, 20 Jun 2008 17:35:08 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Did you watch the last 007 flick, Casino Royale? If you did, you probably noticed that all throughout the movie, James Bond wears an spectacularly beautiful Omega watch... and he even brags about it! How would you like to be wearing that same exact model watch? The good news is that YOU can! Because now, you don't have to spend thousands of dollars to sport an Omega watch! When you visit Diamond Replicas, you will be able to browse through dozens of Omega replica watches, and pick the one of your dreams for just a couple of hundred dollars. Our watches are of such undeniably high quality, and offer such superior performance, that you'll fall in love with them, and what's best: stay in love with them for years to come! Come inside Diamond Replicas and pick your new Omega today! http://bapetytanif76.blogspot.com/ From netlmm-bounces@ietf.org Fri Jun 20 14:35:14 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C9AA3A68F5 for ; Fri, 20 Jun 2008 14:35:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to netlmm awaits moderator approval From: netlmm-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 20 Jun 2008 14:35:12 -0700 Precedence: bulk X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETLMM working group discussion list X-List-Administrivia: yes Sender: netlmm-bounces@ietf.org Errors-To: netlmm-bounces@ietf.org Your mail to 'netlmm' with the subject Replica watch is a perfect gift Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netlmm/93ced35b1e5cb88b97078e13874451b47c0fa7b8 From netconf-bounces@ietf.org Fri Jun 20 14:35:14 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A98A33A68F5 for ; Fri, 20 Jun 2008 14:35:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to Netconf awaits moderator approval From: netconf-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 20 Jun 2008 14:35:12 -0700 Precedence: bulk X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 List-Id: Network Configuration WG mailing list X-List-Administrivia: yes Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Your mail to 'Netconf' with the subject Replica watch is a perfect gift Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netconf/7291ecbbe4d65f7a98f74e6d641cbccf221ecd30 From nfsv4-bounces@ietf.org Fri Jun 20 14:35:14 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B91F53A6980 for ; Fri, 20 Jun 2008 14:35:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nfsv4 awaits moderator approval From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 20 Jun 2008 14:35:12 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org Your mail to 'nfsv4' with the subject Replica watch is a perfect gift Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nfsv4/eb7a2ec3be242102bd6c2340acd22692d215f2fa From ngo-bounces@ietf.org Fri Jun 20 14:35:14 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4B2D3A6980 for ; Fri, 20 Jun 2008 14:35:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NGO awaits moderator approval From: ngo-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 20 Jun 2008 14:35:12 -0700 Precedence: bulk X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF X-List-Administrivia: yes Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Your mail to 'NGO' with the subject Replica watch is a perfect gift Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ngo/85a6c22510a161104748f6430a6632ff2719297d From nsis-bounces@ietf.org Fri Jun 20 14:35:14 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF0523A6980 for ; Fri, 20 Jun 2008 14:35:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nsis awaits moderator approval From: nsis-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 20 Jun 2008 14:35:13 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Your mail to 'nsis' with the subject Replica watch is a perfect gift Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis/753398128f7493f334e54464db677e2b4636724c From nsis-imp-bounces@ietf.org Fri Jun 20 14:35:14 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D79633A6980 for ; Fri, 20 Jun 2008 14:35:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NSIS-imp awaits moderator approval From: nsis-imp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 20 Jun 2008 14:35:13 -0700 Precedence: bulk X-BeenThere: nsis-imp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for implementation questions for NSIS protocols X-List-Administrivia: yes Sender: nsis-imp-bounces@ietf.org Errors-To: nsis-imp-bounces@ietf.org Your mail to 'NSIS-imp' with the subject Replica watch is a perfect gift Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis-imp/9133eaecc4c5995063efa52912c992068271a6d5 From nemo-bounces@ietf.org Fri Jun 20 14:35:14 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E27653A6980 for ; Fri, 20 Jun 2008 14:35:14 -0700 (PDT) Subject: The results of your email commands From: nemo-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0180772957==" Message-ID: Date: Fri, 20 Jun 2008 14:35:13 -0700 Precedence: bulk X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NEMO Working Group X-List-Administrivia: yes Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --===============0180772957== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://bapetytanif76.blogspot.com/ - Done. --===============0180772957== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nemo-request@core3.amsl.com Delivered-To: nemo-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65DDD3A6861; Fri, 20 Jun 2008 14:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -72.274 X-Spam-Level: X-Spam-Status: No, score=-72.274 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SUB_PERFECT=0.725, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YtMe0sfVH26; Fri, 20 Jun 2008 14:35:11 -0700 (PDT) Received: from host-70-45-80-96.onelinkpr.net (host-70-45-80-96.onelinkpr.net [70.45.80.96]) by core3.amsl.com (Postfix) with SMTP id 4C6A73A67D1; Fri, 20 Jun 2008 14:35:06 -0700 (PDT) X-Originating-IP: 157.96.34.4 by smtp.70.45.80.96; Fri, 20 Jun 2008 17:35:08 -0500 Message-ID: From: "Violet Tapia" Reply-To: "Violet Tapia" To: nemo-archive@ietf.org Subject: Replica watch is a perfect gift Date: Fri, 20 Jun 2008 17:35:08 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Did you watch the last 007 flick, Casino Royale? If you did, you probably noticed that all throughout the movie, James Bond wears an spectacularly beautiful Omega watch... and he even brags about it! How would you like to be wearing that same exact model watch? The good news is that YOU can! Because now, you don't have to spend thousands of dollars to sport an Omega watch! When you visit Diamond Replicas, you will be able to browse through dozens of Omega replica watches, and pick the one of your dreams for just a couple of hundred dollars. Our watches are of such undeniably high quality, and offer such superior performance, that you'll fall in love with them, and what's best: stay in love with them for years to come! Come inside Diamond Replicas and pick your new Omega today! http://bapetytanif76.blogspot.com/ --===============0180772957==-- From ntdp-bounces@ietf.org Fri Jun 20 14:35:14 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42663A6989 for ; Fri, 20 Jun 2008 14:35:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NTDP awaits moderator approval From: ntdp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Fri, 20 Jun 2008 14:35:13 -0700 Precedence: bulk X-BeenThere: ntdp@ietf.org X-Mailman-Version: 2.1.9 List-Id: define standards for the purpose of scripting of network testing equipment X-List-Administrivia: yes Sender: ntdp-bounces@ietf.org Errors-To: ntdp-bounces@ietf.org Your mail to 'NTDP' with the subject Replica watch is a perfect gift Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ntdp/85b16d29a4bf26d3d1d28380fdccc37d631d611e From nfsv4-bounces@ietf.org Fri Jun 20 14:35:14 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6E5D3A6980 for ; Fri, 20 Jun 2008 14:35:14 -0700 (PDT) Subject: The results of your email commands From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1223821451==" Message-ID: Date: Fri, 20 Jun 2008 14:35:13 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org --===============1223821451== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://bapetytanif76.blogspot.com/ - Done. --===============1223821451== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nfsv4-request@core3.amsl.com Delivered-To: nfsv4-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65DDD3A6861; Fri, 20 Jun 2008 14:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -72.274 X-Spam-Level: X-Spam-Status: No, score=-72.274 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SUB_PERFECT=0.725, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YtMe0sfVH26; Fri, 20 Jun 2008 14:35:11 -0700 (PDT) Received: from host-70-45-80-96.onelinkpr.net (host-70-45-80-96.onelinkpr.net [70.45.80.96]) by core3.amsl.com (Postfix) with SMTP id 4C6A73A67D1; Fri, 20 Jun 2008 14:35:06 -0700 (PDT) X-Originating-IP: 157.96.34.4 by smtp.70.45.80.96; Fri, 20 Jun 2008 17:35:08 -0500 Message-ID: From: "Violet Tapia" Reply-To: "Violet Tapia" To: nemo-archive@ietf.org Subject: Replica watch is a perfect gift Date: Fri, 20 Jun 2008 17:35:08 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Did you watch the last 007 flick, Casino Royale? If you did, you probably noticed that all throughout the movie, James Bond wears an spectacularly beautiful Omega watch... and he even brags about it! How would you like to be wearing that same exact model watch? The good news is that YOU can! Because now, you don't have to spend thousands of dollars to sport an Omega watch! When you visit Diamond Replicas, you will be able to browse through dozens of Omega replica watches, and pick the one of your dreams for just a couple of hundred dollars. Our watches are of such undeniably high quality, and offer such superior performance, that you'll fall in love with them, and what's best: stay in love with them for years to come! Come inside Diamond Replicas and pick your new Omega today! http://bapetytanif76.blogspot.com/ --===============1223821451==-- From nsis-bounces@ietf.org Fri Jun 20 14:35:15 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37E93A6981 for ; Fri, 20 Jun 2008 14:35:14 -0700 (PDT) Subject: The results of your email commands From: nsis-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1903900615==" Message-ID: Date: Fri, 20 Jun 2008 14:35:13 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============1903900615== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://bapetytanif76.blogspot.com/ - Done. --===============1903900615== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nsis-request@core3.amsl.com Delivered-To: nsis-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65DDD3A6861; Fri, 20 Jun 2008 14:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -72.274 X-Spam-Level: X-Spam-Status: No, score=-72.274 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SUB_PERFECT=0.725, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YtMe0sfVH26; Fri, 20 Jun 2008 14:35:11 -0700 (PDT) Received: from host-70-45-80-96.onelinkpr.net (host-70-45-80-96.onelinkpr.net [70.45.80.96]) by core3.amsl.com (Postfix) with SMTP id 4C6A73A67D1; Fri, 20 Jun 2008 14:35:06 -0700 (PDT) X-Originating-IP: 157.96.34.4 by smtp.70.45.80.96; Fri, 20 Jun 2008 17:35:08 -0500 Message-ID: From: "Violet Tapia" Reply-To: "Violet Tapia" To: nemo-archive@ietf.org Subject: Replica watch is a perfect gift Date: Fri, 20 Jun 2008 17:35:08 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Did you watch the last 007 flick, Casino Royale? If you did, you probably noticed that all throughout the movie, James Bond wears an spectacularly beautiful Omega watch... and he even brags about it! How would you like to be wearing that same exact model watch? The good news is that YOU can! Because now, you don't have to spend thousands of dollars to sport an Omega watch! When you visit Diamond Replicas, you will be able to browse through dozens of Omega replica watches, and pick the one of your dreams for just a couple of hundred dollars. Our watches are of such undeniably high quality, and offer such superior performance, that you'll fall in love with them, and what's best: stay in love with them for years to come! Come inside Diamond Replicas and pick your new Omega today! http://bapetytanif76.blogspot.com/ --===============1903900615==-- From ca@msbl.com Sat Jun 21 05:50:27 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1BCA3A68B4; Sat, 21 Jun 2008 05:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -69.667 X-Spam-Level: X-Spam-Status: No, score=-69.667 tagged_above=-999 required=5 tests=[BAYES_95=3, DNS_FROM_RFC_BOGUSMX=1.482, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPM6Ic7IZLM4; Sat, 21 Jun 2008 05:50:27 -0700 (PDT) Received: from 81.203.84.149.dyn.user.ono.com (81.203.84.149.dyn.user.ono.com [81.203.84.149]) by core3.amsl.com (Postfix) with SMTP id 26EC43A68D1; Sat, 21 Jun 2008 05:50:19 -0700 (PDT) X-Originating-IP: 236.171.66.236 by smtp.81.203.84.149; Sat, 21 Jun 2008 08:50:23 -0500 Message-ID: From: "Freeman Brady" Reply-To: "Freeman Brady" To: nemo-archive@ietf.org Subject: Inexpensive IWC watches Date: Sat, 21 Jun 2008 08:50:23 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Diamond Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://fugozilenug10.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://fugozilenug10.blogspot.com/ From netconf-bounces@ietf.org Sat Jun 21 05:50:28 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 620833A68EC for ; Sat, 21 Jun 2008 05:50:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to Netconf awaits moderator approval From: netconf-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Sat, 21 Jun 2008 05:50:28 -0700 Precedence: bulk X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 List-Id: Network Configuration WG mailing list X-List-Administrivia: yes Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Your mail to 'Netconf' with the subject Inexpensive IWC watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netconf/b7c2d4517cae099ac1ae0226432dea660dd4403c From netlmm-bounces@ietf.org Sat Jun 21 05:50:28 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752E23A68EC for ; Sat, 21 Jun 2008 05:50:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to netlmm awaits moderator approval From: netlmm-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Sat, 21 Jun 2008 05:50:28 -0700 Precedence: bulk X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETLMM working group discussion list X-List-Administrivia: yes Sender: netlmm-bounces@ietf.org Errors-To: netlmm-bounces@ietf.org Your mail to 'netlmm' with the subject Inexpensive IWC watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netlmm/a0990444122ba90c964b67e7cb3f793dd41a7ce9 From ngo-bounces@ietf.org Sat Jun 21 05:50:29 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F583A691A for ; Sat, 21 Jun 2008 05:50:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NGO awaits moderator approval From: ngo-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Sat, 21 Jun 2008 05:50:28 -0700 Precedence: bulk X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF X-List-Administrivia: yes Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Your mail to 'NGO' with the subject Inexpensive IWC watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ngo/a60be9caef5c73734edfcc5ae7e81cebeb7fa538 From nfsv4-bounces@ietf.org Sat Jun 21 05:50:29 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B066A3A6933 for ; Sat, 21 Jun 2008 05:50:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nfsv4 awaits moderator approval From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Sat, 21 Jun 2008 05:50:28 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org Your mail to 'nfsv4' with the subject Inexpensive IWC watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nfsv4/541f10dd03316aeadd339ffe0c94a0f26f5d8413 From nemo-bounces@ietf.org Sat Jun 21 05:50:29 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B99AA3A6933 for ; Sat, 21 Jun 2008 05:50:29 -0700 (PDT) Subject: The results of your email commands From: nemo-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1031229366==" Message-ID: Date: Sat, 21 Jun 2008 05:50:28 -0700 Precedence: bulk X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NEMO Working Group X-List-Administrivia: yes Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --===============1031229366== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://fugozilenug10.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://fugozilenug10.blogspot.com/ - Done. --===============1031229366== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nemo-request@core3.amsl.com Delivered-To: nemo-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1BCA3A68B4; Sat, 21 Jun 2008 05:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -69.667 X-Spam-Level: X-Spam-Status: No, score=-69.667 tagged_above=-999 required=5 tests=[BAYES_95=3, DNS_FROM_RFC_BOGUSMX=1.482, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPM6Ic7IZLM4; Sat, 21 Jun 2008 05:50:27 -0700 (PDT) Received: from 81.203.84.149.dyn.user.ono.com (81.203.84.149.dyn.user.ono.com [81.203.84.149]) by core3.amsl.com (Postfix) with SMTP id 26EC43A68D1; Sat, 21 Jun 2008 05:50:19 -0700 (PDT) X-Originating-IP: 236.171.66.236 by smtp.81.203.84.149; Sat, 21 Jun 2008 08:50:23 -0500 Message-ID: From: "Freeman Brady" Reply-To: "Freeman Brady" To: nemo-archive@ietf.org Subject: Inexpensive IWC watches Date: Sat, 21 Jun 2008 08:50:23 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Diamond Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://fugozilenug10.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://fugozilenug10.blogspot.com/ --===============1031229366==-- From nsis-imp-bounces@ietf.org Sat Jun 21 05:50:29 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC2773A6945 for ; Sat, 21 Jun 2008 05:50:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NSIS-imp awaits moderator approval From: nsis-imp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Sat, 21 Jun 2008 05:50:28 -0700 Precedence: bulk X-BeenThere: nsis-imp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for implementation questions for NSIS protocols X-List-Administrivia: yes Sender: nsis-imp-bounces@ietf.org Errors-To: nsis-imp-bounces@ietf.org Your mail to 'NSIS-imp' with the subject Inexpensive IWC watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis-imp/e29961a99d6acdd1da819fbca13ec301eaf1b91c From nfsv4-bounces@ietf.org Sat Jun 21 05:50:29 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40A63A6928 for ; Sat, 21 Jun 2008 05:50:29 -0700 (PDT) Subject: The results of your email commands From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0989192432==" Message-ID: Date: Sat, 21 Jun 2008 05:50:28 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org --===============0989192432== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://fugozilenug10.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://fugozilenug10.blogspot.com/ - Done. --===============0989192432== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nfsv4-request@core3.amsl.com Delivered-To: nfsv4-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1BCA3A68B4; Sat, 21 Jun 2008 05:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -69.667 X-Spam-Level: X-Spam-Status: No, score=-69.667 tagged_above=-999 required=5 tests=[BAYES_95=3, DNS_FROM_RFC_BOGUSMX=1.482, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPM6Ic7IZLM4; Sat, 21 Jun 2008 05:50:27 -0700 (PDT) Received: from 81.203.84.149.dyn.user.ono.com (81.203.84.149.dyn.user.ono.com [81.203.84.149]) by core3.amsl.com (Postfix) with SMTP id 26EC43A68D1; Sat, 21 Jun 2008 05:50:19 -0700 (PDT) X-Originating-IP: 236.171.66.236 by smtp.81.203.84.149; Sat, 21 Jun 2008 08:50:23 -0500 Message-ID: From: "Freeman Brady" Reply-To: "Freeman Brady" To: nemo-archive@ietf.org Subject: Inexpensive IWC watches Date: Sat, 21 Jun 2008 08:50:23 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Diamond Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://fugozilenug10.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://fugozilenug10.blogspot.com/ --===============0989192432==-- From nsis-bounces@ietf.org Sat Jun 21 05:50:29 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8FEE3A6928 for ; Sat, 21 Jun 2008 05:50:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nsis awaits moderator approval From: nsis-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Sat, 21 Jun 2008 05:50:29 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Your mail to 'nsis' with the subject Inexpensive IWC watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis/de28dc1c94afb84002fa3a4f68a38cb650897270 From ntdp-bounces@ietf.org Sat Jun 21 05:50:29 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFCCA3A6928 for ; Sat, 21 Jun 2008 05:50:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NTDP awaits moderator approval From: ntdp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Sat, 21 Jun 2008 05:50:29 -0700 Precedence: bulk X-BeenThere: ntdp@ietf.org X-Mailman-Version: 2.1.9 List-Id: define standards for the purpose of scripting of network testing equipment X-List-Administrivia: yes Sender: ntdp-bounces@ietf.org Errors-To: ntdp-bounces@ietf.org Your mail to 'NTDP' with the subject Inexpensive IWC watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ntdp/8e1bd42bf2134abcd1593ac623f952737c5c983b From nsis-bounces@ietf.org Sat Jun 21 05:50:30 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1E503A6946 for ; Sat, 21 Jun 2008 05:50:30 -0700 (PDT) Subject: The results of your email commands From: nsis-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1964230758==" Message-ID: Date: Sat, 21 Jun 2008 05:50:30 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============1964230758== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://fugozilenug10.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://fugozilenug10.blogspot.com/ - Done. --===============1964230758== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nsis-request@core3.amsl.com Delivered-To: nsis-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1BCA3A68B4; Sat, 21 Jun 2008 05:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -69.667 X-Spam-Level: X-Spam-Status: No, score=-69.667 tagged_above=-999 required=5 tests=[BAYES_95=3, DNS_FROM_RFC_BOGUSMX=1.482, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPM6Ic7IZLM4; Sat, 21 Jun 2008 05:50:27 -0700 (PDT) Received: from 81.203.84.149.dyn.user.ono.com (81.203.84.149.dyn.user.ono.com [81.203.84.149]) by core3.amsl.com (Postfix) with SMTP id 26EC43A68D1; Sat, 21 Jun 2008 05:50:19 -0700 (PDT) X-Originating-IP: 236.171.66.236 by smtp.81.203.84.149; Sat, 21 Jun 2008 08:50:23 -0500 Message-ID: From: "Freeman Brady" Reply-To: "Freeman Brady" To: nemo-archive@ietf.org Subject: Inexpensive IWC watches Date: Sat, 21 Jun 2008 08:50:23 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Diamond Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://fugozilenug10.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://fugozilenug10.blogspot.com/ --===============1964230758==-- From leeshangtrait@yahoo.co.jp Sat Jun 21 09:12:08 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AEBF3A6961; Sat, 21 Jun 2008 09:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.344 X-Spam-Level: ** X-Spam-Status: No, score=2.344 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_INVITATION=-2, J_CHICKENPOX_92=0.6, SARE_SUB_REPRESENT_REQ=1.666, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqZzAcqmefyw; Sat, 21 Jun 2008 09:12:08 -0700 (PDT) Received: from vmailn2.uprrp.edu (vmailn2.uprrp.edu [136.145.180.95]) by core3.amsl.com (Postfix) with ESMTP id E4DE03A6955; Sat, 21 Jun 2008 09:12:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by vmailn2.uprrp.edu (Postfix) with ESMTP id 91834C2BCE; Sat, 21 Jun 2008 12:12:01 -0400 (AST) X-Virus-Scanned: amavisd-new at vmailn2.uprrp.edu Received: from vmailn2.uprrp.edu ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJb0UhdoJGPw; Sat, 21 Jun 2008 12:12:01 -0400 (AST) Received: from email.uprrp.edu (localhost [127.0.0.1]) by vmailn2.uprrp.edu (Postfix) with ESMTP id C62B4C2A5A; Sat, 21 Jun 2008 12:10:38 -0400 (AST) Received: from 74.210.127.95 (SquirrelMail authenticated user laveguilla) by email.uprrp.edu with HTTP; Sat, 21 Jun 2008 12:10:38 -0400 (AST) Message-ID: <58939.74.210.127.95.1214064638.squirrel@email.uprrp.edu> Date: Sat, 21 Jun 2008 12:10:38 -0400 (AST) Subject: REPRESENTATIVE NEEDED From: "ITOCHU CORPORATION LTD." Reply-To: leeshangtrait@yahoo.co.jp User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal To: undisclosed-recipients:; DESK OF ITOCHU CORPORATION LTD. 5-1, Kita-Aoyama 2-chome Minato-ku, Tokyo 107-8077, Japan. This mail is serving as an invitation to treat with the above named company. Our company was established in 1970. Over the years we have accumulated invaluable experience in our business and we are proud to claim we are second to none.Our company exports cement, sugar and textile materials for world trade. Due to the increase in demand of our products in North and South America continent,it is upon this note that we seek your assistance to stand as our company representative in any of these continent list above. Note that, as our representative, you will receive 10% and monthly salary of $2,000.00 USD of whatever amount you clear for the company and the balance will be paid into an account we will avail to you. facilitate the conclusion of this transaction if accepted, send me promptly by email the following: Full Names: Contact Address: Phone/Mobile: Fax: Thank you for your time. Please send the above details to our Personnel Manager via belowdetails: Name: Mr. lee shang Email: leeshangtrait@yahoo.co.jp RESPECTFULLY SUBMITTED, PRESIDENT-ITOCHU CORPORATION LTD. From ChibrakePuckett@isoc.org Sat Jun 21 10:38:11 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 046173A684F; Sat, 21 Jun 2008 10:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.106 X-Spam-Level: X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, FORGED_MUA_OUTLOOK=3.116, INVALID_MSGID=1.9, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXMuaNnx6nVT; Sat, 21 Jun 2008 10:38:10 -0700 (PDT) Received: from casaim6jdu86zb (unknown [84.78.84.47]) by core3.amsl.com (Postfix) with SMTP id 943EF3A6836; Sat, 21 Jun 2008 10:38:08 -0700 (PDT) Message-ID: 1f10f401c8d3c5$86f21810$0301a8c0@casaim6jdu86zb From: "Hank Guthrie" To: Subject: Luxury Watches Date: Sat, 21 Jun 2008 19:37:20 -0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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 High Quality Name Brand Watches 1500 Styles Of High End Replicas http://snoodzip.com/ From c.manuel@amacogroup.com Mon Jun 23 01:19:11 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FE903A692D; Mon, 23 Jun 2008 01:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -69.876 X-Spam-Level: X-Spam-Status: No, score=-69.876 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLMPPWtZq18R; Mon, 23 Jun 2008 01:19:10 -0700 (PDT) Received: from host83-97-dynamic.30-79-r.retail.telecomitalia.it (host83-97-dynamic.30-79-r.retail.telecomitalia.it [79.30.97.83]) by core3.amsl.com (Postfix) with SMTP id 970D13A6881; Mon, 23 Jun 2008 01:18:25 -0700 (PDT) X-Originating-IP: 40.85.194.170 by smtp.79.30.97.83; Mon, 23 Jun 2008 04:18:26 -0500 Message-ID: From: "Valerie Wong" Reply-To: "Valerie Wong" To: nemo-archive@ietf.org Subject: Why replica watches are better Date: Mon, 23 Jun 2008 04:18:26 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Did you watch the last 007 flick, Casino Royale? If you did, you probably noticed that all throughout the movie, James Bond wears an spectacularly beautiful Omega watch... and he even brags about it! How would you like to be wearing that same exact model watch? The good news is that YOU can! Because now, you don't have to spend thousands of dollars to sport an Omega watch! When you visit Diamond Replicas, you will be able to browse through dozens of Omega replica watches, and pick the one of your dreams for just a couple of hundred dollars. Our watches are of such undeniably high quality, and offer such superior performance, that you'll fall in love with them, and what's best: stay in love with them for years to come! Come inside Diamond Replicas and pick your new Omega today! http://zyrixugicog44.blogspot.com/ From netlmm-bounces@ietf.org Mon Jun 23 01:19:12 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C163B3A6943 for ; Mon, 23 Jun 2008 01:19:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to netlmm awaits moderator approval From: netlmm-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 01:19:11 -0700 Precedence: bulk X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETLMM working group discussion list X-List-Administrivia: yes Sender: netlmm-bounces@ietf.org Errors-To: netlmm-bounces@ietf.org Your mail to 'netlmm' with the subject Why replica watches are better Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netlmm/02add9eca2902ec9cc4fc80f427d180d0dad8c08 From ngo-bounces@ietf.org Mon Jun 23 01:19:12 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91893A6943 for ; Mon, 23 Jun 2008 01:19:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NGO awaits moderator approval From: ngo-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 01:19:11 -0700 Precedence: bulk X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF X-List-Administrivia: yes Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Your mail to 'NGO' with the subject Why replica watches are better Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ngo/cb686d8f567c97c2bb736ed57dd24c0055ecb8bc From nsis-bounces@ietf.org Mon Jun 23 01:19:12 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D012D3A697A for ; Mon, 23 Jun 2008 01:19:12 -0700 (PDT) Subject: The results of your email commands From: nsis-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1209037771==" Message-ID: Date: Mon, 23 Jun 2008 01:19:11 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============1209037771== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://zyrixugicog44.blogspot.com/ - Done. --===============1209037771== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nsis-request@core3.amsl.com Delivered-To: nsis-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FE903A692D; Mon, 23 Jun 2008 01:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -69.876 X-Spam-Level: X-Spam-Status: No, score=-69.876 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLMPPWtZq18R; Mon, 23 Jun 2008 01:19:10 -0700 (PDT) Received: from host83-97-dynamic.30-79-r.retail.telecomitalia.it (host83-97-dynamic.30-79-r.retail.telecomitalia.it [79.30.97.83]) by core3.amsl.com (Postfix) with SMTP id 970D13A6881; Mon, 23 Jun 2008 01:18:25 -0700 (PDT) X-Originating-IP: 40.85.194.170 by smtp.79.30.97.83; Mon, 23 Jun 2008 04:18:26 -0500 Message-ID: From: "Valerie Wong" Reply-To: "Valerie Wong" To: nemo-archive@ietf.org Subject: Why replica watches are better Date: Mon, 23 Jun 2008 04:18:26 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Did you watch the last 007 flick, Casino Royale? If you did, you probably noticed that all throughout the movie, James Bond wears an spectacularly beautiful Omega watch... and he even brags about it! How would you like to be wearing that same exact model watch? The good news is that YOU can! Because now, you don't have to spend thousands of dollars to sport an Omega watch! When you visit Diamond Replicas, you will be able to browse through dozens of Omega replica watches, and pick the one of your dreams for just a couple of hundred dollars. Our watches are of such undeniably high quality, and offer such superior performance, that you'll fall in love with them, and what's best: stay in love with them for years to come! Come inside Diamond Replicas and pick your new Omega today! http://zyrixugicog44.blogspot.com/ --===============1209037771==-- From nfsv4-bounces@ietf.org Mon Jun 23 01:19:12 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D40F93A697A for ; Mon, 23 Jun 2008 01:19:12 -0700 (PDT) Subject: The results of your email commands From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1302519264==" Message-ID: Date: Mon, 23 Jun 2008 01:19:11 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org --===============1302519264== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://zyrixugicog44.blogspot.com/ - Done. --===============1302519264== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nfsv4-request@core3.amsl.com Delivered-To: nfsv4-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FE903A692D; Mon, 23 Jun 2008 01:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -69.876 X-Spam-Level: X-Spam-Status: No, score=-69.876 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLMPPWtZq18R; Mon, 23 Jun 2008 01:19:10 -0700 (PDT) Received: from host83-97-dynamic.30-79-r.retail.telecomitalia.it (host83-97-dynamic.30-79-r.retail.telecomitalia.it [79.30.97.83]) by core3.amsl.com (Postfix) with SMTP id 970D13A6881; Mon, 23 Jun 2008 01:18:25 -0700 (PDT) X-Originating-IP: 40.85.194.170 by smtp.79.30.97.83; Mon, 23 Jun 2008 04:18:26 -0500 Message-ID: From: "Valerie Wong" Reply-To: "Valerie Wong" To: nemo-archive@ietf.org Subject: Why replica watches are better Date: Mon, 23 Jun 2008 04:18:26 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Did you watch the last 007 flick, Casino Royale? If you did, you probably noticed that all throughout the movie, James Bond wears an spectacularly beautiful Omega watch... and he even brags about it! How would you like to be wearing that same exact model watch? The good news is that YOU can! Because now, you don't have to spend thousands of dollars to sport an Omega watch! When you visit Diamond Replicas, you will be able to browse through dozens of Omega replica watches, and pick the one of your dreams for just a couple of hundred dollars. Our watches are of such undeniably high quality, and offer such superior performance, that you'll fall in love with them, and what's best: stay in love with them for years to come! Come inside Diamond Replicas and pick your new Omega today! http://zyrixugicog44.blogspot.com/ --===============1302519264==-- From netconf-bounces@ietf.org Mon Jun 23 01:19:12 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9D3D3A6953 for ; Mon, 23 Jun 2008 01:19:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to Netconf awaits moderator approval From: netconf-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 01:19:11 -0700 Precedence: bulk X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 List-Id: Network Configuration WG mailing list X-List-Administrivia: yes Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Your mail to 'Netconf' with the subject Why replica watches are better Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netconf/b2dbc05801027df6f484c08f9deae5287fc2467b From nemo-bounces@ietf.org Mon Jun 23 01:19:12 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E30A53A6953 for ; Mon, 23 Jun 2008 01:19:12 -0700 (PDT) Subject: The results of your email commands From: nemo-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0985802707==" Message-ID: Date: Mon, 23 Jun 2008 01:19:11 -0700 Precedence: bulk X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NEMO Working Group X-List-Administrivia: yes Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --===============0985802707== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://zyrixugicog44.blogspot.com/ - Done. --===============0985802707== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nemo-request@core3.amsl.com Delivered-To: nemo-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FE903A692D; Mon, 23 Jun 2008 01:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -69.876 X-Spam-Level: X-Spam-Status: No, score=-69.876 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLMPPWtZq18R; Mon, 23 Jun 2008 01:19:10 -0700 (PDT) Received: from host83-97-dynamic.30-79-r.retail.telecomitalia.it (host83-97-dynamic.30-79-r.retail.telecomitalia.it [79.30.97.83]) by core3.amsl.com (Postfix) with SMTP id 970D13A6881; Mon, 23 Jun 2008 01:18:25 -0700 (PDT) X-Originating-IP: 40.85.194.170 by smtp.79.30.97.83; Mon, 23 Jun 2008 04:18:26 -0500 Message-ID: From: "Valerie Wong" Reply-To: "Valerie Wong" To: nemo-archive@ietf.org Subject: Why replica watches are better Date: Mon, 23 Jun 2008 04:18:26 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Did you watch the last 007 flick, Casino Royale? If you did, you probably noticed that all throughout the movie, James Bond wears an spectacularly beautiful Omega watch... and he even brags about it! How would you like to be wearing that same exact model watch? The good news is that YOU can! Because now, you don't have to spend thousands of dollars to sport an Omega watch! When you visit Diamond Replicas, you will be able to browse through dozens of Omega replica watches, and pick the one of your dreams for just a couple of hundred dollars. Our watches are of such undeniably high quality, and offer such superior performance, that you'll fall in love with them, and what's best: stay in love with them for years to come! Come inside Diamond Replicas and pick your new Omega today! http://zyrixugicog44.blogspot.com/ --===============0985802707==-- From nsis-imp-bounces@ietf.org Mon Jun 23 01:19:12 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E54DF3A6965 for ; Mon, 23 Jun 2008 01:19:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NSIS-imp awaits moderator approval From: nsis-imp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 01:19:11 -0700 Precedence: bulk X-BeenThere: nsis-imp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for implementation questions for NSIS protocols X-List-Administrivia: yes Sender: nsis-imp-bounces@ietf.org Errors-To: nsis-imp-bounces@ietf.org Your mail to 'NSIS-imp' with the subject Why replica watches are better Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis-imp/4e82e7d817f588d1620506e203ea93b147a2cf88 From nfsv4-bounces@ietf.org Mon Jun 23 01:19:12 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB0583A697A for ; Mon, 23 Jun 2008 01:19:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nfsv4 awaits moderator approval From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 01:19:11 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org Your mail to 'nfsv4' with the subject Why replica watches are better Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nfsv4/07de261ddd14b8db2b1c7f948d52d17bdfd8e0e3 From nsis-bounces@ietf.org Mon Jun 23 01:19:13 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045D23A6953 for ; Mon, 23 Jun 2008 01:19:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nsis awaits moderator approval From: nsis-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 01:19:12 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Your mail to 'nsis' with the subject Why replica watches are better Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis/dbdb0c9729a92f5d40b4962c0e6771a232afe937 From ntdp-bounces@ietf.org Mon Jun 23 01:19:13 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099DD3A6953 for ; Mon, 23 Jun 2008 01:19:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NTDP awaits moderator approval From: ntdp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 01:19:12 -0700 Precedence: bulk X-BeenThere: ntdp@ietf.org X-Mailman-Version: 2.1.9 List-Id: define standards for the purpose of scripting of network testing equipment X-List-Administrivia: yes Sender: ntdp-bounces@ietf.org Errors-To: ntdp-bounces@ietf.org Your mail to 'NTDP' with the subject Why replica watches are better Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ntdp/6eb4341d421c4dfa32adeb8c9d2bf1aa5e6c7b78 From c.roets@gloria.be Mon Jun 23 01:49:49 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2436B3A6816; Mon, 23 Jun 2008 01:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -59.094 X-Spam-Level: X-Spam-Status: No, score=-59.094 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, GB_ROLEX=5, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fxaNRI4+JSH; Mon, 23 Jun 2008 01:49:48 -0700 (PDT) Received: from cable201-233-191-147.epm.net.co (cable201-233-191-147.epm.net.co [201.233.191.147]) by core3.amsl.com (Postfix) with SMTP id F0F0A3A676A; Mon, 23 Jun 2008 01:48:53 -0700 (PDT) X-Originating-IP: 172.120.156.160 by smtp.201.233.191.147; Mon, 23 Jun 2008 04:48:53 -0500 Message-ID: From: "Alvaro Osborn" Reply-To: "Alvaro Osborn" To: nemo-archive@ietf.org Subject: The discreet replica store Date: Mon, 23 Jun 2008 04:48:53 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Diamond Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://cevytovirac57.blogspot.com/ Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://cevytovirac57.blogspot.com/ From nemo-bounces@ietf.org Mon Jun 23 01:49:50 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B91263A6912 for ; Mon, 23 Jun 2008 01:49:50 -0700 (PDT) Subject: The results of your email commands From: nemo-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1667669488==" Message-ID: Date: Mon, 23 Jun 2008 01:49:49 -0700 Precedence: bulk X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NEMO Working Group X-List-Administrivia: yes Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --===============1667669488== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://cevytovirac57.blogspot.com/ Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://cevytovirac57.blogspot.com/ - Done. --===============1667669488== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nemo-request@core3.amsl.com Delivered-To: nemo-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2436B3A6816; Mon, 23 Jun 2008 01:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -59.094 X-Spam-Level: X-Spam-Status: No, score=-59.094 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, GB_ROLEX=5, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fxaNRI4+JSH; Mon, 23 Jun 2008 01:49:48 -0700 (PDT) Received: from cable201-233-191-147.epm.net.co (cable201-233-191-147.epm.net.co [201.233.191.147]) by core3.amsl.com (Postfix) with SMTP id F0F0A3A676A; Mon, 23 Jun 2008 01:48:53 -0700 (PDT) X-Originating-IP: 172.120.156.160 by smtp.201.233.191.147; Mon, 23 Jun 2008 04:48:53 -0500 Message-ID: From: "Alvaro Osborn" Reply-To: "Alvaro Osborn" To: nemo-archive@ietf.org Subject: The discreet replica store Date: Mon, 23 Jun 2008 04:48:53 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Diamond Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://cevytovirac57.blogspot.com/ Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://cevytovirac57.blogspot.com/ --===============1667669488==-- From nfsv4-bounces@ietf.org Mon Jun 23 01:49:50 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEF0D3A6912 for ; Mon, 23 Jun 2008 01:49:50 -0700 (PDT) Subject: The results of your email commands From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0043653081==" Message-ID: Date: Mon, 23 Jun 2008 01:49:49 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org --===============0043653081== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://cevytovirac57.blogspot.com/ Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://cevytovirac57.blogspot.com/ - Done. --===============0043653081== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nfsv4-request@core3.amsl.com Delivered-To: nfsv4-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2436B3A6816; Mon, 23 Jun 2008 01:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -59.094 X-Spam-Level: X-Spam-Status: No, score=-59.094 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, GB_ROLEX=5, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fxaNRI4+JSH; Mon, 23 Jun 2008 01:49:48 -0700 (PDT) Received: from cable201-233-191-147.epm.net.co (cable201-233-191-147.epm.net.co [201.233.191.147]) by core3.amsl.com (Postfix) with SMTP id F0F0A3A676A; Mon, 23 Jun 2008 01:48:53 -0700 (PDT) X-Originating-IP: 172.120.156.160 by smtp.201.233.191.147; Mon, 23 Jun 2008 04:48:53 -0500 Message-ID: From: "Alvaro Osborn" Reply-To: "Alvaro Osborn" To: nemo-archive@ietf.org Subject: The discreet replica store Date: Mon, 23 Jun 2008 04:48:53 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Diamond Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://cevytovirac57.blogspot.com/ Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://cevytovirac57.blogspot.com/ --===============0043653081==-- From nsis-bounces@ietf.org Mon Jun 23 01:49:50 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C496F3A6912 for ; Mon, 23 Jun 2008 01:49:50 -0700 (PDT) Subject: The results of your email commands From: nsis-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1722311295==" Message-ID: Date: Mon, 23 Jun 2008 01:49:49 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============1722311295== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://cevytovirac57.blogspot.com/ Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://cevytovirac57.blogspot.com/ - Done. --===============1722311295== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nsis-request@core3.amsl.com Delivered-To: nsis-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2436B3A6816; Mon, 23 Jun 2008 01:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -59.094 X-Spam-Level: X-Spam-Status: No, score=-59.094 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, GB_ROLEX=5, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fxaNRI4+JSH; Mon, 23 Jun 2008 01:49:48 -0700 (PDT) Received: from cable201-233-191-147.epm.net.co (cable201-233-191-147.epm.net.co [201.233.191.147]) by core3.amsl.com (Postfix) with SMTP id F0F0A3A676A; Mon, 23 Jun 2008 01:48:53 -0700 (PDT) X-Originating-IP: 172.120.156.160 by smtp.201.233.191.147; Mon, 23 Jun 2008 04:48:53 -0500 Message-ID: From: "Alvaro Osborn" Reply-To: "Alvaro Osborn" To: nemo-archive@ietf.org Subject: The discreet replica store Date: Mon, 23 Jun 2008 04:48:53 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Diamond Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://cevytovirac57.blogspot.com/ Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://cevytovirac57.blogspot.com/ --===============1722311295==-- From netlmm-bounces@ietf.org Mon Jun 23 01:49:50 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C79193A693F for ; Mon, 23 Jun 2008 01:49:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to netlmm awaits moderator approval From: netlmm-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 01:49:49 -0700 Precedence: bulk X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETLMM working group discussion list X-List-Administrivia: yes Sender: netlmm-bounces@ietf.org Errors-To: netlmm-bounces@ietf.org Your mail to 'netlmm' with the subject The discreet replica store Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netlmm/efd987126f699d297e4aeb3cd3bab483e24d225d From nsis-imp-bounces@ietf.org Mon Jun 23 01:49:50 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8F33A693F for ; Mon, 23 Jun 2008 01:49:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NSIS-imp awaits moderator approval From: nsis-imp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 01:49:49 -0700 Precedence: bulk X-BeenThere: nsis-imp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for implementation questions for NSIS protocols X-List-Administrivia: yes Sender: nsis-imp-bounces@ietf.org Errors-To: nsis-imp-bounces@ietf.org Your mail to 'NSIS-imp' with the subject The discreet replica store Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis-imp/c350638e3ba021578f2e9c261d3b35545e0213c9 From netconf-bounces@ietf.org Mon Jun 23 01:49:50 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2C593A6953 for ; Mon, 23 Jun 2008 01:49:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to Netconf awaits moderator approval From: netconf-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 01:49:49 -0700 Precedence: bulk X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 List-Id: Network Configuration WG mailing list X-List-Administrivia: yes Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Your mail to 'Netconf' with the subject The discreet replica store Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netconf/0a0f08f5b50f340cefdf216b7c4a5ea98a0d1b04 From nfsv4-bounces@ietf.org Mon Jun 23 01:49:50 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDAAE3A6912 for ; Mon, 23 Jun 2008 01:49:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nfsv4 awaits moderator approval From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 01:49:49 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org Your mail to 'nfsv4' with the subject The discreet replica store Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nfsv4/179f489e843b539418d0b2b75ea3dcb2de9a3fd3 From nsis-bounces@ietf.org Mon Jun 23 01:49:50 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7D283A6912 for ; Mon, 23 Jun 2008 01:49:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nsis awaits moderator approval From: nsis-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 01:49:49 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Your mail to 'nsis' with the subject The discreet replica store Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis/e78fa1b5af3ee6186995cf8eb576499251938c07 From ngo-bounces@ietf.org Mon Jun 23 01:49:50 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECFE33A6912 for ; Mon, 23 Jun 2008 01:49:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NGO awaits moderator approval From: ngo-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 01:49:49 -0700 Precedence: bulk X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF X-List-Administrivia: yes Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Your mail to 'NGO' with the subject The discreet replica store Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ngo/01a407243f189b59e59b6ee4525d9982f2106b2f From ntdp-bounces@ietf.org Mon Jun 23 01:49:51 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 019FE3A6953 for ; Mon, 23 Jun 2008 01:49:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NTDP awaits moderator approval From: ntdp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 01:49:49 -0700 Precedence: bulk X-BeenThere: ntdp@ietf.org X-Mailman-Version: 2.1.9 List-Id: define standards for the purpose of scripting of network testing equipment X-List-Administrivia: yes Sender: ntdp-bounces@ietf.org Errors-To: ntdp-bounces@ietf.org Your mail to 'NTDP' with the subject The discreet replica store Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ntdp/c5ab70cbf91c2453d2aeb2dfaf914d4aa1876612 From mext-bounces@ietf.org Mon Jun 23 05:52:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F813A68EF; Mon, 23 Jun 2008 05:52:52 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E35763A68EF for ; Mon, 23 Jun 2008 05:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37rTt1pSMsp8 for ; Mon, 23 Jun 2008 05:52:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2706C3A67C1 for ; Mon, 23 Jun 2008 05:52:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,690,1204498800"; d="scan'208";a="12413558" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 23 Jun 2008 14:52:49 +0200 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 m5NCqnCE009374; Mon, 23 Jun 2008 14:52:49 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5NCqn2R007267; Mon, 23 Jun 2008 12:52:49 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, 23 Jun 2008 14:52:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 14:52:12 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05DC4567@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Thread-Index: AcjRWMl3c2XQcjPfQ/O4sOqAfROytwBThYkQABcMJX0Aiv4XkA== References: <7892795E1A87F04CADFCCF41FADD00FC05DC3DE2@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Behcet Sarikaya" , "Julien Laganier" X-OriginalArrivalTime: 23 Jun 2008 12:52:49.0031 (UTC) FILETIME=[0A6FE170:01C8D530] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6732; t=1214225569; x=1215089569; 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]=20Adoption=20of=20draft-droms-me xt-nemo-pd-00.txt? |Sender:=20; bh=YqENWa3bauYEv0+51FC/zDEzkZt2CZeH2stumBEktkQ=; b=rAjIrKO2yb10g2rR64gXAwc8LL2mZzuwkWCqsfaUsSzwB5eeDwSZvQOQkW QqCB1RWKZXACIAOWDYA7CC5PRACfMpchstkYlsLh5O+7XVhHAxUexCZr9U9W eNTh0JMy3A; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, I've not seen a consensus call on this and I'm sorry if I missed it. If the= re was none than let us have one with all the arguments from all parties on= the table. My point is that this PD draft extends a family started with 3775 and 3963.= This is why I think it makes sense to be consistent between the 3. People = do not have to call their lawyer to figure how discovery is done depending = on which MIP feature we are talking about. What I do disagree with is your idea of trying all the HAs found in MIP/NEM= O DHAAD till one HA is found that supports PD. I think that this is what do= es not make lots of sense... Pascal >-----Original Message----- >From: Vijay Devarapalli [mailto:vijay@wichorus.com] >Sent: vendredi 20 juin 2008 20:26 >To: Pascal Thubert (pthubert); Behcet Sarikaya; Julien Laganier >Cc: mext@ietf.org >Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > >Hi Pascal, > >I believe there was reasonable consensus on removing the DHAAD extensions = in >the NEMO prefix delegation document, when were discussing adoption of the >draft as a WG document. > >Many had argued said there is no need to extend DHAAD in the first place f= or >prefix delegation. Perhaps you missed those emails buried in the emails on >DHAAD deprecation. So your argument below that since it is there in 3776 a= nd >3963, it should be in the prefix delegation document, does not make sense = to >me. > >Vijay > > >On 6/20/08 12:28 AM, "Pascal Thubert (pthubert)" wrot= e: > >> Hi Behcet >> >> The PD draft is consistent with its parent RFCs 3775 and 3963. If the gr= oup >> agrees in some future that DHAAD should be deprecated, then we=B9ll need= to >> revise all 3 documents. What=B9s important IMHO is to keep them consiste= nt. >> >> >> Pascal >> >> >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of = Behcet >> Sarikaya >> Sent: mercredi 18 juin 2008 17:34 >> To: Julien Laganier >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> >> >> Yes. The reason is simple, look at this draft: >> http://tools.ietf.org/id/draft-dupont-mext-dhaadharmful-00.txt >> >> Regards, >> >> Behcet >> >> ----- Original Message ---- >> From: Julien Laganier >> To: mext@ietf.org; Behcet Sarikaya >> Sent: Wednesday, June 18, 2008 10:29:27 AM >> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> >> On Wednesday 18 June 2008, Behcet Sarikaya wrote: >>> Well, I was just wondering if its coauthors agree with this text ? >> >> Well, then I'm still wondering what you're wondering about... Are you >> asking whether or not coauthors of the draft agree with the draft?! >> >> --julien >> >>> ----- Original Message ---- >>> From: Julien Laganier >>> To: Behcet Sarikaya >>> Cc: mext@ietf.org >>> Sent: Wednesday, June 18, 2008 4:00:49 AM >>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >>> >>> Behcet, >>> >>> I'm wondering what you're wondering about -- the message I sent >>> (excerpt below) is quite explicit, isn't it? >>> >>>> We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as >>>> a WG draft corresponding to the Nemo Prefix Delegation work item. >>>> >>>> Authors, please resubmit the draft as WG draft under the name: >>>> >>>> draft-ietf-mext-nemo-pd-00.txt >>> >>> --julien >>> >>> On Tuesday 17 June 2008, Behcet Sarikaya wrote: >>>> Hi Julien, >>>> It seems like draft-ietf-mext-nemo-pd-00.txt does not carry any >>>> changes based on the long and heated debates we had on >>>> draft-droms-mext-nemo-pd-00.txt. It is a keep-alive version. Is >>>> this what you expected from the authors? >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>>> >>>> ----- Original Message ---- >>>> From: Julien Laganier >>>> To: draft-droms-mext-nemo-pd@tools.ietf.org >>>> Cc: mext@ietf.org >>>> Sent: Friday, June 13, 2008 10:42:14 AM >>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >>>> >>>> Folks, >>>> >>>> We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as >>>> a WG draft corresponding to the Nemo Prefix Delegation work item. >>>> >>>> Authors, please resubmit the draft as WG draft under the name: >>>> >>>> draft-ietf-mext-nemo-pd-00.txt >>>> >>>> Note: you can use the online I-D submission tool to make it faster: >>>> >>>> >>>> Thanks. >>>> >>>> --julien & marcelo, MEXT chairs. >>>> >>>> On Friday 30 May 2008, marcelo bagnulo braun wrote: >>>>> Hi, >>>>> >>>>> We would like to ask the WG what is their opinion about accepting >>>>> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo >>>>> PD deliverable included in our charter. >>>>> >>>>> Please provide comments so we cna make some progress on this long >>>>> overdue deliverable >>>>> >>>>> thanks, Julien and marcelo >>>>> >>>>> -------- Mensaje original -------- >>>>> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt >>>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >>>>> De: Internet-Drafts@ietf.org >>>>> Responder a: internet-drafts@ietf.org >>>>> Para: i-d-announce@ietf.org >>>>> >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line >>>>> Internet-Drafts directories. >>>>> >>>>> Title : DHCPv6 Prefix Delegation for NEMO >>>>> Author(s) : R. Droms, et al. >>>>> Filename : draft-droms-mext-nemo-pd-00.txt >>>>> Pages : 12 >>>>> Date : 2008-05-30 >>>>> >>>>> One aspect of network mobility support is the assignment of a >>>>> prefix or prefixes to a Mobile Router (MR) for use on the links >>>>> in the Mobile Network. DHCPv6 prefix delegation can be used for >>>>> this configuration task. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.t >>>>> xt >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> Below is the data which will enable a MIME compliant mail reader >>>>> implementation to automatically retrieve the ASCII version of the >>>>> Internet-Draft. >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 23 10:35:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD123A69B6; Mon, 23 Jun 2008 10:35:25 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0873A6A1A for ; Mon, 23 Jun 2008 10:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+W6vYWdc9JN for ; Mon, 23 Jun 2008 10:35:18 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 9EE033A69AF for ; Mon, 23 Jun 2008 10:35:12 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 13:35:09 -0400 Message-ID: In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05DC4567@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Thread-Index: AcjRWMl3c2XQcjPfQ/O4sOqAfROytwBThYkQABcMJX0Aiv4XkAAJtZog References: <7892795E1A87F04CADFCCF41FADD00FC05DC3DE2@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05DC4567@xmb-ams-337.emea.cisco.com> From: "Vijay Devarapalli" To: "Pascal Thubert (pthubert)" , "Julien Laganier" , "marcelo bagnulo braun" Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Pascal, = > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] = > Sent: Monday, June 23, 2008 5:52 AM > To: Vijay Devarapalli; Behcet Sarikaya; Julien Laganier > Cc: mext@ietf.org > Subject: RE: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > = > Hi Vijay, > = > I've not seen a consensus call on this and I'm sorry if I = > missed it. If there was none than let us have one with all = > the arguments from all parties on the table. There was no consensus call on this. But there were quite a few = emails sent on this topic. My conclusion from that discussion = was that most people agreed with removing extensions to DHAAD = from the prefix delegation document. I don't believe it is = Necessary, but we could have an explicit consensus call on this. Julien, Marcelo? > My point is that this PD draft extends a family started with = > 3775 and 3963. This is why I think it makes sense to be = > consistent between the 3. People do not have to call their = > lawyer to figure how discovery is done depending on which MIP = > feature we are talking about. First of all, the HA discovery mechanisms that are likely to be = used are either DNS-based or integrated scenario-based. While = DHAAD is a useful tool for testing, I don't think it will get = used or deployed. If you feel that we MUST define a mechanism = to discover a DHCPv6-PD capable home agent, then we are better = off extending the DNS-based or integrated scenario mechanisms. = FWIW, I don't think this is necessary. We have mechanisms for = the mobile router to try other home agents and/or to recover = from the error. = I also believe it was not necessary to extend DHAAD in RFC 3963. = If and when we revise 3963, I would support removing the DHAAD = extensions. = Vijay > What I do disagree with is your idea of trying all the HAs = > found in MIP/NEMO DHAAD till one HA is found that supports = > PD. I think that this is what does not make lots of sense... > = > Pascal > = > >-----Original Message----- > >From: Vijay Devarapalli [mailto:vijay@wichorus.com] > >Sent: vendredi 20 juin 2008 20:26 > >To: Pascal Thubert (pthubert); Behcet Sarikaya; Julien Laganier > >Cc: mext@ietf.org > >Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > > >Hi Pascal, > > > >I believe there was reasonable consensus on removing the = > DHAAD extensions in > >the NEMO prefix delegation document, when were discussing = > adoption of the > >draft as a WG document. > > > >Many had argued said there is no need to extend DHAAD in the = > first place for > >prefix delegation. Perhaps you missed those emails buried in = > the emails on > >DHAAD deprecation. So your argument below that since it is = > there in 3776 and > >3963, it should be in the prefix delegation document, does = > not make sense to > >me. > > > >Vijay > > > > > >On 6/20/08 12:28 AM, "Pascal Thubert (pthubert)" = > wrote: > > > >> Hi Behcet > >> > >> The PD draft is consistent with its parent RFCs 3775 and = > 3963. If the group > >> agrees in some future that DHAAD should be deprecated, = > then we=B9ll need to > >> revise all 3 documents. What=B9s important IMHO is to keep = > them consistent. > >> > >> > >> Pascal > >> > >> > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] = > On Behalf Of Behcet > >> Sarikaya > >> Sent: mercredi 18 juin 2008 17:34 > >> To: Julien Laganier > >> Cc: mext@ietf.org > >> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > >> > >> > >> Yes. The reason is simple, look at this draft: > >> http://tools.ietf.org/id/draft-dupont-mext-dhaadharmful-00.txt > >> > >> Regards, > >> > >> Behcet > >> > >> ----- Original Message ---- > >> From: Julien Laganier > >> To: mext@ietf.org; Behcet Sarikaya > >> Sent: Wednesday, June 18, 2008 10:29:27 AM > >> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > >> > >> On Wednesday 18 June 2008, Behcet Sarikaya wrote: > >>> Well, I was just wondering if its coauthors agree with this text ? > >> > >> Well, then I'm still wondering what you're wondering = > about... Are you > >> asking whether or not coauthors of the draft agree with the draft?! > >> > >> --julien > >> > >>> ----- Original Message ---- > >>> From: Julien Laganier > >>> To: Behcet Sarikaya > >>> Cc: mext@ietf.org > >>> Sent: Wednesday, June 18, 2008 4:00:49 AM > >>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > >>> > >>> Behcet, > >>> > >>> I'm wondering what you're wondering about -- the message I sent > >>> (excerpt below) is quite explicit, isn't it? > >>> > >>>> We have a WG consensus to adopt = > draft-droms-mext-nemo-pd-00.txt as > >>>> a WG draft corresponding to the Nemo Prefix Delegation work item. > >>>> > >>>> Authors, please resubmit the draft as WG draft under the name: > >>>> > >>>> draft-ietf-mext-nemo-pd-00.txt > >>> > >>> --julien > >>> > >>> On Tuesday 17 June 2008, Behcet Sarikaya wrote: > >>>> Hi Julien, > >>>> It seems like draft-ietf-mext-nemo-pd-00.txt does not carry any > >>>> changes based on the long and heated debates we had on > >>>> draft-droms-mext-nemo-pd-00.txt. It is a keep-alive version. Is > >>>> this what you expected from the authors? > >>>> > >>>> Regards, > >>>> > >>>> Behcet > >>>> > >>>> > >>>> ----- Original Message ---- > >>>> From: Julien Laganier > >>>> To: draft-droms-mext-nemo-pd@tools.ietf.org > >>>> Cc: mext@ietf.org > >>>> Sent: Friday, June 13, 2008 10:42:14 AM > >>>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > >>>> > >>>> Folks, > >>>> > >>>> We have a WG consensus to adopt = > draft-droms-mext-nemo-pd-00.txt as > >>>> a WG draft corresponding to the Nemo Prefix Delegation work item. > >>>> > >>>> Authors, please resubmit the draft as WG draft under the name: > >>>> > >>>> draft-ietf-mext-nemo-pd-00.txt > >>>> > >>>> Note: you can use the online I-D submission tool to make = > it faster: > >>>> > >>>> > >>>> Thanks. > >>>> > >>>> --julien & marcelo, MEXT chairs. > >>>> > >>>> On Friday 30 May 2008, marcelo bagnulo braun wrote: > >>>>> Hi, > >>>>> > >>>>> We would like to ask the WG what is their opinion about = > accepting > >>>>> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo > >>>>> PD deliverable included in our charter. > >>>>> > >>>>> Please provide comments so we cna make some progress on = > this long > >>>>> overdue deliverable > >>>>> > >>>>> thanks, Julien and marcelo > >>>>> > >>>>> -------- Mensaje original -------- > >>>>> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt > >>>>> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) > >>>>> De: Internet-Drafts@ietf.org > >>>>> Responder a: internet-drafts@ietf.org > >>>>> Para: i-d-announce@ietf.org > >>>>> > >>>>> > >>>>> > >>>>> A New Internet-Draft is available from the on-line > >>>>> Internet-Drafts directories. > >>>>> > >>>>> Title : DHCPv6 Prefix Delegation for NEMO > >>>>> Author(s) : R. Droms, et al. > >>>>> Filename : draft-droms-mext-nemo-pd-00.txt > >>>>> Pages : 12 > >>>>> Date : 2008-05-30 > >>>>> > >>>>> One aspect of network mobility support is the assignment of a > >>>>> prefix or prefixes to a Mobile Router (MR) for use on the links > >>>>> in the Mobile Network. DHCPv6 prefix delegation can be used for > >>>>> this configuration task. > >>>>> > >>>>> A URL for this Internet-Draft is: > >>>>> = > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.t > >>>>> xt > >>>>> > >>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>> > >>>>> Below is the data which will enable a MIME compliant mail reader > >>>>> implementation to automatically retrieve the ASCII = > version of the > >>>>> Internet-Draft. > >>>> > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mext > >> > >> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > = > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From c.medina@ibauma.com Mon Jun 23 16:19:08 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9539E3A69DB; Mon, 23 Jun 2008 16:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -68.579 X-Spam-Level: X-Spam-Status: No, score=-68.579 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sdkp0-V36fY; Mon, 23 Jun 2008 16:19:07 -0700 (PDT) Received: from 196-190-223-201.adsl.terra.cl (196-190-223-201.adsl.terra.cl [201.223.190.196]) by core3.amsl.com (Postfix) with SMTP id 7FB903A688B; Mon, 23 Jun 2008 16:18:57 -0700 (PDT) X-Originating-IP: 10.112.6.58 by smtp.201.223.190.196; Mon, 23 Jun 2008 19:18:59 -0500 Message-ID: From: "Earline Winkler" Reply-To: "Earline Winkler" To: nemo-archive@ietf.org Subject: You and a Rolex watch Date: Mon, 23 Jun 2008 19:18:59 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Diamond Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://wocogesokes83.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://wocogesokes83.blogspot.com/ From nemo-bounces@ietf.org Mon Jun 23 16:19:09 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BB6A3A6A6E for ; Mon, 23 Jun 2008 16:19:09 -0700 (PDT) Subject: The results of your email commands From: nemo-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0823757126==" Message-ID: Date: Mon, 23 Jun 2008 16:19:08 -0700 Precedence: bulk X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NEMO Working Group X-List-Administrivia: yes Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --===============0823757126== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://wocogesokes83.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://wocogesokes83.blogspot.com/ - Done. --===============0823757126== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nemo-request@core3.amsl.com Delivered-To: nemo-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9539E3A69DB; Mon, 23 Jun 2008 16:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -68.579 X-Spam-Level: X-Spam-Status: No, score=-68.579 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sdkp0-V36fY; Mon, 23 Jun 2008 16:19:07 -0700 (PDT) Received: from 196-190-223-201.adsl.terra.cl (196-190-223-201.adsl.terra.cl [201.223.190.196]) by core3.amsl.com (Postfix) with SMTP id 7FB903A688B; Mon, 23 Jun 2008 16:18:57 -0700 (PDT) X-Originating-IP: 10.112.6.58 by smtp.201.223.190.196; Mon, 23 Jun 2008 19:18:59 -0500 Message-ID: From: "Earline Winkler" Reply-To: "Earline Winkler" To: nemo-archive@ietf.org Subject: You and a Rolex watch Date: Mon, 23 Jun 2008 19:18:59 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Diamond Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://wocogesokes83.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://wocogesokes83.blogspot.com/ --===============0823757126==-- From nfsv4-bounces@ietf.org Mon Jun 23 16:19:09 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E5903A6A7B for ; Mon, 23 Jun 2008 16:19:09 -0700 (PDT) Subject: The results of your email commands From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0387736588==" Message-ID: Date: Mon, 23 Jun 2008 16:19:08 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org --===============0387736588== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://wocogesokes83.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://wocogesokes83.blogspot.com/ - Done. --===============0387736588== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nfsv4-request@core3.amsl.com Delivered-To: nfsv4-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9539E3A69DB; Mon, 23 Jun 2008 16:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -68.579 X-Spam-Level: X-Spam-Status: No, score=-68.579 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sdkp0-V36fY; Mon, 23 Jun 2008 16:19:07 -0700 (PDT) Received: from 196-190-223-201.adsl.terra.cl (196-190-223-201.adsl.terra.cl [201.223.190.196]) by core3.amsl.com (Postfix) with SMTP id 7FB903A688B; Mon, 23 Jun 2008 16:18:57 -0700 (PDT) X-Originating-IP: 10.112.6.58 by smtp.201.223.190.196; Mon, 23 Jun 2008 19:18:59 -0500 Message-ID: From: "Earline Winkler" Reply-To: "Earline Winkler" To: nemo-archive@ietf.org Subject: You and a Rolex watch Date: Mon, 23 Jun 2008 19:18:59 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Diamond Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://wocogesokes83.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://wocogesokes83.blogspot.com/ --===============0387736588==-- From nsis-bounces@ietf.org Mon Jun 23 16:19:09 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91ABF3A6A6E for ; Mon, 23 Jun 2008 16:19:09 -0700 (PDT) Subject: The results of your email commands From: nsis-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0601289027==" Message-ID: Date: Mon, 23 Jun 2008 16:19:08 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============0601289027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://wocogesokes83.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://wocogesokes83.blogspot.com/ - Done. --===============0601289027== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nsis-request@core3.amsl.com Delivered-To: nsis-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9539E3A69DB; Mon, 23 Jun 2008 16:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -68.579 X-Spam-Level: X-Spam-Status: No, score=-68.579 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sdkp0-V36fY; Mon, 23 Jun 2008 16:19:07 -0700 (PDT) Received: from 196-190-223-201.adsl.terra.cl (196-190-223-201.adsl.terra.cl [201.223.190.196]) by core3.amsl.com (Postfix) with SMTP id 7FB903A688B; Mon, 23 Jun 2008 16:18:57 -0700 (PDT) X-Originating-IP: 10.112.6.58 by smtp.201.223.190.196; Mon, 23 Jun 2008 19:18:59 -0500 Message-ID: From: "Earline Winkler" Reply-To: "Earline Winkler" To: nemo-archive@ietf.org Subject: You and a Rolex watch Date: Mon, 23 Jun 2008 19:18:59 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Diamond Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://wocogesokes83.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://wocogesokes83.blogspot.com/ --===============0601289027==-- From netconf-bounces@ietf.org Mon Jun 23 16:19:09 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939833A6A7B for ; Mon, 23 Jun 2008 16:19:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to Netconf awaits moderator approval From: netconf-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 16:19:08 -0700 Precedence: bulk X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 List-Id: Network Configuration WG mailing list X-List-Administrivia: yes Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Your mail to 'Netconf' with the subject You and a Rolex watch Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netconf/db6df4468c2762ada520bd3c4ec84b74376878ec From netlmm-bounces@ietf.org Mon Jun 23 16:19:09 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9771D3A6A7B for ; Mon, 23 Jun 2008 16:19:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to netlmm awaits moderator approval From: netlmm-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 16:19:08 -0700 Precedence: bulk X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETLMM working group discussion list X-List-Administrivia: yes Sender: netlmm-bounces@ietf.org Errors-To: netlmm-bounces@ietf.org Your mail to 'netlmm' with the subject You and a Rolex watch Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netlmm/230e6b0d92308023db9a7e838e829531915a3ee0 From nfsv4-bounces@ietf.org Mon Jun 23 16:19:10 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B62E3A6A6E for ; Mon, 23 Jun 2008 16:19:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nfsv4 awaits moderator approval From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 16:19:08 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org Your mail to 'nfsv4' with the subject You and a Rolex watch Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nfsv4/2bb91361e518aad8c91b2900ddf9d3edadde01bf From ngo-bounces@ietf.org Mon Jun 23 16:19:10 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EDB63A6A91 for ; Mon, 23 Jun 2008 16:19:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NGO awaits moderator approval From: ngo-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 16:19:09 -0700 Precedence: bulk X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF X-List-Administrivia: yes Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Your mail to 'NGO' with the subject You and a Rolex watch Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ngo/ed24dfd679f9fc215891411aa943e8b5992ebe0d From ntdp-bounces@ietf.org Mon Jun 23 16:19:10 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A448C3A6A9D for ; Mon, 23 Jun 2008 16:19:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NTDP awaits moderator approval From: ntdp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 16:19:09 -0700 Precedence: bulk X-BeenThere: ntdp@ietf.org X-Mailman-Version: 2.1.9 List-Id: define standards for the purpose of scripting of network testing equipment X-List-Administrivia: yes Sender: ntdp-bounces@ietf.org Errors-To: ntdp-bounces@ietf.org Your mail to 'NTDP' with the subject You and a Rolex watch Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ntdp/f6db108656275cc52b078ea3e991ce119a33f17b From nsis-imp-bounces@ietf.org Mon Jun 23 16:19:10 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A89FD3A6AB0 for ; Mon, 23 Jun 2008 16:19:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NSIS-imp awaits moderator approval From: nsis-imp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 16:19:09 -0700 Precedence: bulk X-BeenThere: nsis-imp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for implementation questions for NSIS protocols X-List-Administrivia: yes Sender: nsis-imp-bounces@ietf.org Errors-To: nsis-imp-bounces@ietf.org Your mail to 'NSIS-imp' with the subject You and a Rolex watch Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis-imp/72c2906435bf0051b24e9a18571886c5b6f34870 From nsis-bounces@ietf.org Mon Jun 23 16:19:10 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADD453A6A9D for ; Mon, 23 Jun 2008 16:19:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nsis awaits moderator approval From: nsis-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Mon, 23 Jun 2008 16:19:09 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Your mail to 'nsis' with the subject You and a Rolex watch Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis/d168d40d5ff3fce9e142a36178acfe4d93a11525 From mext-bounces@ietf.org Tue Jun 24 03:19:17 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B78693A6861; Tue, 24 Jun 2008 03:19:17 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F153A6861 for ; Tue, 24 Jun 2008 03:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAODFs4bn7iI for ; Tue, 24 Jun 2008 03:19:15 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 9C0B83A6845 for ; Tue, 24 Jun 2008 03:19:15 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so7883104rvf.49 for ; Tue, 24 Jun 2008 03:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:sender; bh=iHXHVg6gB2h+09clokzNui+xuWUTlLpd5HVuCjo9/GM=; b=Gg1lYCcaejfVfLsQzvQ8h/lMlhPRpfR82yMYDxXSjtoEcB9UxQnvddjoas+/FmT0jz A5aS4B8bCEPaPLCU3auQ1h2uem9F48n6vi6g6aWjNwdZvYxpgw7orje5VeKuxJ1TBNd2 y5YS9rw6ghRpdXh4sfcP8gH4KYo4CQ0HETiK8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :sender; b=ZRSIkcM6/22jfCluw5blN9vxDznhPXkLB3vWN+kXSHoRKFYH7U7BSGK7L0uoqv+Zna GCEgmOo5p3ZZ41SHUg2zHNwyHUWBJOUYKst2r8bvNX3QNq7mDEZU9TdaN0mq2nDmnF/b m5jGnl68QNxUdh+fYvrQb8n7l5UjpEBzR2N00= Received: by 10.141.172.6 with SMTP id z6mr14512040rvo.91.1214302753680; Tue, 24 Jun 2008 03:19:13 -0700 (PDT) Received: from ?192.168.100.94? ( [89.201.163.12]) by mx.google.com with ESMTPS id 31sm9450839wri.14.2008.06.24.03.19.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Jun 2008 03:19:12 -0700 (PDT) Message-ID: <4860CA21.7060200@laposte.net> Date: Tue, 24 Jun 2008 12:19:13 +0200 From: Julien Laganier User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Vijay Devarapalli References: <7892795E1A87F04CADFCCF41FADD00FC05DC3DE2@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05DC4567@xmb-ams-337.emea.cisco.com> In-Reply-To: Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay and Pascal, Vijay Devarapalli wrote: > Hi Pascal, > >> -----Original Message----- >> From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] >> Sent: Monday, June 23, 2008 5:52 AM >> To: Vijay Devarapalli; Behcet Sarikaya; Julien Laganier >> Cc: mext@ietf.org >> Subject: RE: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> >> Hi Vijay, >> >> I've not seen a consensus call on this and I'm sorry if I >> missed it. If there was none than let us have one with all >> the arguments from all parties on the table. > > There was no consensus call on this. But there were quite a few > emails sent on this topic. My conclusion from that discussion > was that most people agreed with removing extensions to DHAAD > from the prefix delegation document. I don't believe it is > Necessary, but we could have an explicit consensus call on this. > Julien, Marcelo? We do not necessary need a consensus call for every decision -- the consensus can appear by itself as the result of the discussion, consensus call is only needed in case no clear consensus appears after the discussion has ran for some time. So the question is, do you think all the arguments have been expressed already and we're now rehashing the same ones? In case the answer is yes, I'm happy to proceed with issuing a consensus call on the DHAAD for NEMO-PD issue. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 24 05:07:56 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1BDE3A69B2; Tue, 24 Jun 2008 05:07:56 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C433A69B2 for ; Tue, 24 Jun 2008 05:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlf+WnB8tdUU for ; Tue, 24 Jun 2008 05:07:55 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.245.51]) by core3.amsl.com (Postfix) with SMTP id 3107F3A6994 for ; Tue, 24 Jun 2008 05:07:54 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1214309270!24500640!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 22211 invoked from network); 24 Jun 2008 12:07:50 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-119.messagelabs.com with SMTP; 24 Jun 2008 12:07:50 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m5OC7od0007484 for ; Tue, 24 Jun 2008 05:07:50 -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 m5OC7nm5028895 for ; Tue, 24 Jun 2008 07:07:49 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id m5OC7ma7028880 for ; Tue, 24 Jun 2008 07:07:49 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 13:07:48 +0100 Message-ID: <4860E393.8040400@gmail.com> Date: Tue, 24 Jun 2008 14:07:47 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Vijay Devarapalli References: <7892795E1A87F04CADFCCF41FADD00FC05DC3DE2@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05DC4567@xmb-ams-337.emea.cisco.com> In-Reply-To: X-Antivirus: avast! (VPS 080623-0, 23/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 24 Jun 2008 12:07:48.0129 (UTC) FILETIME=[EAFCB110:01C8D5F2] X-CFilter-Loop: Reflected Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, Vijay Devarapalli wrote: [...] > First of all, the HA discovery mechanisms that are likely to be used > are either DNS-based or integrated scenario-based. Where was a DNS-based HA discovery mechanism experimented, prototyped, shown? > While DHAAD is a useful tool for testing, I don't think it will get > used or deployed. I have seen DHAAD used for testing in my lab, with two different implementations. Or should I assume that you make deployment statements relying _only_ on SDO requirements? 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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jun 24 10:55:11 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254DA3A6951; Tue, 24 Jun 2008 10:55:11 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7341E3A6951 for ; Tue, 24 Jun 2008 10:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Scq90aSkCQIw for ; Tue, 24 Jun 2008 10:55:09 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 8E8283A68A0 for ; Tue, 24 Jun 2008 10:55:09 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 13:55:07 -0400 Message-ID: In-Reply-To: <4860CA21.7060200@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Thread-Index: AcjV48K2OCFigBjtTtK/Luy7sv25PgAP46Pg References: <7892795E1A87F04CADFCCF41FADD00FC05DC3DE2@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05DC4567@xmb-ams-337.emea.cisco.com> <4860CA21.7060200@laposte.net> From: "Vijay Devarapalli" To: "Julien Laganier" Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > >> -----Original Message----- > >> From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > >> Sent: Monday, June 23, 2008 5:52 AM > >> To: Vijay Devarapalli; Behcet Sarikaya; Julien Laganier > >> Cc: mext@ietf.org > >> Subject: RE: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > >> > >> Hi Vijay, > >> > >> I've not seen a consensus call on this and I'm sorry if I > >> missed it. If there was none than let us have one with all > >> the arguments from all parties on the table. > > > > There was no consensus call on this. But there were quite a few > > emails sent on this topic. My conclusion from that discussion > > was that most people agreed with removing extensions to DHAAD > > from the prefix delegation document. I don't believe it is > > Necessary, but we could have an explicit consensus call on this. > > Julien, Marcelo? > > We do not necessary need a consensus call for every decision -- the > consensus can appear by itself as the result of the discussion, > consensus call is only needed in case no clear consensus > appears after > the discussion has ran for some time. Exactly. Pascal, please review the earlier thread. If you still think we need an explicit consensus call, let the chairs know. Vijay > > So the question is, do you think all the arguments have been > expressed > already and we're now rehashing the same ones? In case the answer is > yes, I'm happy to proceed with issuing a consensus call on > the DHAAD for > NEMO-PD issue. > > --julien > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From c3025x@wellingtonschool.com Tue Jun 24 21:38:27 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F1E328C12B; Tue, 24 Jun 2008 21:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -64.421 X-Spam-Level: X-Spam-Status: No, score=-64.421 tagged_above=-999 required=5 tests=[BAYES_60=1, FB_QUALITY_REPLICA=10.357, GB_ROLEX=5, HELO_EQ_MINDSPRING=0.45, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MINDSPRING=2.2, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3vckF5sRG1t; Tue, 24 Jun 2008 21:38:26 -0700 (PDT) Received: from user-387hllp.cable.mindspring.com (user-387hllp.cable.mindspring.com [208.120.214.185]) by core3.amsl.com (Postfix) with SMTP id F344E3A692E; Tue, 24 Jun 2008 21:38:23 -0700 (PDT) X-Originating-IP: 245.72.32.92 by smtp.208.120.214.185; Wed, 25 Jun 2008 00:38:26 -0500 Message-ID: From: "Shari Forrest" Reply-To: "Shari Forrest" To: nemo-archive@ietf.org Subject: Watches made to impress Date: Wed, 25 Jun 2008 00:38:26 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Diamond Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://www.geocities.com/garymokum Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://www.geocities.com/garymokum From nfsv4-bounces@ietf.org Tue Jun 24 21:38:28 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9214F3A69B9 for ; Tue, 24 Jun 2008 21:38:28 -0700 (PDT) Subject: The results of your email commands From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0553317175==" Message-ID: Date: Tue, 24 Jun 2008 21:38:27 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org --===============0553317175== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://www.geocities.com/garymokum Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://www.geocities.com/garymokum - Done. --===============0553317175== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nfsv4-request@core3.amsl.com Delivered-To: nfsv4-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F1E328C12B; Tue, 24 Jun 2008 21:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -64.421 X-Spam-Level: X-Spam-Status: No, score=-64.421 tagged_above=-999 required=5 tests=[BAYES_60=1, FB_QUALITY_REPLICA=10.357, GB_ROLEX=5, HELO_EQ_MINDSPRING=0.45, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MINDSPRING=2.2, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3vckF5sRG1t; Tue, 24 Jun 2008 21:38:26 -0700 (PDT) Received: from user-387hllp.cable.mindspring.com (user-387hllp.cable.mindspring.com [208.120.214.185]) by core3.amsl.com (Postfix) with SMTP id F344E3A692E; Tue, 24 Jun 2008 21:38:23 -0700 (PDT) X-Originating-IP: 245.72.32.92 by smtp.208.120.214.185; Wed, 25 Jun 2008 00:38:26 -0500 Message-ID: From: "Shari Forrest" Reply-To: "Shari Forrest" To: nemo-archive@ietf.org Subject: Watches made to impress Date: Wed, 25 Jun 2008 00:38:26 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Diamond Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://www.geocities.com/garymokum Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://www.geocities.com/garymokum --===============0553317175==-- From nemo-bounces@ietf.org Tue Jun 24 21:38:28 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7D43A6A78 for ; Tue, 24 Jun 2008 21:38:28 -0700 (PDT) Subject: The results of your email commands From: nemo-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0358470979==" Message-ID: Date: Tue, 24 Jun 2008 21:38:27 -0700 Precedence: bulk X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NEMO Working Group X-List-Administrivia: yes Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --===============0358470979== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://www.geocities.com/garymokum Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://www.geocities.com/garymokum - Done. --===============0358470979== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nemo-request@core3.amsl.com Delivered-To: nemo-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F1E328C12B; Tue, 24 Jun 2008 21:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -64.421 X-Spam-Level: X-Spam-Status: No, score=-64.421 tagged_above=-999 required=5 tests=[BAYES_60=1, FB_QUALITY_REPLICA=10.357, GB_ROLEX=5, HELO_EQ_MINDSPRING=0.45, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MINDSPRING=2.2, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3vckF5sRG1t; Tue, 24 Jun 2008 21:38:26 -0700 (PDT) Received: from user-387hllp.cable.mindspring.com (user-387hllp.cable.mindspring.com [208.120.214.185]) by core3.amsl.com (Postfix) with SMTP id F344E3A692E; Tue, 24 Jun 2008 21:38:23 -0700 (PDT) X-Originating-IP: 245.72.32.92 by smtp.208.120.214.185; Wed, 25 Jun 2008 00:38:26 -0500 Message-ID: From: "Shari Forrest" Reply-To: "Shari Forrest" To: nemo-archive@ietf.org Subject: Watches made to impress Date: Wed, 25 Jun 2008 00:38:26 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Diamond Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://www.geocities.com/garymokum Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://www.geocities.com/garymokum --===============0358470979==-- From nsis-bounces@ietf.org Tue Jun 24 21:38:29 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F163A3A6A78 for ; Tue, 24 Jun 2008 21:38:28 -0700 (PDT) Subject: The results of your email commands From: nsis-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1156840640==" Message-ID: Date: Tue, 24 Jun 2008 21:38:27 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============1156840640== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://www.geocities.com/garymokum Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://www.geocities.com/garymokum - Done. --===============1156840640== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nsis-request@core3.amsl.com Delivered-To: nsis-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F1E328C12B; Tue, 24 Jun 2008 21:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -64.421 X-Spam-Level: X-Spam-Status: No, score=-64.421 tagged_above=-999 required=5 tests=[BAYES_60=1, FB_QUALITY_REPLICA=10.357, GB_ROLEX=5, HELO_EQ_MINDSPRING=0.45, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MINDSPRING=2.2, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3vckF5sRG1t; Tue, 24 Jun 2008 21:38:26 -0700 (PDT) Received: from user-387hllp.cable.mindspring.com (user-387hllp.cable.mindspring.com [208.120.214.185]) by core3.amsl.com (Postfix) with SMTP id F344E3A692E; Tue, 24 Jun 2008 21:38:23 -0700 (PDT) X-Originating-IP: 245.72.32.92 by smtp.208.120.214.185; Wed, 25 Jun 2008 00:38:26 -0500 Message-ID: From: "Shari Forrest" Reply-To: "Shari Forrest" To: nemo-archive@ietf.org Subject: Watches made to impress Date: Wed, 25 Jun 2008 00:38:26 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Diamond Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://www.geocities.com/garymokum Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://www.geocities.com/garymokum --===============1156840640==-- From netlmm-bounces@ietf.org Tue Jun 24 21:38:30 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097393A6882 for ; Tue, 24 Jun 2008 21:38:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to netlmm awaits moderator approval From: netlmm-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Tue, 24 Jun 2008 21:38:28 -0700 Precedence: bulk X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETLMM working group discussion list X-List-Administrivia: yes Sender: netlmm-bounces@ietf.org Errors-To: netlmm-bounces@ietf.org Your mail to 'netlmm' with the subject Watches made to impress Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netlmm/1765e814e4e959073c4f889071a83ce6be1ce95b From ngo-bounces@ietf.org Tue Jun 24 21:38:30 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1873328C129 for ; Tue, 24 Jun 2008 21:38:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NGO awaits moderator approval From: ngo-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Tue, 24 Jun 2008 21:38:28 -0700 Precedence: bulk X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF X-List-Administrivia: yes Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Your mail to 'NGO' with the subject Watches made to impress Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ngo/3057fa057d9ccb74dfd88237fae02c2b0a7d3ca7 From nfsv4-bounces@ietf.org Tue Jun 24 21:38:30 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23CAD28C129 for ; Tue, 24 Jun 2008 21:38:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nfsv4 awaits moderator approval From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Tue, 24 Jun 2008 21:38:28 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org Your mail to 'nfsv4' with the subject Watches made to impress Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nfsv4/285018dd71f2dd1a704427abbe73913b0dbb0082 From nsis-imp-bounces@ietf.org Tue Jun 24 21:38:30 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C8F28C129 for ; Tue, 24 Jun 2008 21:38:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NSIS-imp awaits moderator approval From: nsis-imp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Tue, 24 Jun 2008 21:38:29 -0700 Precedence: bulk X-BeenThere: nsis-imp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for implementation questions for NSIS protocols X-List-Administrivia: yes Sender: nsis-imp-bounces@ietf.org Errors-To: nsis-imp-bounces@ietf.org Your mail to 'NSIS-imp' with the subject Watches made to impress Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis-imp/59409ecbe6d07b72ce40bb7eac804336c46271a9 From ntdp-bounces@ietf.org Tue Jun 24 21:38:30 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EB8F28C129 for ; Tue, 24 Jun 2008 21:38:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NTDP awaits moderator approval From: ntdp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Tue, 24 Jun 2008 21:38:29 -0700 Precedence: bulk X-BeenThere: ntdp@ietf.org X-Mailman-Version: 2.1.9 List-Id: define standards for the purpose of scripting of network testing equipment X-List-Administrivia: yes Sender: ntdp-bounces@ietf.org Errors-To: ntdp-bounces@ietf.org Your mail to 'NTDP' with the subject Watches made to impress Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ntdp/4971c0f8a8da872bfccd9381be5969d04a2616a1 From nsis-bounces@ietf.org Tue Jun 24 21:38:30 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3493728C129 for ; Tue, 24 Jun 2008 21:38:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nsis awaits moderator approval From: nsis-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Tue, 24 Jun 2008 21:38:29 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Your mail to 'nsis' with the subject Watches made to impress Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis/3eaa9f2004afd89d5ef4c783cbc5e2d1e1155dc3 From mext-bounces@ietf.org Wed Jun 25 00:29:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FB093A681D; Wed, 25 Jun 2008 00:29:45 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C768A3A6848 for ; Wed, 25 Jun 2008 00:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJDNbAw558WZ for ; Wed, 25 Jun 2008 00:29:42 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 20C783A681D for ; Wed, 25 Jun 2008 00:29:41 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5P7TNfs031438 for ; Wed, 25 Jun 2008 10:29:41 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 10:29:33 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 10:29:33 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 10:29:31 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72FD36B0@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: IP Security Maintenance and Extensions (ipsecme) Thread-Index: AcjWF57d/96p82bISCmdmbuVhjd7DgAfXEbQ From: To: X-OriginalArrivalTime: 25 Jun 2008 07:29:33.0033 (UTC) FILETIME=[3658F590:01C8D695] X-Nokia-AV: Clean Subject: [MEXT] FW: WG Review: IP Security Maintenance and Extensions (ipsecme) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org FYI (in case you don't follow ietf-announce): some of the proposed work items might be of interest to people using IPsec to protect Mobile IPv6. -Pasi -----Original Message----- From: IESG Secretary Sent: 24 June, 2008 19:30 To: ietf-announce@ietf.org Cc: ipsec@ietf.org Subject: WG Review: IP Security Maintenance and Extensions (ipsecme) A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, July 1, 2008. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ Last Modified: June 19, 2008 Current Status: Proposed Working Group Chair(s): TBD Mailing Lists: General Discussion: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group will continue the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions and improvements to IPsec, mostly to IKEv2. The working group will also be a focus point for other IETF Working Groups who use IPsec in their own protocols. The initial set of work items is: - A revision to IKEv2 (RFC 4306) that incorporates the clarifications from RFC 4718, and otherwise improves the quality of the specification, taking into account implementation and interoperability experience. In some cases, the revision may include small technical corrections; however, impact on existing implementations must be considered. Major changes and adding new features is beyond the scope of this work item. The starting point for this work is draft-hoffman-ikev2bis. - An IPsec document roadmap that describes the various RFC documents covering IPsec, including both the core RFC 240x and RFC 430x versions of IPsec, and extensions specified in other documents. Sections 2 and 3 of RFC 2411 can provide useful material, but the expected scope is slightly different from RFC 2411. This document will be informational. - A standards-track extension to IKEv2 that provides full IPv6 support for IPsec remote access clients that use configuration payloads. This work will be based on draft-eronen-ipsec-ikev2-ipv6-config. The WG shall solicit help and reviews from the 6MAN WG to ensure that all aspects of IPv6 are properly considered. - A standards-track extension that allows an IPsec remote access client to "resume" a session with a gateway; that is, to skip certain parts of IKE negotation when connecting again to the same gateway (or possibly a cluster of closely cooperating gateways). The idea is similar to TLS session resumption without server-side state, specified in RFC 5077. The main goals for this extension are to avoid public-key computations (to reduce VPN gateway load when a large number of clients reconnect to the geteway within a short period of time, such as following a network outage), and remove the need for user interaction for authentication (which may be required by some authentication mechanisms). The extension shall not have negative impact on IKEv2 security features. Failover from one gateway to another, mechanisms for detecting when a session should be resumed, and specifying communication mechanisms between gateways are beyond the scope of this work item. Specifying the detailed contents of the "session ticket" is also beyond the scope of this document; if there is sufficient interest, this could be specified later in a separate document. To the degree its content falls within the scope of this work item, text and ideas from draft-sheffer-ipsec-failover will be used as a starting point. - A standards-track extension to IPsec that allows an IPsec remote access gateway to redirect VPN clients to another gateway. This extension should be aligned with the session resumption extension, (the previous work item), and if so decided by the WG, could be specified in the same document. The starting point will be draft-devarapalli-ipsec-ikev2-redirect. - A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet. The starting points for this work item are draft-grewal-ipsec-traffic-visibility and draft-hoffman- esp-null-protocol. The initial scope of the WG is restricted to the work items listed above. The WG shall not consider adding new work items until one or more of its documents progress to IESG evaluation. At that time, the WG can propose rechartering. Chartering this WG is not intended to have effect on documents that beyond the initial scope. In particular, work on IPsec extensions that are not included in this charter can happen as usual in other WGs (and there are currently several other WGs working on IPsec extensions; for example, BTNS and ROHC), or as individual submissions. This charter will expire in July 2010 (24 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Milestones: Dec 2008 WG last call on IPv6 configuration payloads Dec 2008 WG last call on IPsec roadmap Jan 2009 WG last call on session resumption Feb 2009 WG last call on redirect Mar 2009 WG last call on IKEv2bis Apr 2009 WG last call on ESP NULL traffic visibility _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 25 06:18:38 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC4C3A69D2; Wed, 25 Jun 2008 06:18:38 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B7513A69D2 for ; Wed, 25 Jun 2008 06:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLw1sNsJ0wqn for ; Wed, 25 Jun 2008 06:18:30 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1B6033A6851 for ; Wed, 25 Jun 2008 06:18:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,702,1204498800"; d="scan'208";a="12642205" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 25 Jun 2008 15:18:30 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5PDIU4b010538; Wed, 25 Jun 2008 15:18:30 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5PDIUYm012951; Wed, 25 Jun 2008 13:18:30 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); Wed, 25 Jun 2008 15:18:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 15:17:54 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05E1862E@xmb-ams-337.emea.cisco.com> In-Reply-To: <4860CA21.7060200@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Thread-Index: AcjV48U4UCLaJGg0RO2QP0Wg0IsC6QA3QMpQ References: <7892795E1A87F04CADFCCF41FADD00FC05DC3DE2@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05DC4567@xmb-ams-337.emea.cisco.com> <4860CA21.7060200@laposte.net> From: "Pascal Thubert (pthubert)" To: "Julien Laganier" , "Vijay Devarapalli" X-OriginalArrivalTime: 25 Jun 2008 13:18:30.0044 (UTC) FILETIME=[F5C74DC0:01C8D6C5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3513; t=1214399910; x=1215263910; 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]=20Adoption=20of=20draft-droms-me xt-nemo-pd-00.txt? |Sender:=20; bh=vZ5VF4lWuUyjxzR5HC1oZ1kuyy1+ZeMhzNu7I3Y0V0E=; b=k9Ms+uzZpJwWMDXaonUF2d0MSS0EUmUkv9RpEopXRGe3hvLLElfEILNCHd STnQkkMnxGGt0XZ81CSKojkvL9kTaUp2H1nIsZljdSyItD+8NplL90TQRlCj GI3u9CS8V8; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien: I have seen some discussions and I do not think that there is consensus on the specific matter of removing the DHAAD based discovery from this draft. If I did, I would have retracted the text already. What I've seen is people interested in deprecating DHAAD which is a different thing. I think there is confusion between a vision of a better future and the practical work of adding a simple extension to an existing protocol. Right now the MIP protocol suite still uses dhaad. A NEMO MR will set the R bit to filter out HAs that do not support NEMO on top of MIP. It just makes sense for the same MR to set the next bit to filter out HAs that do not support PD on top of NEMO. Simple update, no new message or FSM state. I did not find a convincing alternate either. Making an additional DNS request adds complexity whereas the idea scanning and binding to all HAs in the DHAAD list till the PD request works makes very little sense to me. Finally, making the bootstrap mechanism a prereq to PD is an undesirable dependency and as a vendor I would not want such an artifact to impact my product planning. In a same spirit, I disagree with obsoleting DHAAD in NEMO if we keep it in MIP. Yet I'm not saying that Vijay is wrong. He might be very right to push DHAAD out through the window. My point is that we must be consistent with ourselves. Should we deprecate DHAAD, I think we should define a new discovery that does it all and obsolete the whole suite of protocols so that the new flow is not heavier than the current flow. If you can dedicate a slot in Dublin for PD discussion then we can expose both viewpoints and see what the group favors. That should be enough to break the knot. Pascal >-----Original Message----- >From: julien laganier [mailto:julien.laganier@gmail.com] On Behalf Of Julien Laganier >Sent: mardi 24 juin 2008 12:19 >To: Vijay Devarapalli >Cc: Pascal Thubert (pthubert); marcelo bagnulo braun; mext@ietf.org >Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > >Vijay and Pascal, > > > >Vijay Devarapalli wrote: >> Hi Pascal, >> >>> -----Original Message----- >>> From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] >>> Sent: Monday, June 23, 2008 5:52 AM >>> To: Vijay Devarapalli; Behcet Sarikaya; Julien Laganier >>> Cc: mext@ietf.org >>> Subject: RE: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >>> >>> Hi Vijay, >>> >>> I've not seen a consensus call on this and I'm sorry if I >>> missed it. If there was none than let us have one with all >>> the arguments from all parties on the table. >> >> There was no consensus call on this. But there were quite a few >> emails sent on this topic. My conclusion from that discussion >> was that most people agreed with removing extensions to DHAAD >> from the prefix delegation document. I don't believe it is >> Necessary, but we could have an explicit consensus call on this. >> Julien, Marcelo? > >We do not necessary need a consensus call for every decision -- the >consensus can appear by itself as the result of the discussion, >consensus call is only needed in case no clear consensus appears after >the discussion has ran for some time. > >So the question is, do you think all the arguments have been expressed >already and we're now rehashing the same ones? In case the answer is >yes, I'm happy to proceed with issuing a consensus call on the DHAAD for >NEMO-PD issue. > >--julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 25 08:47:14 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3701E3A69C7; Wed, 25 Jun 2008 08:47:14 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C97903A69C7 for ; Wed, 25 Jun 2008 08:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.38 X-Spam-Level: X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQWpBced7svL for ; Wed, 25 Jun 2008 08:47:12 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CEE843A680B for ; Wed, 25 Jun 2008 08:47:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,703,1204531200"; d="scan'208";a="118233707" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 25 Jun 2008 08:47:15 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5PFlFZp025710; Wed, 25 Jun 2008 08:47:15 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m5PFlF1t003892; Wed, 25 Jun 2008 15:47:15 GMT Date: Wed, 25 Jun 2008 08:47:14 -0700 (PDT) From: Sri Gundavelli To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05E1862E@xmb-ams-337.emea.cisco.com> Message-ID: References: <7892795E1A87F04CADFCCF41FADD00FC05DC3DE2@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05DC4567@xmb-ams-337.emea.cisco.com> <4860CA21.7060200@laposte.net> <7892795E1A87F04CADFCCF41FADD00FC05E1862E@xmb-ams-337.emea.cisco.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4208; t=1214408835; x=1215272835; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20Adoption=20of=20draft-droms-me xt-nemo-pd-00.txt? |Sender:=20; bh=TQmnufY7aYvnXhNzh52vfCJEwvoGmhJn9bQVVUOaSkI=; b=dsm+6hkUWyVSZNfR4DKASAHpbxgsJETGnS+2BJPKX5bZMhtpc7kMcQ5W+x 3yiXvCxR2BIgdI+pCLWTQWnC8acou3T/V8AHFxnplSjkQz0k9wxXB+T/Zq6/ 1Jkrp3ZYM6bUz+TKdf63XGeDd3lH5r2CjGXCuTnOePoxaN3X3y/Uw=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I agree. We are not taking DHAAD out from 3775bis for various reasons and if the support exists there, let there be no restrictions in other extensions. The word here is consistency. DHAAD as a discovery mechanism has some value and all the existing implementations support it and I prefer to keep this and let the extensions leverage this feature. Sri On Wed, 25 Jun 2008, Pascal Thubert (pthubert) wrote: > Hi Julien: > > I have seen some discussions and I do not think that there is consensus > on the specific matter of removing the DHAAD based discovery from this > draft. If I did, I would have retracted the text already. What I've seen > is people interested in deprecating DHAAD which is a different thing. > > I think there is confusion between a vision of a better future and the > practical work of adding a simple extension to an existing protocol. > > Right now the MIP protocol suite still uses dhaad. A NEMO MR will set > the R bit to filter out HAs that do not support NEMO on top of MIP. It > just makes sense for the same MR to set the next bit to filter out HAs > that do not support PD on top of NEMO. Simple update, no new message or > FSM state. > > I did not find a convincing alternate either. Making an additional DNS > request adds complexity whereas the idea scanning and binding to all HAs > in the DHAAD list till the PD request works makes very little sense to > me. Finally, making the bootstrap mechanism a prereq to PD is an > undesirable dependency and as a vendor I would not want such an artifact > to impact my product planning. > > In a same spirit, I disagree with obsoleting DHAAD in NEMO if we keep it > in MIP. Yet I'm not saying that Vijay is wrong. He might be very right > to push DHAAD out through the window. My point is that we must be > consistent with ourselves. Should we deprecate DHAAD, I think we should > define a new discovery that does it all and obsolete the whole suite of > protocols so that the new flow is not heavier than the current flow. > > If you can dedicate a slot in Dublin for PD discussion then we can > expose both viewpoints and see what the group favors. That should be > enough to break the knot. > > Pascal > >> -----Original Message----- >> From: julien laganier [mailto:julien.laganier@gmail.com] On Behalf Of > Julien Laganier >> Sent: mardi 24 juin 2008 12:19 >> To: Vijay Devarapalli >> Cc: Pascal Thubert (pthubert); marcelo bagnulo braun; mext@ietf.org >> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >> >> Vijay and Pascal, >> >> >> >> Vijay Devarapalli wrote: >>> Hi Pascal, >>> >>>> -----Original Message----- >>>> From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] >>>> Sent: Monday, June 23, 2008 5:52 AM >>>> To: Vijay Devarapalli; Behcet Sarikaya; Julien Laganier >>>> Cc: mext@ietf.org >>>> Subject: RE: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >>>> >>>> Hi Vijay, >>>> >>>> I've not seen a consensus call on this and I'm sorry if I >>>> missed it. If there was none than let us have one with all >>>> the arguments from all parties on the table. >>> >>> There was no consensus call on this. But there were quite a few >>> emails sent on this topic. My conclusion from that discussion >>> was that most people agreed with removing extensions to DHAAD >>> from the prefix delegation document. I don't believe it is >>> Necessary, but we could have an explicit consensus call on this. >>> Julien, Marcelo? >> >> We do not necessary need a consensus call for every decision -- the >> consensus can appear by itself as the result of the discussion, >> consensus call is only needed in case no clear consensus appears after >> the discussion has ran for some time. >> >> So the question is, do you think all the arguments have been expressed >> already and we're now rehashing the same ones? In case the answer is >> yes, I'm happy to proceed with issuing a consensus call on the DHAAD > for >> NEMO-PD issue. >> >> --julien > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 25 08:54:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14F283A6961; Wed, 25 Jun 2008 08:54:04 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 877383A6961 for ; Wed, 25 Jun 2008 08:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Atsb-Ph36ln for ; Wed, 25 Jun 2008 08:54:01 -0700 (PDT) Received: from web84311.mail.re1.yahoo.com (web84311.mail.re1.yahoo.com [69.147.74.190]) by core3.amsl.com (Postfix) with SMTP id 0C2F63A6911 for ; Wed, 25 Jun 2008 08:54:00 -0700 (PDT) Received: (qmail 75187 invoked by uid 60001); 25 Jun 2008 15:54:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=qDCemgP10zQBPAGdoMviHFqDfQnRo8SPIjRzciJ46ydjs8nZoCKtXpQt+v6ouCttDxeJa7H2scyyjoXN6nLLqEu/ZdqtXkOcvlfm95GnoigXtkCvPM2movQiNagaDqzr6lgvb8KTG+vH2eiGFvOb9/dNkPJkphYP+A/FwhmkE6M=; Received: from [206.16.17.212] by web84311.mail.re1.yahoo.com via HTTP; Wed, 25 Jun 2008 08:54:02 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.199 Date: Wed, 25 Jun 2008 08:54:02 -0700 (PDT) From: Behcet Sarikaya To: "Pascal Thubert \(pthubert\)" , Julien Laganier , Vijay Devarapalli MIME-Version: 1.0 Message-ID: <813348.74077.qm@web84311.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 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="===============1438434762==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1438434762== Content-Type: multipart/alternative; boundary="0-1430085212-1214409242=:74077" --0-1430085212-1214409242=:74077 Content-Type: text/plain; charset=us-ascii Hi Pascal, Two solutions can be proposed: a) Simply remove that section from the draft. As far as I remember most people suggested this on the mailing list. It would have the implications such as leaving it completely up to the implementations. b) Not to have HA as DR. As you mentioned in an earlier mail, going for a second solution is also feasible IMHO. Regards, Behcet ----- Original Message ---- From: Pascal Thubert (pthubert) To: Julien Laganier ; Vijay Devarapalli Cc: mext@ietf.org Sent: Wednesday, June 25, 2008 8:17:54 AM Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Hi Julien: I have seen some discussions and I do not think that there is consensus on the specific matter of removing the DHAAD based discovery from this draft. If I did, I would have retracted the text already. What I've seen is people interested in deprecating DHAAD which is a different thing. I think there is confusion between a vision of a better future and the practical work of adding a simple extension to an existing protocol. Right now the MIP protocol suite still uses dhaad. A NEMO MR will set the R bit to filter out HAs that do not support NEMO on top of MIP. It just makes sense for the same MR to set the next bit to filter out HAs that do not support PD on top of NEMO. Simple update, no new message or FSM state. I did not find a convincing alternate either. Making an additional DNS request adds complexity whereas the idea scanning and binding to all HAs in the DHAAD list till the PD request works makes very little sense to me. Finally, making the bootstrap mechanism a prereq to PD is an undesirable dependency and as a vendor I would not want such an artifact to impact my product planning. In a same spirit, I disagree with obsoleting DHAAD in NEMO if we keep it in MIP. Yet I'm not saying that Vijay is wrong. He might be very right to push DHAAD out through the window. My point is that we must be consistent with ourselves. Should we deprecate DHAAD, I think we should define a new discovery that does it all and obsolete the whole suite of protocols so that the new flow is not heavier than the current flow. If you can dedicate a slot in Dublin for PD discussion then we can expose both viewpoints and see what the group favors. That should be enough to break the knot. Pascal >-----Original Message----- >From: julien laganier [mailto:julien.laganier@gmail.com] On Behalf Of Julien Laganier >Sent: mardi 24 juin 2008 12:19 >To: Vijay Devarapalli >Cc: Pascal Thubert (pthubert); marcelo bagnulo braun; mext@ietf.org >Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > >Vijay and Pascal, > > > >Vijay Devarapalli wrote: >> Hi Pascal, >> >>> -----Original Message----- >>> From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] >>> Sent: Monday, June 23, 2008 5:52 AM >>> To: Vijay Devarapalli; Behcet Sarikaya; Julien Laganier >>> Cc: mext@ietf.org >>> Subject: RE: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? >>> >>> Hi Vijay, >>> >>> I've not seen a consensus call on this and I'm sorry if I >>> missed it. If there was none than let us have one with all >>> the arguments from all parties on the table. >> >> There was no consensus call on this. But there were quite a few >> emails sent on this topic. My conclusion from that discussion >> was that most people agreed with removing extensions to DHAAD >> from the prefix delegation document. I don't believe it is >> Necessary, but we could have an explicit consensus call on this. >> Julien, Marcelo? > >We do not necessary need a consensus call for every decision -- the >consensus can appear by itself as the result of the discussion, >consensus call is only needed in case no clear consensus appears after >the discussion has ran for some time. > >So the question is, do you think all the arguments have been expressed >already and we're now rehashing the same ones? In case the answer is >yes, I'm happy to proceed with issuing a consensus call on the DHAAD for >NEMO-PD issue. > >--julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-1430085212-1214409242=:74077 Content-Type: text/html; charset=us-ascii
Hi Pascal,
  Two solutions can be proposed:
a) Simply remove that section from the draft. As far as I remember most people suggested this on the mailing list. It would have the implications such as leaving it completely up to the implementations.
b) Not to have HA as DR. As you mentioned in an earlier mail, going for a second solution is also feasible IMHO.

Regards,

Behcet

----- Original Message ----
From: Pascal Thubert (pthubert) <pthubert@cisco.com>
To: Julien Laganier <julien.IETF@laposte.net>; Vijay Devarapalli <vijay@wichorus.com>
Cc: mext@ietf.org
Sent: Wednesday, June 25, 2008 8:17:54 AM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

Hi Julien:

I have seen some discussions and I do not think that there is consensus
on the specific matter of removing the DHAAD based discovery from this
draft. If I did, I would have retracted the text already. What I've seen
is people interested in deprecating DHAAD which is a different thing.

I think there is confusion between a vision of a better future and the
practical work of adding a simple extension to an existing protocol.

Right now the MIP protocol suite still uses dhaad. A NEMO MR will set
the R bit to filter out HAs that do not support NEMO on top of MIP. It
just makes sense for the same MR to set the next bit to filter out HAs
that do not support PD on top of NEMO. Simple update, no new message or
FSM state.

I did not find a convincing alternate either. Making an additional DNS
request adds complexity whereas the idea scanning and binding to all HAs
in the DHAAD list till the PD request works makes very little sense to
me. Finally, making the bootstrap mechanism a prereq to PD is an
undesirable dependency and as a vendor I would not want such an artifact
to impact my product planning.

In a same spirit, I disagree with obsoleting DHAAD in NEMO if we keep it
in MIP. Yet I'm not saying that Vijay is wrong. He might be very right
to push DHAAD out through the window. My point is that we must be
consistent with ourselves. Should we deprecate DHAAD, I think we should
define a new discovery that does it all and obsolete the whole suite of
protocols so that the new flow is not heavier than the current flow.

If you can dedicate a slot in Dublin for PD discussion then we can
expose both viewpoints and see what the group favors. That should be
enough to break the knot.

Pascal

>-----Original Message-----
>From: julien laganier [mailto:julien.laganier@gmail.com] On Behalf Of
Julien Laganier
>Sent: mardi 24 juin 2008 12:19
>To: Vijay Devarapalli
>Cc: Pascal Thubert (pthubert); marcelo bagnulo braun; mext@ietf.org
>Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?
>
>Vijay and Pascal,
>
><Chair Hat ON>
>
>Vijay Devarapalli wrote:
>> Hi Pascal,
>>
>>> -----Original Message-----
>>> From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
>>> Sent: Monday, June 23, 2008 5:52 AM
>>> To: Vijay Devarapalli; Behcet Sarikaya; Julien Laganier
>>> Cc: mext@ietf.org
>>> Subject: RE: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?
>>>
>>> Hi Vijay,
>>>
>>> I've not seen a consensus call on this and I'm sorry if I
>>> missed it. If there was none than let us have one with all
>>> the arguments from all parties on the table.
>>
>> There was no consensus call on this. But there were quite a few
>> emails sent on this topic. My conclusion from that discussion
>> was that most people agreed with removing extensions to DHAAD
>> from the prefix delegation document. I don't believe it is
>> Necessary, but we could have an explicit consensus call on this.
>> Julien, Marcelo?
>
>We do not necessary need a consensus call for every decision -- the
>consensus can appear by itself as the result of the discussion,
>consensus call is only needed in case no clear consensus appears after
>the discussion has ran for some time.
>
>So the question is, do you think all the arguments have been expressed
>already and we're now rehashing the same ones? In case the answer is
>yes, I'm happy to proceed with issuing a consensus call on the DHAAD
for
>NEMO-PD issue.
>
>--julien
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
--0-1430085212-1214409242=:74077-- --===============1438434762== 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://www.ietf.org/mailman/listinfo/mext --===============1438434762==-- From mext-bounces@ietf.org Wed Jun 25 10:18:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B4BF3A68B7; Wed, 25 Jun 2008 10:18:46 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE71C3A68B7 for ; Wed, 25 Jun 2008 10:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3tPqNl6CJJp for ; Wed, 25 Jun 2008 10:18:43 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id B73043A683B for ; Wed, 25 Jun 2008 10:18:43 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 13:18:39 -0400 Message-ID: In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05E1862E@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Thread-Index: AcjV48U4UCLaJGg0RO2QP0Wg0IsC6QA3QMpQAAmb/CA= References: <7892795E1A87F04CADFCCF41FADD00FC05DC3DE2@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05DC4567@xmb-ams-337.emea.cisco.com> <4860CA21.7060200@laposte.net> <7892795E1A87F04CADFCCF41FADD00FC05E1862E@xmb-ams-337.emea.cisco.com> From: "Vijay Devarapalli" To: "Pascal Thubert (pthubert)" , "Julien Laganier" Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Pascal, I want to focus on extending DHAAD for prefix delegation. We are *not* talking about DHAAD deprecation in this thread. We already had the discussion a while ago and decided that DHAAD would stay in 3775bis. In fact I had supported keeping DHAAD in 3775bis at that point. What I don't like is extending DHAAD every time we had a minor extension to the MIPv6 home agent. It is not necessary. We have mechanisms for the mobile node to recover when ever the home agent does not support a particular feature. Lets focus on that. Vijay > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Wednesday, June 25, 2008 6:18 AM > To: Julien Laganier; Vijay Devarapalli > Cc: marcelo bagnulo braun; mext@ietf.org > Subject: RE: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > Hi Julien: > > I have seen some discussions and I do not think that there is consensus > on the specific matter of removing the DHAAD based discovery from this > draft. If I did, I would have retracted the text already. What I've seen > is people interested in deprecating DHAAD which is a different thing. > > I think there is confusion between a vision of a better future and the > practical work of adding a simple extension to an existing protocol. > > Right now the MIP protocol suite still uses dhaad. A NEMO MR will set > the R bit to filter out HAs that do not support NEMO on top of MIP. It > just makes sense for the same MR to set the next bit to filter out HAs > that do not support PD on top of NEMO. Simple update, no new message or > FSM state. > > I did not find a convincing alternate either. Making an additional DNS > request adds complexity whereas the idea scanning and binding to all HAs > in the DHAAD list till the PD request works makes very little sense to > me. Finally, making the bootstrap mechanism a prereq to PD is an > undesirable dependency and as a vendor I would not want such an artifact > to impact my product planning. > > In a same spirit, I disagree with obsoleting DHAAD in NEMO if we keep it > in MIP. Yet I'm not saying that Vijay is wrong. He might be very right > to push DHAAD out through the window. My point is that we must be > consistent with ourselves. Should we deprecate DHAAD, I think we should > define a new discovery that does it all and obsolete the whole suite of > protocols so that the new flow is not heavier than the current flow. > > If you can dedicate a slot in Dublin for PD discussion then we can > expose both viewpoints and see what the group favors. That should be > enough to break the knot. > > Pascal > > >-----Original Message----- > >From: julien laganier [mailto:julien.laganier@gmail.com] On Behalf Of > Julien Laganier > >Sent: mardi 24 juin 2008 12:19 > >To: Vijay Devarapalli > >Cc: Pascal Thubert (pthubert); marcelo bagnulo braun; mext@ietf.org > >Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > > > >Vijay and Pascal, > > > > > > > >Vijay Devarapalli wrote: > >> Hi Pascal, > >> > >>> -----Original Message----- > >>> From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > >>> Sent: Monday, June 23, 2008 5:52 AM > >>> To: Vijay Devarapalli; Behcet Sarikaya; Julien Laganier > >>> Cc: mext@ietf.org > >>> Subject: RE: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? > >>> > >>> Hi Vijay, > >>> > >>> I've not seen a consensus call on this and I'm sorry if I > >>> missed it. If there was none than let us have one with all > >>> the arguments from all parties on the table. > >> > >> There was no consensus call on this. But there were quite a few > >> emails sent on this topic. My conclusion from that discussion > >> was that most people agreed with removing extensions to DHAAD > >> from the prefix delegation document. I don't believe it is > >> Necessary, but we could have an explicit consensus call on this. > >> Julien, Marcelo? > > > >We do not necessary need a consensus call for every decision -- the > >consensus can appear by itself as the result of the discussion, > >consensus call is only needed in case no clear consensus appears after > >the discussion has ran for some time. > > > >So the question is, do you think all the arguments have been expressed > >already and we're now rehashing the same ones? In case the answer is > >yes, I'm happy to proceed with issuing a consensus call on the DHAAD > for > >NEMO-PD issue. > > > >--julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 25 10:55:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1546C3A68DE; Wed, 25 Jun 2008 10:55:45 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463D33A68A3 for ; Wed, 25 Jun 2008 10:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.815 X-Spam-Level: X-Spam-Status: No, score=-5.815 tagged_above=-999 required=5 tests=[AWL=0.784, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBSe0PqY-icz for ; Wed, 25 Jun 2008 10:55:43 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 8BFD33A67AE for ; Wed, 25 Jun 2008 10:55:43 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m5PHtjvZ009178 for ; Wed, 25 Jun 2008 12:55:45 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 12:56:13 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 12:56:13 -0500 Message-ID: <486286F0.9010801@ericsson.com> Date: Wed, 25 Jun 2008 13:57:04 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: mext@ietf.org X-OriginalArrivalTime: 25 Jun 2008 17:56:13.0472 (UTC) FILETIME=[C1F4A200:01C8D6EC] Subject: [MEXT] DSMIPv6 deregistration X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Folks, When the MN de-registers using DSMIPv6 and it had an IPv4 address does it need to include the IPv4 Home Address Option in the BU with lifetime 0? If so, is this a SHOULD or a MUST? Thanks Suresh _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 25 11:08:19 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20DDC3A6AA0; Wed, 25 Jun 2008 11:08:19 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B23728B797 for ; Wed, 25 Jun 2008 11:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PG4J25jL1T7s for ; Wed, 25 Jun 2008 11:08:16 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 9075C28C0F1 for ; Wed, 25 Jun 2008 11:08:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 14:08:15 -0400 Message-ID: In-Reply-To: <486286F0.9010801@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] DSMIPv6 deregistration Thread-Index: AcjW7MtrN8+BRyZRS56a5uqLqwJslgAAYrog References: <486286F0.9010801@ericsson.com> From: "Vijay Devarapalli" To: "Suresh Krishnan" , Subject: Re: [MEXT] DSMIPv6 deregistration X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Suresh Krishnan > Sent: Wednesday, June 25, 2008 10:57 AM > To: mext@ietf.org > Subject: [MEXT] DSMIPv6 deregistration > > Hi Folks, > When the MN de-registers using DSMIPv6 and it had an IPv4 address > does it need to include the IPv4 Home Address Option in the BU with > lifetime 0? If so, is this a SHOULD or a MUST? The mobile node does not have to. Both bindings (for the IPv6 and IPv4 home addresses) are removed. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 25 11:11:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1A643A67AE; Wed, 25 Jun 2008 11:11:00 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF3013A67AE for ; Wed, 25 Jun 2008 11:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.129 X-Spam-Level: X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWvG4DpLhlSU for ; Wed, 25 Jun 2008 11:10:56 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 195C73A67AB for ; Wed, 25 Jun 2008 11:10:55 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m5PIAuqZ028020 for ; Wed, 25 Jun 2008 13:10:58 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 13:11:19 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 13:11:19 -0500 Message-ID: <48628A7A.7080606@ericsson.com> Date: Wed, 25 Jun 2008 14:12:10 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: mext@ietf.org X-OriginalArrivalTime: 25 Jun 2008 18:11:19.0835 (UTC) FILETIME=[DE30A6B0:01C8D6EE] Subject: [MEXT] Scope of Binding revocation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Folks, Is the binding revocation mechanism specified in draft-muhanna-mext-binding-revocation-01.txt supposed to be applicable for DSMIPv6 as well. It states that it is applicable to MIPv6 and PMIPv6. I do not see why it should not be applicable to DSMIPv6. If DSMIPv6 needs to be supported, I think there needs to be some additional text added to the draft to address this case (e.g. set of options to be included in the BRI/BRA messages). Cheers Suresh _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 25 11:16:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB5743A6ACD; Wed, 25 Jun 2008 11:16:05 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7C273A6AC8 for ; Wed, 25 Jun 2008 11:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egYjaA4MTz12 for ; Wed, 25 Jun 2008 11:16:03 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 454B13A6ACD for ; Wed, 25 Jun 2008 11:16:03 -0700 (PDT) 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 m5PIG0V15455; Wed, 25 Jun 2008 18:16:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 13:15:14 -0500 Message-ID: In-Reply-To: <48628A7A.7080606@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of Binding revocation Thread-Index: AcjW7tqARQ8MhNRBSlS0T+pHhz6FFgAAAzdg References: <48628A7A.7080606@ericsson.com> From: "Ahmad Muhanna" To: "Suresh Krishnan" , Subject: Re: [MEXT] Scope of Binding revocation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Suresh, I assumed that is understood:) but sure we can have some text to clarify this. Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Suresh Krishnan > Sent: Wednesday, June 25, 2008 1:12 PM > To: mext@ietf.org > Subject: [MEXT] Scope of Binding revocation > > Hi Folks, > Is the binding revocation mechanism specified in > draft-muhanna-mext-binding-revocation-01.txt supposed to be > applicable for DSMIPv6 as well. It states that it is > applicable to MIPv6 and PMIPv6. I do not see why it should > not be applicable to DSMIPv6. If > DSMIPv6 needs to be supported, I think there needs to be some > additional text added to the draft to address this case (e.g. > set of options to be included in the BRI/BRA messages). > > Cheers > Suresh > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 25 14:59:38 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6409728C0FA; Wed, 25 Jun 2008 14:59:38 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7D1528C0FA for ; Wed, 25 Jun 2008 14:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2-EEQzImJnh for ; Wed, 25 Jun 2008 14:59:36 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 072D428C0F4 for ; Wed, 25 Jun 2008 14:59:34 -0700 (PDT) Received: from [124.190.105.201] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1KBd1Z-0005g3-Af; Thu, 26 Jun 2008 07:59:33 +1000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 26 Jun 2008 07:59:22 +1000 From: Hesham Soliman To: Suresh Krishnan , Message-ID: Thread-Topic: [MEXT] DSMIPv6 deregistration Thread-Index: AcjXDrllCQC8SX6mq0Owh/Fkza507w== In-Reply-To: <486286F0.9010801@ericsson.com> Mime-version: 1.0 Subject: Re: [MEXT] DSMIPv6 deregistration X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org It's a MAY. Actually, if you're trying to save bits you should not include the IPv4 addresses. If you de-register, you're removing all bindings. I don't think the spec has keywords associated with this. Hesham On 26/06/08 3:57 AM, "Suresh Krishnan" wrote: > Hi Folks, > When the MN de-registers using DSMIPv6 and it had an IPv4 address > does it need to include the IPv4 Home Address Option in the BU with > lifetime 0? If so, is this a SHOULD or a MUST? > > Thanks > Suresh > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 25 15:05:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E10C3A6A01; Wed, 25 Jun 2008 15:05:12 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E0063A6A20 for ; Wed, 25 Jun 2008 15:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPA+7VzxRZY5 for ; Wed, 25 Jun 2008 15:05:10 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A6BCE3A6A01 for ; Wed, 25 Jun 2008 15:05:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,704,1204531200"; d="scan'208";a="118392652" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 25 Jun 2008 15:05:13 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5PM5DO8005327; Wed, 25 Jun 2008 15:05:13 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5PM5Dxd011180; Wed, 25 Jun 2008 22:05:13 GMT Date: Wed, 25 Jun 2008 15:05:13 -0700 (PDT) From: Sri Gundavelli To: Hesham Soliman In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=388; t=1214431513; x=1215295513; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20DSMIPv6=20deregistration |Sender:=20; bh=T0zmDVhii8xOeIV90pSAPIsDkvyEgMkaxOCXhhp6d+c=; b=g9mgYkXd05aKyCucGLCDtMaXs1LJvRCySAiZRfK5eREw1YhgtZqQ3Bki1k ad8W+iwRSIwDR0HTGIZx+B3ujdCuC0gZVbPCNoJycOOCrPw/6pw24t0EkY00 puiwcCVJzW0NsHPplSd6eU5Zj0MKKSRRW+A+Pix6jGTlHQ8LAOLNE=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] DSMIPv6 deregistration X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Thu, 26 Jun 2008, Hesham Soliman wrote: > It's a MAY. Actually, if you're trying to save bits you should not include > the IPv4 addresses. If you de-register, you're removing all bindings. > > I don't think the spec has keywords associated with this. > What will be the key for the binding lookup ? If the entries are kept seperate, is the v4 HoA not required ? Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 25 15:59:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1561F3A6ACF; Wed, 25 Jun 2008 15:59:53 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB1173A6ACF for ; Wed, 25 Jun 2008 15:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuPo4ppJ+mNR for ; Wed, 25 Jun 2008 15:59:51 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id E4DBE3A69FC for ; Wed, 25 Jun 2008 15:59:49 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 18:59:48 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] DSMIPv6 deregistration Thread-Index: AcjXD495vo5h2TnqQCS1ECJQ+9BRigABy0/Q References: From: "Vijay Devarapalli" To: "Sri Gundavelli" , "Hesham Soliman" Cc: mext@ietf.org Subject: Re: [MEXT] DSMIPv6 deregistration X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > On Thu, 26 Jun 2008, Hesham Soliman wrote: > > > It's a MAY. Actually, if you're trying to save bits you should not > include > > the IPv4 addresses. If you de-register, you're removing all > bindings. > > > > I don't think the spec has keywords associated with this. > > > > What will be the key for the binding lookup ? If the > entries are kept seperate, is the v4 HoA not required ? If you have two separate bindings, you need to link them in your implementation. If the primary binding cache entry (I consider the one for the IPv6 home address as the primary one) is removed, the IPv4 home address binding cache entry should also be removed. Currently we don't support a scenario where the mobile node can delete the binding cache entry for the IPv6 home address, but keep the one for the IPv4 home address. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 25 20:48:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 185003A67B7; Wed, 25 Jun 2008 20:48:16 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B63D3A67AE for ; Wed, 25 Jun 2008 20:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAqRq7hionln for ; Wed, 25 Jun 2008 20:48:12 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 9E7D73A67B7 for ; Wed, 25 Jun 2008 20:48:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,706,1204531200"; d="scan'208";a="60409026" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 25 Jun 2008 20:48:15 -0700 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 m5Q3mFpg007726; Wed, 25 Jun 2008 20:48:15 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5Q3mFRx018565; Thu, 26 Jun 2008 03:48:15 GMT Date: Wed, 25 Jun 2008 20:48:15 -0700 (PDT) From: Sri Gundavelli To: Vijay Devarapalli In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1308; t=1214452095; x=1215316095; 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]=20DSMIPv6=20deregistration |Sender:=20; bh=sTt+85M7uP1mK9F90d3ZVXZPiKgWn33KilqKpE0SB6I=; b=V3p3aoc9hwfARtTcBrB0fMDi+mGYZtqLxspa7B/eGGl/WyhtSCee0B91om IL8lUM2NH5RJLFXONCeJeKv0sars+TCsaQDuw9Ds9MyTgMWrzE1ICRUPUXww AlNuV//dqj; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] DSMIPv6 deregistration X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Wed, 25 Jun 2008, Vijay Devarapalli wrote: >> >> What will be the key for the binding lookup ? If the >> entries are kept seperate, is the v4 HoA not required ? > > If you have two separate bindings, you need to link them in your > implementation. If the primary binding cache entry (I consider the one > for the IPv6 home address as the primary one) is removed, the IPv4 home > address binding cache entry should also be removed. > If the draft has recommendation for seperate binding entries, it would be good have the required identifier present and avoid this special links between bindings. Changing that MAY to MUST is better, saving those 4 bytes is not worth the special linking logic. Why recommend seperate BCE's and why expect this special linkage, if you consider all of them as one, just bundle them in one. > Currently we don't support a scenario where the mobile node can delete > the binding cache entry for the IPv6 home address, but keep the one for > the IPv4 home address. > I thought selective dereg is possible. I'm not sure if the MN is mandated to include HoA option(s) for all the currently obtained IPv4 addresses/prefixes and if the HA is forced to return them in dereg. Either way, bit more explicit language in 5.5 will help. Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jun 25 20:51:31 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE3FC3A6841; Wed, 25 Jun 2008 20:51:31 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA1703A6841 for ; Wed, 25 Jun 2008 20:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITcsB--XeEe4 for ; Wed, 25 Jun 2008 20:51:29 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id AB2933A67AE for ; Wed, 25 Jun 2008 20:51:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,706,1204531200"; d="scan'208";a="44853116" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 25 Jun 2008 20:51:32 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5Q3pWkL011252; Wed, 25 Jun 2008 20:51:32 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5Q3pWF4007620; Thu, 26 Jun 2008 03:51:32 GMT Date: Wed, 25 Jun 2008 20:51:32 -0700 (PDT) From: Sri Gundavelli To: Vijay Devarapalli In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=414; t=1214452292; x=1215316292; 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]=20DSMIPv6=20deregistration |Sender:=20; bh=3uaRZO/lRRN1X3PkmunwTmOgzuNH+Mk13W9mRvRa8PY=; b=LOni+g2LCACdxmAyMNeqwj5lZlrMzXQGrwk2CJw332h/CY96fe/ueAaq1b Xj4t559aj45nDy6nLCsaZM1sJp4G3pivH33yX+DN4GzZks5ZJJ6B6bNo257a 86+mnwD0gC; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] DSMIPv6 deregistration X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Wed, 25 Jun 2008, Sri Gundavelli wrote: > > I thought selective dereg is possible. I'm not sure if the MN is > mandated to include HoA option(s) for all the currently obtained > IPv4 addresses/prefixes and if the HA is forced to return them > in dereg. Either way, bit more explicit language in 5.5 will help. > In re-registrations I meant, if all obtained HoA's have to be present ..., Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 26 00:13:33 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B94F93A686D; Thu, 26 Jun 2008 00:13:33 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BDA73A681A for ; Thu, 26 Jun 2008 00:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cz3dOMeeDnrA for ; Thu, 26 Jun 2008 00:13:32 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id DA9253A686D for ; Thu, 26 Jun 2008 00:13:30 -0700 (PDT) Received: from [211.27.108.142] (helo=[10.0.0.5]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1KBlfc-0001Tn-RC; Thu, 26 Jun 2008 17:13:29 +1000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 26 Jun 2008 17:13:20 +1000 From: Hesham Soliman To: Sri Gundavelli , Vijay Devarapalli Message-ID: Thread-Topic: [MEXT] DSMIPv6 deregistration Thread-Index: AcjXXBzJlyqfXWwDCkOQkj+mT2OLpg== In-Reply-To: Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] DSMIPv6 deregistration X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On 26/06/08 1:48 PM, "Sri Gundavelli" wrote: > > > On Wed, 25 Jun 2008, Vijay Devarapalli wrote: > >>> >>> What will be the key for the binding lookup ? If the >>> entries are kept seperate, is the v4 HoA not required ? >> >> If you have two separate bindings, you need to link them in your >> implementation. If the primary binding cache entry (I consider the one >> for the IPv6 home address as the primary one) is removed, the IPv4 home >> address binding cache entry should also be removed. >> > > If the draft has recommendation for seperate binding entries, => The draft has no such recommendation. There is only one logical binding and that is tied to the IPv6 address. >> Currently we don't support a scenario where the mobile node can delete >> the binding cache entry for the IPv6 home address, but keep the one for >> the IPv4 home address. >> > > I thought selective dereg is possible. => No. Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 26 00:14:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606BA3A6922; Thu, 26 Jun 2008 00:14:44 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71DEE3A68A4 for ; Thu, 26 Jun 2008 00:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sim+eQYZ98Kv for ; Thu, 26 Jun 2008 00:14:42 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id A73F43A6879 for ; Thu, 26 Jun 2008 00:14:42 -0700 (PDT) Received: from [211.27.108.142] (helo=[10.0.0.5]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1KBlgk-0001B0-27; Thu, 26 Jun 2008 17:14:38 +1000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 26 Jun 2008 17:14:25 +1000 From: Hesham Soliman To: Sri Gundavelli , Vijay Devarapalli Message-ID: Thread-Topic: [MEXT] DSMIPv6 deregistration Thread-Index: AcjXXEOHZSbPpojujkaZDC3y5o17xA== In-Reply-To: Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] DSMIPv6 deregistration X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Sri, the draft explicitly states that the HAO is not used in the BU. Please check the BU format used. Hesham On 26/06/08 1:51 PM, "Sri Gundavelli" wrote: > > > On Wed, 25 Jun 2008, Sri Gundavelli wrote: >> >> I thought selective dereg is possible. I'm not sure if the MN is >> mandated to include HoA option(s) for all the currently obtained >> IPv4 addresses/prefixes and if the HA is forced to return them >> in dereg. Either way, bit more explicit language in 5.5 will help. >> > > In re-registrations I meant, if all obtained HoA's have to be > present ..., > > > Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 26 03:12:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70E403A6811; Thu, 26 Jun 2008 03:12:48 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EA323A6811 for ; Thu, 26 Jun 2008 03:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyhewNh0o20t for ; Thu, 26 Jun 2008 03:12:47 -0700 (PDT) Received: from nw-smtp-03.wineasy.se (nw-smtp-03.wineasy.se [195.42.210.226]) by core3.amsl.com (Postfix) with ESMTP id C65DF3A67ED for ; Thu, 26 Jun 2008 03:12:46 -0700 (PDT) Received: from [10.1.2.47] (static-213.88.172.99.addr.tdcsong.se [213.88.172.99]) by nw-smtp-03.wineasy.se (Postfix) with ESMTP id 4C6F66A163D for ; Thu, 26 Jun 2008 12:12:48 +0200 (CEST) From: Joel Hortelius To: mext@ietf.org Organization: Interpeak Date: Thu, 26 Jun 2008 11:15:19 +0000 Message-Id: <1214478919.11693.29.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 Subject: [MEXT] DSMIPv6 Dynamic Prefix Allocation/Home Address & Prefix Length X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi; A question regarding the home address/home address ack options; In the ACK option, if I request a home address(not a prefix), will it be set to '32' or will it be set to the subnet length of the network the home address belongs to? If its set to the network subnet length, which would provide more information and making "returning home" much easier, I can see no way I can differ it from a dynamic prefix allocation in the same request; that is if I request 0.0.0.0/32, and 0.0.0.0/24 with P flag set, there's no way currently to figure which of the ack options contain the reply, since both may be returned with /24 prefix length? Why does not the ack also contain the PREFIX flag, if it's in reply to a PREFIX allocation? Regards, Joel Hortelius. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From ca@soteria-klinik-leipzig.de Thu Jun 26 05:14:02 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BAC43A6A90; Thu, 26 Jun 2008 05:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -67.583 X-Spam-Level: X-Spam-Status: No, score=-67.583 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_STATIC=1.172, HOST_EQ_USERONOCOM=1.444, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZezX3K5FDho; Thu, 26 Jun 2008 05:14:01 -0700 (PDT) Received: from 84.124.12.213.static.user.ono.com (84.124.12.213.static.user.ono.com [84.124.12.213]) by core3.amsl.com (Postfix) with SMTP id 2809E3A695C; Thu, 26 Jun 2008 05:13:52 -0700 (PDT) X-Originating-IP: 206.62.127.0 by smtp.84.124.12.213; Thu, 26 Jun 2008 08:13:57 -0500 Message-ID: From: "Elsa Murphy" Reply-To: "Elsa Murphy" To: nemo-archive@ietf.org Subject: Tag Heuer replicas better than originals Date: Thu, 26 Jun 2008 08:13:57 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Diamond Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://mehegigilar15.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://mehegigilar15.blogspot.com/ From nfsv4-bounces@ietf.org Thu Jun 26 05:14:03 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2F933A6A9F for ; Thu, 26 Jun 2008 05:14:03 -0700 (PDT) Subject: The results of your email commands From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1871647690==" Message-ID: Date: Thu, 26 Jun 2008 05:14:02 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org --===============1871647690== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://mehegigilar15.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://mehegigilar15.blogspot.com/ - Done. --===============1871647690== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nfsv4-request@core3.amsl.com Delivered-To: nfsv4-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BAC43A6A90; Thu, 26 Jun 2008 05:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -67.583 X-Spam-Level: X-Spam-Status: No, score=-67.583 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_STATIC=1.172, HOST_EQ_USERONOCOM=1.444, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZezX3K5FDho; Thu, 26 Jun 2008 05:14:01 -0700 (PDT) Received: from 84.124.12.213.static.user.ono.com (84.124.12.213.static.user.ono.com [84.124.12.213]) by core3.amsl.com (Postfix) with SMTP id 2809E3A695C; Thu, 26 Jun 2008 05:13:52 -0700 (PDT) X-Originating-IP: 206.62.127.0 by smtp.84.124.12.213; Thu, 26 Jun 2008 08:13:57 -0500 Message-ID: From: "Elsa Murphy" Reply-To: "Elsa Murphy" To: nemo-archive@ietf.org Subject: Tag Heuer replicas better than originals Date: Thu, 26 Jun 2008 08:13:57 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Diamond Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://mehegigilar15.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://mehegigilar15.blogspot.com/ --===============1871647690==-- From nemo-bounces@ietf.org Thu Jun 26 05:14:03 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C50433A6AAC for ; Thu, 26 Jun 2008 05:14:03 -0700 (PDT) Subject: The results of your email commands From: nemo-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0751771205==" Message-ID: Date: Thu, 26 Jun 2008 05:14:02 -0700 Precedence: bulk X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NEMO Working Group X-List-Administrivia: yes Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --===============0751771205== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://mehegigilar15.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://mehegigilar15.blogspot.com/ - Done. --===============0751771205== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nemo-request@core3.amsl.com Delivered-To: nemo-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BAC43A6A90; Thu, 26 Jun 2008 05:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -67.583 X-Spam-Level: X-Spam-Status: No, score=-67.583 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_STATIC=1.172, HOST_EQ_USERONOCOM=1.444, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZezX3K5FDho; Thu, 26 Jun 2008 05:14:01 -0700 (PDT) Received: from 84.124.12.213.static.user.ono.com (84.124.12.213.static.user.ono.com [84.124.12.213]) by core3.amsl.com (Postfix) with SMTP id 2809E3A695C; Thu, 26 Jun 2008 05:13:52 -0700 (PDT) X-Originating-IP: 206.62.127.0 by smtp.84.124.12.213; Thu, 26 Jun 2008 08:13:57 -0500 Message-ID: From: "Elsa Murphy" Reply-To: "Elsa Murphy" To: nemo-archive@ietf.org Subject: Tag Heuer replicas better than originals Date: Thu, 26 Jun 2008 08:13:57 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Diamond Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://mehegigilar15.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://mehegigilar15.blogspot.com/ --===============0751771205==-- From nsis-bounces@ietf.org Thu Jun 26 05:14:03 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC253A6A9F for ; Thu, 26 Jun 2008 05:14:03 -0700 (PDT) Subject: The results of your email commands From: nsis-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1206615167==" Message-ID: Date: Thu, 26 Jun 2008 05:14:02 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============1206615167== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://mehegigilar15.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://mehegigilar15.blogspot.com/ - Done. --===============1206615167== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nsis-request@core3.amsl.com Delivered-To: nsis-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BAC43A6A90; Thu, 26 Jun 2008 05:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -67.583 X-Spam-Level: X-Spam-Status: No, score=-67.583 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_STATIC=1.172, HOST_EQ_USERONOCOM=1.444, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZezX3K5FDho; Thu, 26 Jun 2008 05:14:01 -0700 (PDT) Received: from 84.124.12.213.static.user.ono.com (84.124.12.213.static.user.ono.com [84.124.12.213]) by core3.amsl.com (Postfix) with SMTP id 2809E3A695C; Thu, 26 Jun 2008 05:13:52 -0700 (PDT) X-Originating-IP: 206.62.127.0 by smtp.84.124.12.213; Thu, 26 Jun 2008 08:13:57 -0500 Message-ID: From: "Elsa Murphy" Reply-To: "Elsa Murphy" To: nemo-archive@ietf.org Subject: Tag Heuer replicas better than originals Date: Thu, 26 Jun 2008 08:13:57 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Diamond Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://mehegigilar15.blogspot.com/ As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today! http://mehegigilar15.blogspot.com/ --===============1206615167==-- From netlmm-bounces@ietf.org Thu Jun 26 05:14:03 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4DFE3A6AB0 for ; Thu, 26 Jun 2008 05:14:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to netlmm awaits moderator approval From: netlmm-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Thu, 26 Jun 2008 05:14:02 -0700 Precedence: bulk X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETLMM working group discussion list X-List-Administrivia: yes Sender: netlmm-bounces@ietf.org Errors-To: netlmm-bounces@ietf.org Your mail to 'netlmm' with the subject Tag Heuer replicas better than originals Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netlmm/65a320050943cf74e4a61c45237b355811fd3dcd From nfsv4-bounces@ietf.org Thu Jun 26 05:14:03 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0D5A3A6AB5 for ; Thu, 26 Jun 2008 05:14:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nfsv4 awaits moderator approval From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Thu, 26 Jun 2008 05:14:03 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org Your mail to 'nfsv4' with the subject Tag Heuer replicas better than originals Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nfsv4/d863cb3795f9b0e84c3e20873bc99f4ec9dfa00d From nsis-imp-bounces@ietf.org Thu Jun 26 05:14:03 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5D093A6AB2 for ; Thu, 26 Jun 2008 05:14:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NSIS-imp awaits moderator approval From: nsis-imp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Thu, 26 Jun 2008 05:14:03 -0700 Precedence: bulk X-BeenThere: nsis-imp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for implementation questions for NSIS protocols X-List-Administrivia: yes Sender: nsis-imp-bounces@ietf.org Errors-To: nsis-imp-bounces@ietf.org Your mail to 'NSIS-imp' with the subject Tag Heuer replicas better than originals Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis-imp/3a54a59bdf96facf86ddca4dd7da25777a06b8a6 From ngo-bounces@ietf.org Thu Jun 26 05:14:03 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E94853A6AB2 for ; Thu, 26 Jun 2008 05:14:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NGO awaits moderator approval From: ngo-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Thu, 26 Jun 2008 05:14:03 -0700 Precedence: bulk X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF X-List-Administrivia: yes Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Your mail to 'NGO' with the subject Tag Heuer replicas better than originals Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ngo/c96382df78e9525c744519eb9f069d169f37548d From nsis-bounces@ietf.org Thu Jun 26 05:14:05 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22B4E3A6AB9 for ; Thu, 26 Jun 2008 05:14:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nsis awaits moderator approval From: nsis-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Thu, 26 Jun 2008 05:14:04 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Your mail to 'nsis' with the subject Tag Heuer replicas better than originals Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis/3d6681314e938cc999e67bfd82716d56eb888d9c From ntdp-bounces@ietf.org Thu Jun 26 05:14:05 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2902A3A6ABC for ; Thu, 26 Jun 2008 05:14:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NTDP awaits moderator approval From: ntdp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Thu, 26 Jun 2008 05:14:04 -0700 Precedence: bulk X-BeenThere: ntdp@ietf.org X-Mailman-Version: 2.1.9 List-Id: define standards for the purpose of scripting of network testing equipment X-List-Administrivia: yes Sender: ntdp-bounces@ietf.org Errors-To: ntdp-bounces@ietf.org Your mail to 'NTDP' with the subject Tag Heuer replicas better than originals Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ntdp/6b32da9d6cb6448fe469fd9ed0c20450fd8be67d From mext-bounces@ietf.org Thu Jun 26 05:14:22 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00CBA3A6AB0; Thu, 26 Jun 2008 05:14:22 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06D6B3A6A99 for ; Thu, 26 Jun 2008 05:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGIYx8tOGvSb for ; Thu, 26 Jun 2008 05:14:20 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id ECA563A6A70 for ; Thu, 26 Jun 2008 05:14:18 -0700 (PDT) Received: from [124.190.105.201] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1KBqMk-0001Oj-Hu; Thu, 26 Jun 2008 22:14:18 +1000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 26 Jun 2008 22:14:00 +1000 From: Hesham Soliman To: Joel Hortelius , Message-ID: Thread-Topic: [MEXT] DSMIPv6 Dynamic Prefix Allocation/Home Address & Prefix Length Thread-Index: AcjXhh133itq0Fm9fEajr+UgzYQxXQ== In-Reply-To: <1214478919.11693.29.camel@localhost.localdomain> Mime-version: 1.0 Subject: Re: [MEXT] DSMIPv6 Dynamic Prefix Allocation/Home Address & Prefix Length X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On 26/06/08 9:15 PM, "Joel Hortelius" wrote: > Hi; > > A question regarding the home address/home address ack options; > > In the ACK option, if I request a home address(not a prefix), will it be > set to '32' or will it be set to the subnet length of the network the > home address belongs to? => It will be set to 32. > > If its set to the network subnet length, which would provide more > information and making "returning home" much easier, => The spec does not detect "returning home" using IPv4. This spec assumes the home network MUST be IPv6 enabled, therefore movement detection for the home network is done according to DNAv6 and RFC3775. > Why does not the ack also contain the PREFIX flag, if it's in reply to a > PREFIX allocation? => Because it adds no information for the purpose of the spec. Hesham > > Regards, > Joel Hortelius. > > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 26 06:00:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 508AD28C140; Thu, 26 Jun 2008 06:00:04 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8E228C122 for ; Thu, 26 Jun 2008 06:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoD1YudyJQE8 for ; Thu, 26 Jun 2008 06:00:02 -0700 (PDT) Received: from nw-smtp-03.wineasy.se (nw-smtp-03.wineasy.se [195.42.210.226]) by core3.amsl.com (Postfix) with ESMTP id 13C833A6909 for ; Thu, 26 Jun 2008 06:00:01 -0700 (PDT) Received: from [10.1.2.47] (static-213.88.172.99.addr.tdcsong.se [213.88.172.99]) by nw-smtp-03.wineasy.se (Postfix) with ESMTP id DE14A6A1586; Thu, 26 Jun 2008 15:00:02 +0200 (CEST) From: Joel Hortelius To: Hesham Soliman In-Reply-To: References: Organization: Interpeak Date: Thu, 26 Jun 2008 14:02:35 +0000 Message-Id: <1214488955.11693.37.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 Cc: mext@ietf.org Subject: Re: [MEXT] DSMIPv6 Dynamic Prefix Allocation/Home Address & Prefix Length X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Still; If you use a v4 home address, you need to set up routing for that particular domain as well when returning home; v6 is not an issue, that's properly resolved, but for v4 you'd either need to resolve the prefix length somehow (using DHCP, perhaps), or have it statically configured; otherwise it'd be difficult to resolve what subnet mask to assign to the "returned home" interface for the v4 address. As it stands now, the information received through the DSMIPv6 options allows me to easily set up tunneling regarding the v4 domain; but not as easily set up a working "home" environment, which I assume should also be possible; I only have address/32; which is not really assignable on an interface if you want it usable. Regards, /J. On Thu, 2008-06-26 at 22:14 +1000, Hesham Soliman wrote: > > > On 26/06/08 9:15 PM, "Joel Hortelius" wrote: > > > Hi; > > > > A question regarding the home address/home address ack options; > > > > In the ACK option, if I request a home address(not a prefix), will it be > > set to '32' or will it be set to the subnet length of the network the > > home address belongs to? > > => It will be set to 32. > > > > > If its set to the network subnet length, which would provide more > > information and making "returning home" much easier, > > => The spec does not detect "returning home" using IPv4. This spec assumes > the home network MUST be IPv6 enabled, therefore movement detection for the > home network is done according to DNAv6 and RFC3775. > > > Why does not the ack also contain the PREFIX flag, if it's in reply to a > > PREFIX allocation? > > => Because it adds no information for the purpose of the spec. > > Hesham > > > > > Regards, > > Joel Hortelius. > > > > > > > > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 26 07:13:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DA7828C134; Thu, 26 Jun 2008 07:13:40 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533CE28C144 for ; Thu, 26 Jun 2008 07:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mteoOFzx5pYa for ; Thu, 26 Jun 2008 07:13:37 -0700 (PDT) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id 4D70728C134 for ; Thu, 26 Jun 2008 07:13:37 -0700 (PDT) Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs1.siemens.at with ESMTP id m5QEDbKE021077 for ; Thu, 26 Jun 2008 16:13:37 +0200 Received: from nets138a.ww300.siemens.net ([192.168.217.3]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m5QEDbAl030991 for ; Thu, 26 Jun 2008 16:13:37 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 16:13:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 16:13:35 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD68040E9E38@zagh223a.ww300.siemens.net> In-Reply-To: <486286F0.9010801@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] DSMIPv6 deregistration Thread-Index: AcjW7Lf5VvhlrreQSbOR6z7bx2MZtQAqLxuw References: <486286F0.9010801@ericsson.com> From: "Premec, Domagoj" To: X-OriginalArrivalTime: 26 Jun 2008 14:13:37.0186 (UTC) FILETIME=[D366E020:01C8D796] 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::080626161337-0BE1DBA0-6E06263A/0-0/0-15 X-purgate-size: 763/0 Subject: Re: [MEXT] DSMIPv6 deregistration X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org If ARP is used on the IPv4 home link, are there any requirements on the MN and HA related to proxy/gratuitous ARP when the MN returns home? domagoj > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Suresh Krishnan > Sent: 25. lipanj 2008 19:57 > To: mext@ietf.org > Subject: [MEXT] DSMIPv6 deregistration > > Hi Folks, > When the MN de-registers using DSMIPv6 and it had an IPv4 > address does it need to include the IPv4 Home Address Option > in the BU with lifetime 0? If so, is this a SHOULD or a MUST? > > Thanks > Suresh > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 26 09:07:09 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FE653A69F8; Thu, 26 Jun 2008 09:07:09 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07BDC3A69F8 for ; Thu, 26 Jun 2008 09:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1H-UOvMBU2gE for ; Thu, 26 Jun 2008 09:07:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 26A6B3A6774 for ; Thu, 26 Jun 2008 09:07:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,709,1204531200"; d="scan'208";a="60593556" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 26 Jun 2008 09:07:10 -0700 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 m5QG7AkS004266; Thu, 26 Jun 2008 09:07:10 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5QG7A6d019238; Thu, 26 Jun 2008 16:07:10 GMT Date: Thu, 26 Jun 2008 09:07:10 -0700 (PDT) From: Sri Gundavelli To: Hesham Soliman In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1710; t=1214496430; x=1215360430; 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]=20DSMIPv6=20deregistration |Sender:=20; bh=zyKHzk9G8mXOVOHu04cwHtlc0lCHCsB3cVJFQI0stXc=; b=w8hfHvzF8fAAjiuCn/XeKIwL8fBfxpCVA7QZk+kaOpODqNKJDlNw0B9xIH Cpncxmb/BmdUqzVSh+Rn1mQ/Rct1fWGUxqFBfdrGjoH0KXQx9SHONRzxjWin fqygj/Md0x; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] DSMIPv6 deregistration X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Thu, 26 Jun 2008, Hesham Soliman wrote: >>> If you have two separate bindings, you need to link them in your >>> implementation. If the primary binding cache entry (I consider the one >>> for the IPv6 home address as the primary one) is removed, the IPv4 home >>> address binding cache entry should also be removed. >>> >> >> If the draft has recommendation for seperate binding entries, > > => The draft has no such recommendation. There is only one logical > binding and that is tied to the IPv6 address. > Ok. Fine. These two places on BCE and BUL entries, it suggested multiple entries. May be you may want to be specific, since this is one mobility session, its still one logical entry. However, I'd prefer to keep all the state associated to a mobility session in one BCE entry, just as how NEMO does. This special BCE linking as Vijay suggested is not implied, that needlessly changes the BCE data structure implementation on existing HA's. Sec 5.5, On BCE entries If the binding update is accepted for both IPv4 and IPv6 home addresses, the home agent creates separate binding cache entries, one for each home address. The care-of address is the one included in the binding update. If the care-of address is an IPv4 address, the home agent MUST setup a tunnel to the IPv4 care-of address of the mobile node. 5.4: On BUL entries: If the mobility header includes an IPv4 address acknowledgement option indicating success, the mobile node should create two entries in its binding update list, one for the IPv6 home address and another for the IPv4 home address. Thanks Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 26 09:20:27 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A19A3A699D; Thu, 26 Jun 2008 09:20:27 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22DB43A699D for ; Thu, 26 Jun 2008 09:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaUV17ow08-j for ; Thu, 26 Jun 2008 09:20:22 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id ABAAF3A6818 for ; Thu, 26 Jun 2008 09:20:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,709,1204531200"; d="scan'208";a="83495570" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 26 Jun 2008 09:20:24 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m5QGKOUA007411; Thu, 26 Jun 2008 09:20:24 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5QGKOgX003591; Thu, 26 Jun 2008 16:20:24 GMT Date: Thu, 26 Jun 2008 09:20:24 -0700 (PDT) From: Sri Gundavelli To: Hesham Soliman In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1276; t=1214497224; x=1215361224; 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]=20DSMIPv6=20deregistration |Sender:=20; bh=bUVj8WBQzFfjDLAI487A0+0lWpNBC9s5MmrvaxyzhyA=; b=WJ3308K23xoaN34uI7yDt7TdG5MuHfozDeqn3UsJZir8vJmmnEpaLWXl2W Is+5ELXeQepYF1WsCYLBz0En5/IBn6/BZWH/Gzrb8oO5kva6ZogL/SiyuTc6 +XsaSF3TMu; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] DSMIPv6 deregistration X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, On Thu, 26 Jun 2008, Hesham Soliman wrote: > Sri, the draft explicitly states that the HAO is not used in the BU. Please > check the BU format used. > I was referring to the IPv4 Home Address Option. Its is there in the BU. Specific question, if the mobile needs to include IPv4 HoA option for each of the currently assigned IPv4 home addresses or prefixes ? >From the below text, its not clear if the MN should include IPv4 home address option for each of the addresses. Also, I'm not sure if the format for re-registration messages is the same as the initial message, few lines will help. Or if it is there, if you can point me. 5.4: MN Operation: When sending a binding update from a visited network that supports IPv6, the mobile node MUST follow the rules specified in [RFC3775]. In addition, if the mobile node has an IPv4 home address or needs one, it MUST include the IPv4 home address option in the mobility header. If the mobile node already has a static IPv4 home address, this address MUST be included in the IPv4 home address option. Otherwise, if the mobile node needs a dynamic IPv4 address, it MUST include the IPv4 0.0.0.0 address in the IPv4 home address option. Thanks Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 26 09:24:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4143A3A695F; Thu, 26 Jun 2008 09:24:52 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 109033A695F for ; Thu, 26 Jun 2008 09:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.244 X-Spam-Level: X-Spam-Status: No, score=-6.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cd7jyyQ9JxFY for ; Thu, 26 Jun 2008 09:24:50 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B0B933A6774 for ; Thu, 26 Jun 2008 09:24:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,709,1204531200"; d="scan'208";a="45155730" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 26 Jun 2008 09:24:49 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5QGOnHC025641; Thu, 26 Jun 2008 09:24:49 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5QGOnYr010289; Thu, 26 Jun 2008 16:24:49 GMT Date: Thu, 26 Jun 2008 09:24:49 -0700 (PDT) From: Sri Gundavelli To: Hesham Soliman In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=459; t=1214497489; x=1215361489; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20DSMIPv6=20Dynamic=20Prefix=20A llocation/Home=20Address=20&=20Prefix=0A=20Length |Sender:=20; bh=mgGh94S4ryVS6ptCh3pb35Q4jm6eRAlmkaWxzuJDCtM=; b=EsM/6Q4mDR8woE9gWtNJt1EW/1t8OXm6WIdPtZpAv6116qflqBTh7M/D6b 8Dx8VFrZJl8VNmUSSknOIBI6TNIGnOgG729ziQzqQEgj/Y5AHpJOYYBF7p17 69ItAj48HjwbTQiYTqBGuFun/iAo5LqkCgNrO2p8dA/CjnCNSghOQ=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] DSMIPv6 Dynamic Prefix Allocation/Home Address & Prefix Length X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Thu, 26 Jun 2008, Hesham Soliman wrote: >> In the ACK option, if I request a home address(not a prefix), will it be >> set to '32' or will it be set to the subnet length of the network the >> home address belongs to? > > => It will be set to 32. > Since, the (P) flag is there, to indicate if its a host address or a prefix, returning the actual prefix length will be useful, instead of returning 32, and HA has the prefix length. Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 26 17:50:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BAE63A67FB; Thu, 26 Jun 2008 17:50:00 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C94F3A6855 for ; Thu, 26 Jun 2008 17:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78LJekIF9Y5Y for ; Thu, 26 Jun 2008 17:49:55 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id AF4863A67A8 for ; Thu, 26 Jun 2008 17:49:54 -0700 (PDT) Received: from [124.190.105.201] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1KC29w-0004rv-D9; Fri, 27 Jun 2008 10:49:52 +1000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 27 Jun 2008 10:49:31 +1000 From: Hesham Soliman To: Sri Gundavelli Message-ID: Thread-Topic: [MEXT] DSMIPv6 deregistration Thread-Index: AcjX76jYDoO818WUuEG8TY1zLzsqyA== In-Reply-To: Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] DSMIPv6 deregistration X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Sri, > > I was referring to the IPv4 Home Address Option. Its is there in the > BU. Specific question, if the mobile needs to include IPv4 HoA option > for each of the currently assigned IPv4 home addresses or prefixes ? => Yes. Also, I'm not sure if the > format for re-registration messages is the same as the initial message, > few lines will help. Or if it is there, if you can point me. => I don't think there is anything in the spec about that. The BU, as defined in 3775 is always the same format, there is no distinction between the format for initial and refresh AFAIK. We don't need to talk about that because you only talk about something when you've deviated from the well-known norm. Otherwise, we would have to repeat major sections of 3775. Hesham > > > 5.4: MN Operation: > > When sending a binding update from a visited network that supports > IPv6, the mobile node MUST follow the rules specified in [RFC3775]. > In addition, if the mobile node has an IPv4 home address or needs > one, it MUST include the IPv4 home address option in the mobility > header. If the mobile node already has a static IPv4 home address, > this address MUST be included in the IPv4 home address option. > Otherwise, if the mobile node needs a dynamic IPv4 address, it MUST > include the IPv4 0.0.0.0 address in the IPv4 home address option. > > > Thanks > Sri > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 26 18:01:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C18183A6807; Thu, 26 Jun 2008 18:01:12 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 185203A6807 for ; Thu, 26 Jun 2008 18:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CK9o2ro0yZDk for ; Thu, 26 Jun 2008 18:01:10 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 416623A679F for ; Thu, 26 Jun 2008 18:01:10 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 21:01:07 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] DSMIPv6 Dynamic Prefix Allocation/Home Address & Prefix Length Thread-Index: AcjXqS6zIY8P0uYvTCO05b5lsooemQAR4Jjw References: From: "Vijay Devarapalli" To: "Sri Gundavelli" , "Hesham Soliman" , "Joel Hortelius" Cc: mext@ietf.org Subject: Re: [MEXT] DSMIPv6 Dynamic Prefix Allocation/Home Address & Prefix Length X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org One possible simplification is to set the 'P' flag in both the request and the reply whenever a prefix is requested/returned. In case a single address is being sent, the "prefix-len" field would be used to carry the network subnet length. The 'P' flag would be unset. Comments? Vijay > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf > Of Sri Gundavelli > Sent: Thursday, June 26, 2008 9:25 AM > To: Hesham Soliman > Cc: mext@ietf.org > Subject: Re: [MEXT] DSMIPv6 Dynamic Prefix Allocation/Home Address & > Prefix Length > > > > On Thu, 26 Jun 2008, Hesham Soliman wrote: > > >> In the ACK option, if I request a home address(not a prefix), will > it be > >> set to '32' or will it be set to the subnet length of the network > the > >> home address belongs to? > > > > => It will be set to 32. > > > > Since, the (P) flag is there, to indicate if its a host address or > a prefix, returning the actual prefix length will be useful, instead > of returning 32, and HA has the prefix length. > > Sri > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 26 18:05:43 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892113A6A4C; Thu, 26 Jun 2008 18:05:43 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E62B63A6A7C for ; Thu, 26 Jun 2008 18:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNHp0sbjkl-o for ; Thu, 26 Jun 2008 18:05:41 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1938D3A6A4C for ; Thu, 26 Jun 2008 18:05:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,712,1204531200"; d="scan'208";a="45430521" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 26 Jun 2008 18:05:44 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5R15ibE025759; Thu, 26 Jun 2008 18:05:44 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5R15iO7013623; Fri, 27 Jun 2008 01:05:44 GMT Date: Thu, 26 Jun 2008 18:05:44 -0700 (PDT) From: Sri Gundavelli To: Hesham Soliman In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1163; t=1214528744; x=1215392744; 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]=20DSMIPv6=20deregistration |Sender:=20; bh=vCtheOzxOwgxIUE0Wdu+Mc5sNCOeqety7b+xjM1KzBs=; b=xDcyxjNeKchh4Bt3feObMrw09QMPiaoZTvfRj2EK3hhrknP6kBhe8Hr4pT SXsAY2I5/wQ2H9jJ7mgQQUi5WapysHixbPlb4Kqg93VGNjNmdOC0SOySFMEi JZsSgvVnIx; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] DSMIPv6 deregistration X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hesham, On Fri, 27 Jun 2008, Hesham Soliman wrote: > Sri, > > >> >> I was referring to the IPv4 Home Address Option. Its is there in the >> BU. Specific question, if the mobile needs to include IPv4 HoA option >> for each of the currently assigned IPv4 home addresses or prefixes ? > > => Yes. > > Also, I'm not sure if the >> format for re-registration messages is the same as the initial message, >> few lines will help. Or if it is there, if you can point me. > > => I don't think there is anything in the spec about that. The BU, as > defined in 3775 is always the same format, there is no distinction between > the format for initial and refresh AFAIK. We don't need to talk about that > because you only talk about something when you've deviated from the > well-known norm. Otherwise, we would have to repeat major sections of 3775. > Sorry, I was not clear. When I say format, I meant if all the IPv4 HoA options should be present and if the values should reflect the assigned values or if the PBU can just be the initial PBU and potentially with the option values of 0.0.0.0. Fine, if you think this is implied. Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jun 26 18:06:41 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5E53A6A7C; Thu, 26 Jun 2008 18:06:41 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58B693A6A97 for ; Thu, 26 Jun 2008 18:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjZ+H30a00oN for ; Thu, 26 Jun 2008 18:06:39 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6CFAC3A6A8E for ; Thu, 26 Jun 2008 18:06:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,712,1204531200"; d="scan'208";a="45430829" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 26 Jun 2008 18:06:43 -0700 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 m5R16h7u024762; Thu, 26 Jun 2008 18:06:43 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5R16hPI015746; Fri, 27 Jun 2008 01:06:43 GMT Date: Thu, 26 Jun 2008 18:06:42 -0700 (PDT) From: Sri Gundavelli To: Vijay Devarapalli In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1363; t=1214528803; x=1215392803; 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]=20DSMIPv6=20Dynamic=20Prefix=20A llocation/Home=20Address=20&=20Prefix=0A=20Length |Sender:=20; bh=ExPl0gB9FRDKO9xpksTUFjWIyotl2s38L9c7tY1Ai7U=; b=TjMpk1en0BI1r/nDxQG2jXPUhkIc2DFB1hBCaHP/rPR8IBltHl1vAovB3O 33Zu7Ke4MyAfGaE5aLvU0ZS8uf2IWNRvN9Vb/NbQwtR2oIRPfMLQ/RQlaj5B H3IPB9r0Vg; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] DSMIPv6 Dynamic Prefix Allocation/Home Address & Prefix Length X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org That's what I'm suggesting as well. Sri On Thu, 26 Jun 2008, Vijay Devarapalli wrote: > One possible simplification is to set the 'P' flag in both the request > and the reply whenever a prefix is requested/returned. > > In case a single address is being sent, the "prefix-len" field would be > used to carry the network subnet length. The 'P' flag would be unset. > > Comments? > > Vijay > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf >> Of Sri Gundavelli >> Sent: Thursday, June 26, 2008 9:25 AM >> To: Hesham Soliman >> Cc: mext@ietf.org >> Subject: Re: [MEXT] DSMIPv6 Dynamic Prefix Allocation/Home Address & >> Prefix Length >> >> >> >> On Thu, 26 Jun 2008, Hesham Soliman wrote: >> >>>> In the ACK option, if I request a home address(not a prefix), will >> it be >>>> set to '32' or will it be set to the subnet length of the network >> the >>>> home address belongs to? >>> >>> => It will be set to 32. >>> >> >> Since, the (P) flag is there, to indicate if its a host address or >> a prefix, returning the actual prefix length will be useful, instead >> of returning 32, and HA has the prefix length. >> >> Sri >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From c.gill@psychsol.com Thu Jun 26 18:58:32 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D8DB3A6846; Thu, 26 Jun 2008 18:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -74.079 X-Spam-Level: X-Spam-Status: No, score=-74.079 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rj5AS5qLzl2G; Thu, 26 Jun 2008 18:58:31 -0700 (PDT) Received: from 92-143-246-201.adsl.terra.cl (92-143-246-201.adsl.terra.cl [201.246.143.92]) by core3.amsl.com (Postfix) with SMTP id BEAE93A679F; Thu, 26 Jun 2008 18:58:23 -0700 (PDT) X-Originating-IP: 206.243.133.218 by smtp.201.246.143.92; Thu, 26 Jun 2008 21:58:29 -0500 Message-ID: From: "Aimee Holbrook" Reply-To: "Aimee Holbrook" To: nemo-archive@ietf.org Subject: Inexpensive IWC watches Date: Thu, 26 Jun 2008 21:58:29 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Diamond Replicas, the web's most comprehensive collection of brand name replica watches. In Diamond Replicas, any Tag Heuer is available for just over $200. http://cipyzasupet74.blogspot.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Diamond Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Diamond Replicas. http://cipyzasupet74.blogspot.com/ From netlmm-bounces@ietf.org Thu Jun 26 18:58:33 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB48B28C0D7 for ; Thu, 26 Jun 2008 18:58:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to netlmm awaits moderator approval From: netlmm-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Thu, 26 Jun 2008 18:58:33 -0700 Precedence: bulk X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETLMM working group discussion list X-List-Administrivia: yes Sender: netlmm-bounces@ietf.org Errors-To: netlmm-bounces@ietf.org Your mail to 'netlmm' with the subject Inexpensive IWC watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/netlmm/e43bd35a0db128cc8c387679f0c3fff39dba704b From nfsv4-bounces@ietf.org Thu Jun 26 18:58:33 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D27A128C0D7 for ; Thu, 26 Jun 2008 18:58:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nfsv4 awaits moderator approval From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Thu, 26 Jun 2008 18:58:33 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org Your mail to 'nfsv4' with the subject Inexpensive IWC watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nfsv4/31629839c936b212171ed88129b53ff55efc7113 From ngo-bounces@ietf.org Thu Jun 26 18:58:33 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6C0228C0D7 for ; Thu, 26 Jun 2008 18:58:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NGO awaits moderator approval From: ngo-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Thu, 26 Jun 2008 18:58:33 -0700 Precedence: bulk X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF X-List-Administrivia: yes Sender: ngo-bounces@ietf.org Errors-To: ngo-bounces@ietf.org Your mail to 'NGO' with the subject Inexpensive IWC watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ngo/59e4867db913319d50ce22a045707607d54c619e From ntdp-bounces@ietf.org Thu Jun 26 18:58:33 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD88128C0F0 for ; Thu, 26 Jun 2008 18:58:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NTDP awaits moderator approval From: ntdp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Thu, 26 Jun 2008 18:58:33 -0700 Precedence: bulk X-BeenThere: ntdp@ietf.org X-Mailman-Version: 2.1.9 List-Id: define standards for the purpose of scripting of network testing equipment X-List-Administrivia: yes Sender: ntdp-bounces@ietf.org Errors-To: ntdp-bounces@ietf.org Your mail to 'NTDP' with the subject Inexpensive IWC watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ntdp/150b44cec08d2d2c0dbc2d374c06f09de2f138f4 From nsis-bounces@ietf.org Thu Jun 26 18:58:33 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAB1828C0D7 for ; Thu, 26 Jun 2008 18:58:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to nsis awaits moderator approval From: nsis-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Thu, 26 Jun 2008 18:58:33 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Your mail to 'nsis' with the subject Inexpensive IWC watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis/e155bb4f60b1819da316bf26e4e2213482e86c79 From nemo-bounces@ietf.org Thu Jun 26 18:58:34 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E9C28C0D7 for ; Thu, 26 Jun 2008 18:58:33 -0700 (PDT) Subject: The results of your email commands From: nemo-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1798902261==" Message-ID: Date: Thu, 26 Jun 2008 18:58:33 -0700 Precedence: bulk X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.9 List-Id: NEMO Working Group X-List-Administrivia: yes Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --===============1798902261== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://cipyzasupet74.blogspot.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Diamond Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Diamond Replicas. http://cipyzasupet74.blogspot.com/ - Done. --===============1798902261== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nemo-request@core3.amsl.com Delivered-To: nemo-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D8DB3A6846; Thu, 26 Jun 2008 18:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -74.079 X-Spam-Level: X-Spam-Status: No, score=-74.079 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rj5AS5qLzl2G; Thu, 26 Jun 2008 18:58:31 -0700 (PDT) Received: from 92-143-246-201.adsl.terra.cl (92-143-246-201.adsl.terra.cl [201.246.143.92]) by core3.amsl.com (Postfix) with SMTP id BEAE93A679F; Thu, 26 Jun 2008 18:58:23 -0700 (PDT) X-Originating-IP: 206.243.133.218 by smtp.201.246.143.92; Thu, 26 Jun 2008 21:58:29 -0500 Message-ID: From: "Aimee Holbrook" Reply-To: "Aimee Holbrook" To: nemo-archive@ietf.org Subject: Inexpensive IWC watches Date: Thu, 26 Jun 2008 21:58:29 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Diamond Replicas, the web's most comprehensive collection of brand name replica watches. In Diamond Replicas, any Tag Heuer is available for just over $200. http://cipyzasupet74.blogspot.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Diamond Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Diamond Replicas. http://cipyzasupet74.blogspot.com/ --===============1798902261==-- From nfsv4-bounces@ietf.org Thu Jun 26 18:58:34 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02DDA28C0D7 for ; Thu, 26 Jun 2008 18:58:34 -0700 (PDT) Subject: The results of your email commands From: nfsv4-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1156190159==" Message-ID: Date: Thu, 26 Jun 2008 18:58:33 -0700 Precedence: bulk X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.9 List-Id: NFSv4 Working Group X-List-Administrivia: yes Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org --===============1156190159== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://cipyzasupet74.blogspot.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Diamond Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Diamond Replicas. http://cipyzasupet74.blogspot.com/ - Done. --===============1156190159== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nfsv4-request@core3.amsl.com Delivered-To: nfsv4-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D8DB3A6846; Thu, 26 Jun 2008 18:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -74.079 X-Spam-Level: X-Spam-Status: No, score=-74.079 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rj5AS5qLzl2G; Thu, 26 Jun 2008 18:58:31 -0700 (PDT) Received: from 92-143-246-201.adsl.terra.cl (92-143-246-201.adsl.terra.cl [201.246.143.92]) by core3.amsl.com (Postfix) with SMTP id BEAE93A679F; Thu, 26 Jun 2008 18:58:23 -0700 (PDT) X-Originating-IP: 206.243.133.218 by smtp.201.246.143.92; Thu, 26 Jun 2008 21:58:29 -0500 Message-ID: From: "Aimee Holbrook" Reply-To: "Aimee Holbrook" To: nemo-archive@ietf.org Subject: Inexpensive IWC watches Date: Thu, 26 Jun 2008 21:58:29 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Diamond Replicas, the web's most comprehensive collection of brand name replica watches. In Diamond Replicas, any Tag Heuer is available for just over $200. http://cipyzasupet74.blogspot.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Diamond Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Diamond Replicas. http://cipyzasupet74.blogspot.com/ --===============1156190159==-- From nsis-bounces@ietf.org Thu Jun 26 18:58:34 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04F7C28C0DE for ; Thu, 26 Jun 2008 18:58:34 -0700 (PDT) Subject: The results of your email commands From: nsis-bounces@ietf.org To: nemo-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0472950403==" Message-ID: Date: Thu, 26 Jun 2008 18:58:33 -0700 Precedence: bulk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 List-Id: Next Steps in Signaling X-List-Administrivia: yes Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============0472950403== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://cipyzasupet74.blogspot.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Diamond Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Diamond Replicas. http://cipyzasupet74.blogspot.com/ - Done. --===============0472950403== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: nsis-request@core3.amsl.com Delivered-To: nsis-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D8DB3A6846; Thu, 26 Jun 2008 18:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -74.079 X-Spam-Level: X-Spam-Status: No, score=-74.079 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rj5AS5qLzl2G; Thu, 26 Jun 2008 18:58:31 -0700 (PDT) Received: from 92-143-246-201.adsl.terra.cl (92-143-246-201.adsl.terra.cl [201.246.143.92]) by core3.amsl.com (Postfix) with SMTP id BEAE93A679F; Thu, 26 Jun 2008 18:58:23 -0700 (PDT) X-Originating-IP: 206.243.133.218 by smtp.201.246.143.92; Thu, 26 Jun 2008 21:58:29 -0500 Message-ID: From: "Aimee Holbrook" Reply-To: "Aimee Holbrook" To: nemo-archive@ietf.org Subject: Inexpensive IWC watches Date: Thu, 26 Jun 2008 21:58:29 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Diamond Replicas, the web's most comprehensive collection of brand name replica watches. In Diamond Replicas, any Tag Heuer is available for just over $200. http://cipyzasupet74.blogspot.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Diamond Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Diamond Replicas. http://cipyzasupet74.blogspot.com/ --===============0472950403==-- From nsis-imp-bounces@ietf.org Thu Jun 26 18:58:34 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0887828C0D7 for ; Thu, 26 Jun 2008 18:58:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to NSIS-imp awaits moderator approval From: nsis-imp-bounces@ietf.org To: nemo-archive@ietf.org Message-ID: Date: Thu, 26 Jun 2008 18:58:33 -0700 Precedence: bulk X-BeenThere: nsis-imp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for implementation questions for NSIS protocols X-List-Administrivia: yes Sender: nsis-imp-bounces@ietf.org Errors-To: nsis-imp-bounces@ietf.org Your mail to 'NSIS-imp' with the subject Inexpensive IWC watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/nsis-imp/d92841a47c8e533c3abd16c3b4c0f205973338c4 From mext-bounces@ietf.org Fri Jun 27 12:08:28 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 399143A68C8; Fri, 27 Jun 2008 12:08:28 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 669ED3A68C8 for ; Fri, 27 Jun 2008 12:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOy7tEvybxGe for ; Fri, 27 Jun 2008 12:08:25 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 70A1F3A68B4 for ; Fri, 27 Jun 2008 12:08:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=EPooe+KF/VnaDIMLJ1yVOInic5fNo8cueFnVRqF2LGOU01NT7UWeAy5xaIsynYQK; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.89]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KCJJ8-00085E-EU for mext@ietf.org; Fri, 27 Jun 2008 15:08:30 -0400 Message-ID: <48653AAD.6020909@earthlink.net> Date: Fri, 27 Jun 2008 12:08:29 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mext@ietf.org X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52f2dfbe4efa7ee4d218a63fd05f0e3f6d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Subject: [MEXT] Issue #1: Last accepted SQN X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, The intention in RFC 3775 was pretty clearly to allow the mobile node to update its record for the sequence number. An authenticated Binding Acknowledgement is clearly useful for this purpose. The discussion up until now was sticking on the need for a new protocol element, which Ahmad specified as an extension. Since I'm in the process of collecting mailing-list inputs and trying to make recommendations according to the discussion so far, I thought I'd like to at least suggest a text revision for rfc3775bis that (a) allows the original intention of RFC 3775 but (b) does not require a new protocol element. ======================================================================== OLD TEXT: o The Sequence Number field matches the Sequence Number sent by the mobile node to this destination address in an outstanding Binding Update. ======================================================================== NEW TEXT: o The Sequence Number field matches the Sequence Number sent by the mobile node to this destination address in an outstanding Binding Update, and the Status field is not 135. ... and, just before the bulleted text for Status field #1 (currently on pg. 139): o Additionally, if the Binding Acknowledgement correctly passes authentication and the Status field value is 135 (Sequence Number out of window), then the mobile node MUST update its binding sequence number appropriately to match the sequence number given in the Binding Acknowledgement. Otherwise, if the Status field value is 135 but the the Binding Acknowledgement does not pass authentication, the message MUST be silently ignored. ======================================================================== If this is O.K., I plan to use it as a recommendation for resolution of this issue. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 27 13:22:19 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE76C3A6B1C; Fri, 27 Jun 2008 13:22:19 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26B003A6821 for ; Fri, 27 Jun 2008 13:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyloEhDgbPf0 for ; Fri, 27 Jun 2008 13:22:18 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 203073A6B1C for ; Fri, 27 Jun 2008 13:22:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=SPKaDBx936M24FTaNnMDfy003WbR7DaSrpnHu3xo5lwBPeLHJEiyJxuDR5RjolhC; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.89]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KCKSb-0005e1-Bn; Fri, 27 Jun 2008 16:22:21 -0400 Message-ID: <48654BFB.5000005@earthlink.net> Date: Fri, 27 Jun 2008 13:22:19 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mext@ietf.org References: <200803271024.49601.julien.IETF@laposte.net> In-Reply-To: <200803271024.49601.julien.IETF@laposte.net> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5203f5a805b718dfee962a99368f315836350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: Julien Laganier Subject: [MEXT] Issue #2: Recommendation for closure on on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, After 80,000 messages, discussion about the DHAAD discovery message suddenly stopped when, it seemed to me, a resolution was nearly at hand. After reading through the "harmful" ID that was submitted, I imported a bit of text for another try at a resolution to be used in rfc3775bis. Here is the resulting modification to Julien's previous effort. ------------------------------------------------------------------------ OLD: 15.5. Dynamic Home Agent Address Discovery The dynamic home agent address discovery function could be used to learn the addresses of home agents in the home network. The ability to learn addresses of nodes may be useful to attackers because brute-force scanning of the address space is not practical with IPv6. Thus, they could benefit from any means which make mapping the networks easier. For example, if a security threat targeted at routers or even home agents is discovered, having a simple ICMP mechanism to easily find out possible targets may prove to be an additional (though minor) security risk. Apart from discovering the address(es) of home agents, attackers will not be able to learn much from this information, and mobile nodes cannot be tricked into using wrong home agents, as all other communication with the home agents is secure. NEW: 15.5. Dynamic Home Agent Address Discovery The dynamic home agent address discovery function could be used to learn the addresses of home agents in the home network. The ability to learn addresses of nodes may be useful to attackers because brute-force scanning of the address space is not practical with IPv6. Thus, they could benefit from any means which make mapping the networks easier. For example, if a security threat targeted at routers or even home agents is discovered, having a simple ICMP mechanism to easily find out possible targets may prove to be an additional (though minor) security risk. * This document does not define any authentication mechanism for * dynamic home agent address discovery messages. Therefore the home * agent cannot verify the home address of the mobile node that * requested the list of home agents. Apart from discovering the address(es) of home agents, attackers will not be able to learn much from this information, and mobile nodes cannot be tricked into using wrong home agents, as all other communication with the home agents is secure. * In cases where additional security is needed, one may consider * instead the use of MIPv6 bootstrapping [RFC5026] (based on * DNS SRV Resource Records [RFC2782]) in conjunction with security * mechanisms suggested in these specifications. In that solution, * security is provided by the DNSSEC [RFC4033] framework. The needed * pre-configured data on the mobile node for this mechanism is the * domain name of the mobile service provider, which is marginally better * than the home subnet prefix. For the security, a trust anchor which * dominates the domain is needed. * * Finally, it should be noted that the specification of ICMP to carry * DHAAD incurs a certain deployability risk related to the perceived * insecurity of ICMP messages. Many ISPs are blocking ICMP on all links * except the first hop, because ICMP is known to be a vehicle for DoS * attacks and other sorts of threats. ------------------------------------------------------------------------ Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 27 13:43:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C57DE3A6951; Fri, 27 Jun 2008 13:43:00 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 629193A6813 for ; Fri, 27 Jun 2008 13:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFs61Z2IMeyH for ; Fri, 27 Jun 2008 13:42:58 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 617293A682A for ; Fri, 27 Jun 2008 13:42:58 -0700 (PDT) Received: from localhost ([127.0.0.1]:47957 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KCKmZ-000527-Ep; Fri, 27 Jun 2008 22:42:59 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Fri, 27 Jun 2008 20:42:59 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/5 Message-ID: <063.2216c156b8d01873f711182105b99860@tools.ietf.org> X-Trac-Ticket-ID: 5 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: [MEXT] [mext] #5: Wrong protocol number used in discussion about checksum pseudo-header: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ticket #5: Wrong protocol number used in discussion about checksum pseudo-header: submitted by Jari Arkko : The mistake to use protocol number 2 and not 135, which I believe was correct and what everyone is truly using. This bug was introduced back when the was replaced from the draft to what became the RFC. ---- Proposed change: Section 6.1 (in discussion about Checksum, currently pg. 35): OLD: The pseudo-header contains IPv6 header fields, as specified in Section 8.1 of RFC 2460 [11]. The Next Header value used in the pseudo-header is 2. NEW: The pseudo-header contains IPv6 header fields, as specified in Section 8.1 of RFC 2460 [11]. The Next Header value used in the pseudo-header is 135. ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: Active WG Document | Keywords: ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 27 13:56:32 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1613B3A6AB9; Fri, 27 Jun 2008 13:56:32 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49D83A6A7A for ; Fri, 27 Jun 2008 13:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OadIe-Ghm0y0 for ; Fri, 27 Jun 2008 13:56:30 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id EADF53A6868 for ; Fri, 27 Jun 2008 13:56:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=bCZf0XSwcuLgCZqlyV9Y9hDfOxKaF8iWEh7i1dWjzhujFoGq51TyOKrDQ25HWFle; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.89]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KCKzj-0006Ly-9I for mext@ietf.org; Fri, 27 Jun 2008 16:56:35 -0400 Message-ID: <48655401.1060905@earthlink.net> Date: Fri, 27 Jun 2008 13:56:33 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mext@ietf.org X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52cdb166ab426bebc659b35bee2f71ae46350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Subject: [MEXT] Issue #5 (Wrong protocol number used in discussion about checksum pseudo-header:) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, I've created issue #5; see http://www3.tools.ietf.org/wg/mext/trac/ticket/5 I recommend accepting the proposed change in rfc3775bis-01. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 27 14:03:38 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BADD3A6B68; Fri, 27 Jun 2008 14:03:38 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E8623A6B63 for ; Fri, 27 Jun 2008 14:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAxVDQlqKJ-7 for ; Fri, 27 Jun 2008 14:03:35 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 5B4363A687C for ; Fri, 27 Jun 2008 14:03:35 -0700 (PDT) Received: from localhost ([127.0.0.1]:35678 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KCL6X-0005op-GH; Fri, 27 Jun 2008 23:03:37 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Fri, 27 Jun 2008 21:03:37 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/6 Message-ID: <063.6cdbee963dc30703959f827d9a9543eb@tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: [MEXT] [mext] #6: Minor editorial corrections and updates X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ticket #6: Minor editorial corrections and updates Submitted by Jari Arkko : Since the publication of RFC 3775, several of the references have progressed, have been republished, etc. ---- Section 9.3.2 (keyword capitalization): OLD: However, the sending node MUST not do this in the following cases: NEW: However, the sending node MUST NOT do this in the following cases: ---- Section 10.4.2 (missing paranthesis): OLD: Multicast packets addressed to a multicast address with a scope larger than link-local, but smaller than global (e.g., site- local and organization-local [3], to which the mobile node is subscribed, SHOULD NOT be tunneled to the mobile node. NEW: Multicast packets addressed to a multicast address with a scope larger than link-local, but smaller than global (e.g., site- local and organization-local [3]), to which the mobile node is subscribed, SHOULD NOT be tunneled to the mobile node. ---- Section 10.6.4 (keyword capitalization): OLD: As described in Section 10.3.1, the lifetime returned by the home agent in a Binding Acknowledgement MUST not be greater than the remaining valid lifetime for the subnet prefix in the mobile node's home address. NEW: As described in Section 10.3.1, the lifetime returned by the home agent in a Binding Acknowledgement MUST NOT be greater than the remaining valid lifetime for the subnet prefix in the mobile node's home address. ---- Section 11.7.3 (keyword capitalization): OLD: o The Binding Authorization Data mobility option, if present, MUST be the last option and MUST not have trailing padding. NEW: o The Binding Authorization Data mobility option, if present, MUST be the last option and MUST NOT have trailing padding. ---- Reference updates as follows: RFC 1750 => RFC 4086[[BR]] RFC 3513 => RFC 4291[[BR]] RFC 2424 => RFC 5226[[BR]] RFC 2461 => RFC 4861[[BR]] RFC 2462 => RFC 4862[[BR]] RFC 2463 => RFC 4443[[BR]] RFC 3041 => RFC 4941[[BR]] draft-bellovin-mandate-keymgmt-00 => RFC 4107[[BR]] draft-ietf-ipsec-ikev2-07 => RFC 4306[[BR]] draft-nikander-mobileip-v6-ro-sec-00 => RFC 4225[[BR]] ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: Active WG Document | Keywords: ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 27 14:17:08 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 806753A69C4; Fri, 27 Jun 2008 14:17:08 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC91F3A69C4 for ; Fri, 27 Jun 2008 14:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNyL8VMHC1SA for ; Fri, 27 Jun 2008 14:17:06 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id CC1683A6813 for ; Fri, 27 Jun 2008 14:17:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=FiYDfukjIRd2MMvL8ZK0S5qXTzBgInYHu59d3McQI+4C4jHWy5jXOWFi4V4WzwnY; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.89]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KCLJg-0003DQ-9M; Fri, 27 Jun 2008 17:17:12 -0400 Message-ID: <486558D6.1070803@earthlink.net> Date: Fri, 27 Jun 2008 14:17:10 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mext@ietf.org X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52e5ae244e4f5f30761054d1169a64d5bb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Subject: [MEXT] Issue #3 -- BRR, BErr are sent by HA too, not only by CN [Alexandru Petrescu ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, Further discussion gravitated towards creating two different issues, one for Binding Error and another for Binding Refresh Request. Recommendation: close this issue in favor of focusing comments on new issues that will be created, according to the more recent discussion on the mailing list. Note that most of the voluminous discussion was not captured on the issue tracker for issue #3. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 27 14:19:23 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BCDD3A6BE0; Fri, 27 Jun 2008 14:19:23 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8D53A6813 for ; Fri, 27 Jun 2008 14:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5NRkj0LJ1lH for ; Fri, 27 Jun 2008 14:19:22 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 168303A6BE0 for ; Fri, 27 Jun 2008 14:19:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=XqWJHCtvdCnrDyd46rbDojkylzX6s691t7nOjfFSJhR9Wk5fEivklZpTH2xtES0z; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.89]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KCLLr-0006gU-Qd for mext@ietf.org; Fri, 27 Jun 2008 17:19:28 -0400 Message-ID: <4865595E.4080603@earthlink.net> Date: Fri, 27 Jun 2008 14:19:26 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mext@ietf.org References: <063.6cdbee963dc30703959f827d9a9543eb@tools.ietf.org> In-Reply-To: <063.6cdbee963dc30703959f827d9a9543eb@tools.ietf.org> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52b4d9fa322caa4075a4fda8c5328771b4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Subject: Re: [MEXT] [mext] #6: Minor editorial corrections and updates X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, I've created issue #6; see http://www3.tools.ietf.org/wg/mext/trac/ticket/6 I recommend accepting the proposed changes in rfc3775bis-01. Regards, Charlie P. mext wrote: > Ticket #6: Minor editorial corrections and updates > > Submitted by Jari Arkko : > > Since the publication of RFC 3775, several of the references have > progressed, have been republished, etc. > > ---- > > Section 9.3.2 (keyword capitalization): > > OLD: > However, the sending node MUST not do this in the following cases: > > NEW: > However, the sending node MUST NOT do this in the following cases: > > ---- > > Section 10.4.2 (missing paranthesis): > OLD: > Multicast packets addressed to a multicast address with > a scope larger than link-local, but smaller than global (e.g., site- > local and organization-local [3], to which the mobile node is > subscribed, SHOULD NOT be tunneled to the mobile node. > > NEW: > Multicast packets addressed to a multicast address with > a scope larger than link-local, but smaller than global (e.g., site- > local and organization-local [3]), to which the mobile node is > subscribed, SHOULD NOT be tunneled to the mobile node. > > ---- > > Section 10.6.4 (keyword capitalization): > OLD: > As described in Section 10.3.1, the lifetime returned by the home > agent in a Binding Acknowledgement MUST not be greater than the > remaining valid lifetime for the subnet prefix in the mobile node's > home address. > > NEW: > As described in Section 10.3.1, the lifetime returned by the home > agent in a Binding Acknowledgement MUST NOT be greater than the > remaining valid lifetime for the subnet prefix in the mobile node's > home address. > > ---- > > Section 11.7.3 (keyword capitalization): > OLD: > o The Binding Authorization Data mobility option, if present, MUST > be the last option and MUST not have trailing padding. > > NEW: > o The Binding Authorization Data mobility option, if present, MUST > be the last option and MUST NOT have trailing padding. > > ---- > > Reference updates as follows: > > RFC 1750 => RFC 4086[[BR]] > > RFC 3513 => RFC 4291[[BR]] > > RFC 2424 => RFC 5226[[BR]] > > RFC 2461 => RFC 4861[[BR]] > > RFC 2462 => RFC 4862[[BR]] > > RFC 2463 => RFC 4443[[BR]] > > RFC 3041 => RFC 4941[[BR]] > > draft-bellovin-mandate-keymgmt-00 => RFC 4107[[BR]] > > draft-ietf-ipsec-ikev2-07 => RFC 4306[[BR]] > > draft-nikander-mobileip-v6-ro-sec-00 => RFC 4225[[BR]] > > > ----------------------------------------+----------------------------------- > Reporter: charliep@computer.org | Owner: charliep@computer.org > Type: defect | Status: new > Priority: minor | Milestone: > Component: draft-ietf-mext-rfc3775bis | Version: > Severity: Active WG Document | Keywords: > ----------------------------------------+----------------------------------- _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 27 14:49:20 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE3553A6921; Fri, 27 Jun 2008 14:49:19 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31BC43A6921 for ; Fri, 27 Jun 2008 14:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTq-iu88JBS5 for ; Fri, 27 Jun 2008 14:49:18 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 1286C3A68DF for ; Fri, 27 Jun 2008 14:49:17 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5RLnI524938; Fri, 27 Jun 2008 21:49:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 27 Jun 2008 16:49:02 -0500 Message-ID: In-Reply-To: <48653AAD.6020909@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Issue #1: Last accepted SQN Thread-Index: AcjYiTiJlV3JWjopQTSG/1xYpOACaAAFjksg References: <48653AAD.6020909@earthlink.net> From: "Ahmad Muhanna" To: "Charles E. Perkins" , Subject: Re: [MEXT] Issue #1: Last accepted SQN X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Charlie. I am fine with the suggested text. Cheers! Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Charles E. Perkins > Sent: Friday, June 27, 2008 2:08 PM > To: mext@ietf.org > Subject: [MEXT] Issue #1: Last accepted SQN > > Hello folks, > > The intention in RFC 3775 was pretty clearly to allow the > mobile node to update its record for the sequence number. An > authenticated Binding Acknowledgement is clearly useful for > this purpose. The discussion up until now was sticking on > the need for a new protocol element, which Ahmad specified as > an extension. > > Since I'm in the process of collecting mailing-list inputs > and trying to make recommendations according to the > discussion so far, I thought I'd like to at least suggest a > text revision for rfc3775bis that (a) allows the original > intention of RFC 3775 but (b) does not require a new protocol element. > > ============================================================== > ========== > > OLD TEXT: > > o The Sequence Number field matches the Sequence Number > sent by the > mobile node to this destination address in an > outstanding Binding > Update. > > ============================================================== > ========== > > NEW TEXT: > > o The Sequence Number field matches the Sequence Number > sent by the > mobile node to this destination address in an > outstanding Binding > Update, and the Status field is not 135. > > ... and, just before the bulleted text for Status field #1 > (currently on > pg. 139): > > o Additionally, if the Binding Acknowledgement correctly passes > authentication and the Status field value is 135 > (Sequence Number > out of window), then the mobile node MUST update its binding > sequence number appropriately to match the sequence number given > in the Binding Acknowledgement. Otherwise, if the Status field > value is 135 but the the Binding Acknowledgement does not pass > authentication, the message MUST be silently ignored. > > ============================================================== > ========== > > If this is O.K., I plan to use it as a recommendation for > resolution of this issue. > > Regards, > Charlie P. > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jun 27 14:55:41 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B78A43A6921; Fri, 27 Jun 2008 14:55:41 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42AE43A6921 for ; Fri, 27 Jun 2008 14:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SH6mUhtzDfZN for ; Fri, 27 Jun 2008 14:55:39 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 321713A68C5 for ; Fri, 27 Jun 2008 14:55:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=IoEPMPU1I1SULdmkl6UMeGXnzSBWJSHaK+f4YL4hERvwboNYVaUnbBaeR0uwgr4U; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.89]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KCLuu-0003Je-8H; Fri, 27 Jun 2008 17:55:40 -0400 Message-ID: <486561DA.8090609@earthlink.net> Date: Fri, 27 Jun 2008 14:55:38 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mext@ietf.org X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52a21adbfaba999ce8777377c2a9bcf03b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Subject: [MEXT] Issue #4 Remove references to site-local addresses [George Tsirtsis ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, I've reviewed the discussion about issue #4, and it seems to me that a relatively painless compromise is available. Namely, we could simply delete the "SHOULD NOT" recommendation regarding the use of ULAs as home or care-of addresses, while maintaining the cautionary note about potential inaccessibility of correspondent nodes. Here is the resultant text, which is otherwise almost identical to George's text except for splitting a run-on sentence into two sentences. --------------------------------------------------------------------------- OLD TEXT: ========= 3.1. General Terms ... unicast routable address An identifier for a single interface such that a packet sent to it from another IPv6 subnet is delivered to the interface identified by that address. Accordingly, a unicast routable address must have either a global or site-local scope (but not link-local). NEW TEXT: ========= 3.1. General Terms ... unicast routable address An identifier for a single interface such that a packet sent to it from another IPv6 subnet is delivered to the interface identified by that address. Accordingly, a unicast routable address must either be global IPv6 address or a unique local IPv6 address. --------------------------------------------------------------------------- OLD TEXT: ========= 4.6. Site-Local Addressability This specification requires that home and care-of addresses MUST be unicast routable addresses. Site-local addresses may be usable on networks that are not connected to the Internet, but this specification does not define when such usage is safe and when it is not. Mobile nodes may not be aware of which site they are currently in. It is hard to prevent accidental attachment to other sites, and ambiguity of site-local addresses can cause problems if the home and visited networks use the same addresses. Therefore, site-local addresses SHOULD NOT be used as home or care-of addresses. NEW TEXT: ========= 4.6. Unique-Local Addressability This specification requires that home and care-of addresses MUST be unicast routable addresses. Unique-local IPv6 unicast addresses [RFC4193] may be usable on networks that use such non-globaly routable addresses but this specification does not define when such usage is safe and when it is not. Mobile nodes may not be aware of which site they are currently making it hard to prevent accidental attachment to other sites, resulting in possible unrechability between the MN and the HA, when unique-local IPv6 routable addresses are used as care-of addresses. CNs outside the MN's own site are unlikely to be reachable when unique-local IPv6 routable addresses are used as home addresses. If such addresses are used, however, according to [RFC4193], they are treated as any other global unicast IPv6 address so, for the remainder of this specification, use of unique-local IPv6 unicast addresses is not differentiated from other globally unique IPv6 addresses. --------------------------------------------------------------------------- OLD TEXT: ========= 10.4.2. Processing Intercepted Packets ... ... Packets addressed to the mobile node's site-local address SHOULD NOT be tunneled to the mobile node by default. NEW TEXT (None: old text removed) ========= --------------------------------------------------------------------------- OLD TEXT: ========= 11.3.1. Sending Packets While Away from Home ... o While not at its home link, the mobile node MUST NOT use the Home Address destination option when communicating with link-local or site-local peers, if the scope of the home address is larger than the scope of the peer's address. NEW TEXT: ========= 11.3.1. Sending Packets While Away from Home ... o While not at its home link, the mobile node MUST NOT use the Home Address destination option when communicating with link-local peers. --------------------------------------------------------------------------- OLD TEXT: ========= 11.5.4. Returning Home ... ...The mobile node MUST multicast such a Neighbor Advertisement for each of its home addresses, as defined by the current on-link prefixes, including its link-local address and site-local address. NEW TEXT: ========= 11.5.4. Returning Home ... ...The mobile node MUST multicast such a Neighbor Advertisement for each of its home addresses, as defined by the current on-link prefixes, including its link-local address. --------------------------------------------------------------------------- I recommend accepting the above changes in rfc3775bis-01, and thereby resolving issue #4. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Jun 28 02:19:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B454128C217; Sat, 28 Jun 2008 02:19:53 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EE7528C1EE for ; Sat, 28 Jun 2008 02:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJjDxRKGhvfW for ; Sat, 28 Jun 2008 02:19:51 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 834E228C217 for ; Sat, 28 Jun 2008 02:19:51 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so847509wfd.31 for ; Sat, 28 Jun 2008 02:19:58 -0700 (PDT) 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:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=CSStFiDWUdHUbqvwFnij0V7ehh0DpV3+xbuvksyZ7JI=; b=cA7UCSu1Gs1kwJVlZ8eUf5Q48+XTcvlU8epZq1pNXwk98W6b6uZw301NZKoCkxYhKL T7c20bK1wNFRuueWhozedkEufaoWXEZ/IudvuMaRD2icUZlQ200+CR1Jj9daHn6Xxu+T Se3FAM+HA0mXumHeuHKfXrYr7yMK5+wJwsjp0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=uTpsGf8/d7AFLxPZ3ia+WJF/NHvt6jItb2tZR1mp11K8yM4recLr5vrwhuKFZ1qkN0 9Szi5UN+kdwdhsPnJYbVi+RVR/OKWlefUIldqgceiQm9HyCkeM96I+IrheHQliVhLJ+r hXKT48uhQeQswC006oO4SMdKtCZ30oR6RId/Q= Received: by 10.142.254.8 with SMTP id b8mr904861wfi.58.1214644798409; Sat, 28 Jun 2008 02:19:58 -0700 (PDT) Received: by 10.142.240.12 with HTTP; Sat, 28 Jun 2008 02:19:58 -0700 (PDT) Message-ID: Date: Sat, 28 Jun 2008 12:19:58 +0300 From: "George Tsirtsis" To: "Charles E. Perkins" , mext@ietf.org, "Arnaud Ebalard" In-Reply-To: <486561DA.8090609@earthlink.net> MIME-Version: 1.0 Content-Disposition: inline References: <486561DA.8090609@earthlink.net> Subject: Re: [MEXT] Issue #4 Remove references to site-local addresses [George Tsirtsis ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I am on vacation so I can not check your text right now, but I proposed text for this when I brought up the issue, a long time ago. Was anything wrong with it? Thanks George On 6/28/08, Charles E. Perkins wrote: > > Hello folks, > > I've reviewed the discussion about issue #4, and it seems to me that > a relatively painless compromise is available. Namely, we could simply > delete the "SHOULD NOT" recommendation regarding the use of > ULAs as home or care-of addresses, while maintaining the cautionary > note about potential inaccessibility of correspondent nodes. > > Here is the resultant text, which is otherwise almost identical to > George's text except for splitting a run-on sentence into two > sentences. > > --------------------------------------------------------------------------- > OLD TEXT: > ========= > 3.1. General Terms > ... > unicast routable address > > An identifier for a single interface such that a packet sent to it > from another IPv6 subnet is delivered to the interface identified > by that address. Accordingly, a unicast routable address must > have either a global or site-local scope (but not link-local). > > NEW TEXT: > ========= > 3.1. General Terms > ... > unicast routable address > > An identifier for a single interface such that a packet sent to it > from another IPv6 subnet is delivered to the interface identified > by that address. Accordingly, a unicast routable address must > either be global IPv6 address or a unique local IPv6 address. > > --------------------------------------------------------------------------- > > OLD TEXT: > ========= > 4.6. Site-Local Addressability > > > This specification requires that home and care-of addresses MUST be > unicast routable addresses. Site-local addresses may be usable on > networks that are not connected to the Internet, but this > specification does not define when such usage is safe and when it is > not. Mobile nodes may not be aware of which site they are currently > in. It is hard to prevent accidental attachment to other sites, and > ambiguity of site-local addresses can cause problems if the home and > visited networks use the same addresses. Therefore, site-local > addresses SHOULD NOT be used as home or care-of addresses. > > NEW TEXT: > ========= > 4.6. Unique-Local Addressability > > This specification requires that home and care-of addresses MUST be > unicast routable addresses. Unique-local IPv6 unicast addresses > [RFC4193] may be usable on networks that use such non-globaly routable > addresses but this specification does not define when such usage is > safe and when it is not. Mobile nodes may not be aware of which site > they are currently making it hard to prevent accidental attachment > to other sites, resulting in possible unrechability between the MN > and the HA, when unique-local IPv6 routable addresses are used as > care-of addresses. CNs outside the MN's own site are unlikely > to be reachable when unique-local IPv6 routable addresses are used > as home addresses. If such addresses are used, however, according > to [RFC4193], they are treated as any other global unicast IPv6 > address so, for the remainder of this specification, use of > unique-local IPv6 unicast addresses is not differentiated > from other globally unique IPv6 addresses. > > --------------------------------------------------------------------------- > > OLD TEXT: > ========= > 10.4.2. Processing Intercepted Packets > ... > ... Packets addressed to > the mobile node's site-local address SHOULD NOT be tunneled to the > mobile node by default. > > NEW TEXT (None: old text removed) > ========= > > --------------------------------------------------------------------------- > > OLD TEXT: > ========= > 11.3.1. Sending Packets While Away from Home > ... > o While not at its home link, the mobile node MUST NOT use the Home > Address destination option when communicating with link-local or > site-local peers, if the scope of the home address is larger than > the scope of the peer's address. > > NEW TEXT: > ========= > 11.3.1. Sending Packets While Away from Home > ... > o While not at its home link, the mobile node MUST NOT use the Home > Address destination option when communicating with link-local peers. > > --------------------------------------------------------------------------- > > OLD TEXT: > ========= > 11.5.4. Returning Home > ... > ...The mobile node MUST multicast such a > Neighbor Advertisement for each of its home addresses, as defined by > the current on-link prefixes, including its link-local address and > site-local address. > > NEW TEXT: > ========= > 11.5.4. Returning Home > ... > ...The mobile node MUST multicast such a > Neighbor Advertisement for each of its home addresses, as defined by > the current on-link prefixes, including its link-local address. > > --------------------------------------------------------------------------- > > I recommend accepting the above changes in rfc3775bis-01, and > thereby resolving issue #4. > > > Regards, > Charlie P. > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Jun 28 02:22:43 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C907428C237; Sat, 28 Jun 2008 02:22:43 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAAD228C235 for ; Sat, 28 Jun 2008 02:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejn225m1kkAa for ; Sat, 28 Jun 2008 02:22:41 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id 20C0C28C248 for ; Sat, 28 Jun 2008 02:22:20 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so847976wfd.31 for ; Sat, 28 Jun 2008 02:22:27 -0700 (PDT) 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:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=dgCg1iW0e6cnBhZSDgp6b5/EFI7LD/+tEXo68cK2EYY=; b=HZgac4Avs89S73mP9I5VUwi2U7OG1fCGlg+sfwmq4aRq87vozgXwifr10vwrUULGQ9 JlGlnCUoLhetuu0ja0IoZc4zw9JIKuC1dZHykLycOF8UwoMEXSXFqSVZOnM19xkzL3Ow UrjHKfslp7UA93pj2S1GfDCXoLTyBT/5yGmMM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=lxzeS/z+3GJxfvLMHa8uHngAyn6vD3In0lHyRct5dIIOdk5oSVkMUG/qI+DDMp7GoM P1IpWxv04nbe91MrxWwRt46d+Kd1p1fbJ8xZdRHiYhLr+Rtq1muYLLuHiuygm4UgmR28 D+hbzGMVUGQd5ns65KQr6zV9eCH7OqRObHIdc= Received: by 10.142.52.18 with SMTP id z18mr906979wfz.31.1214644947462; Sat, 28 Jun 2008 02:22:27 -0700 (PDT) Received: by 10.142.240.12 with HTTP; Sat, 28 Jun 2008 02:22:27 -0700 (PDT) Message-ID: Date: Sat, 28 Jun 2008 12:22:27 +0300 From: "George Tsirtsis" To: "Charles E. Perkins" , mext@ietf.org, "Arnaud Ebalard" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <486561DA.8090609@earthlink.net> Subject: Re: [MEXT] Issue #4 Remove references to site-local addresses [George Tsirtsis ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ah never mind, I just realised that the bulk of the text is what I originaly proposed. Sorry about that. Thanks George On 6/28/08, George Tsirtsis wrote: > I am on vacation so I can not check your text right now, but I > proposed text for this when I brought up the issue, a long time ago. > Was anything wrong with it? > > Thanks > George > > > > > On 6/28/08, Charles E. Perkins wrote: >> >> Hello folks, >> >> I've reviewed the discussion about issue #4, and it seems to me that >> a relatively painless compromise is available. Namely, we could simply >> delete the "SHOULD NOT" recommendation regarding the use of >> ULAs as home or care-of addresses, while maintaining the cautionary >> note about potential inaccessibility of correspondent nodes. >> >> Here is the resultant text, which is otherwise almost identical to >> George's text except for splitting a run-on sentence into two >> sentences. >> >> --------------------------------------------------------------------------- >> OLD TEXT: >> ========= >> 3.1. General Terms >> ... >> unicast routable address >> >> An identifier for a single interface such that a packet sent to it >> from another IPv6 subnet is delivered to the interface identified >> by that address. Accordingly, a unicast routable address must >> have either a global or site-local scope (but not link-local). >> >> NEW TEXT: >> ========= >> 3.1. General Terms >> ... >> unicast routable address >> >> An identifier for a single interface such that a packet sent to it >> from another IPv6 subnet is delivered to the interface identified >> by that address. Accordingly, a unicast routable address must >> either be global IPv6 address or a unique local IPv6 address. >> >> --------------------------------------------------------------------------- >> >> OLD TEXT: >> ========= >> 4.6. Site-Local Addressability >> >> >> This specification requires that home and care-of addresses MUST be >> unicast routable addresses. Site-local addresses may be usable on >> networks that are not connected to the Internet, but this >> specification does not define when such usage is safe and when it is >> not. Mobile nodes may not be aware of which site they are currently >> in. It is hard to prevent accidental attachment to other sites, and >> ambiguity of site-local addresses can cause problems if the home and >> visited networks use the same addresses. Therefore, site-local >> addresses SHOULD NOT be used as home or care-of addresses. >> >> NEW TEXT: >> ========= >> 4.6. Unique-Local Addressability >> >> This specification requires that home and care-of addresses MUST be >> unicast routable addresses. Unique-local IPv6 unicast addresses >> [RFC4193] may be usable on networks that use such non-globaly routable >> addresses but this specification does not define when such usage is >> safe and when it is not. Mobile nodes may not be aware of which site >> they are currently making it hard to prevent accidental attachment >> to other sites, resulting in possible unrechability between the MN >> and the HA, when unique-local IPv6 routable addresses are used as >> care-of addresses. CNs outside the MN's own site are unlikely >> to be reachable when unique-local IPv6 routable addresses are used >> as home addresses. If such addresses are used, however, according >> to [RFC4193], they are treated as any other global unicast IPv6 >> address so, for the remainder of this specification, use of >> unique-local IPv6 unicast addresses is not differentiated >> from other globally unique IPv6 addresses. >> >> --------------------------------------------------------------------------- >> >> OLD TEXT: >> ========= >> 10.4.2. Processing Intercepted Packets >> ... >> ... Packets addressed to >> the mobile node's site-local address SHOULD NOT be tunneled to the >> mobile node by default. >> >> NEW TEXT (None: old text removed) >> ========= >> >> --------------------------------------------------------------------------- >> >> OLD TEXT: >> ========= >> 11.3.1. Sending Packets While Away from Home >> ... >> o While not at its home link, the mobile node MUST NOT use the Home >> Address destination option when communicating with link-local or >> site-local peers, if the scope of the home address is larger than >> the scope of the peer's address. >> >> NEW TEXT: >> ========= >> 11.3.1. Sending Packets While Away from Home >> ... >> o While not at its home link, the mobile node MUST NOT use the Home >> Address destination option when communicating with link-local peers. >> >> --------------------------------------------------------------------------- >> >> OLD TEXT: >> ========= >> 11.5.4. Returning Home >> ... >> ...The mobile node MUST multicast such a >> Neighbor Advertisement for each of its home addresses, as defined by >> the current on-link prefixes, including its link-local address and >> site-local address. >> >> NEW TEXT: >> ========= >> 11.5.4. Returning Home >> ... >> ...The mobile node MUST multicast such a >> Neighbor Advertisement for each of its home addresses, as defined by >> the current on-link prefixes, including its link-local address. >> >> --------------------------------------------------------------------------- >> >> I recommend accepting the above changes in rfc3775bis-01, and >> thereby resolving issue #4. >> >> >> Regards, >> Charlie P. >> >> >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Jun 28 04:14:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A7D63A68AB; Sat, 28 Jun 2008 04:14:25 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C4F13A68AB for ; Sat, 28 Jun 2008 04:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idXWm8pTX+lh for ; Sat, 28 Jun 2008 04:14:23 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 4BFB83A68A0 for ; Sat, 28 Jun 2008 04:14:23 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1214651670!27173622!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 1193 invoked from network); 28 Jun 2008 11:14:30 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-4.tower-128.messagelabs.com with SMTP; 28 Jun 2008 11:14:30 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m5SBEMfJ011365; Sat, 28 Jun 2008 04:14:22 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id m5SBEL5L020272; Sat, 28 Jun 2008 06:14:21 -0500 (CDT) Received: from [127.0.0.1] ([10.129.40.74]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id m5SBEJ6v020268; Sat, 28 Jun 2008 06:14:20 -0500 (CDT) Message-ID: <48661D0B.1040900@gmail.com> Date: Sat, 28 Jun 2008 13:14:19 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Charles E. Perkins" References: <486558D6.1070803@earthlink.net> In-Reply-To: <486558D6.1070803@earthlink.net> X-Antivirus: avast! (VPS 080627-0, 27/06/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] Issue #3 -- BRR, BErr are sent by HA too, not only by CN X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Charles E. Perkins wrote: > > Hello folks, > > Further discussion gravitated towards creating two different issues, > one for Binding Error and another for Binding Refresh Request. > > Recommendation: close this issue in favor of focusing comments on new > issues that will be created, according to the more recent discussion > on the mailing list. Charles, hi, thanks for advancing this. I agree with the recommendation to close this issue in favor of focusing comments on new issues that will be created. 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://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Jun 28 04:46:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EB063A6861; Sat, 28 Jun 2008 04:46:00 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B63123A6861 for ; Sat, 28 Jun 2008 04:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNenUgH2Taqp for ; Sat, 28 Jun 2008 04:45:58 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 957BE3A67D4 for ; Sat, 28 Jun 2008 04:45:58 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KCYsR-00011H-B2; Sat, 28 Jun 2008 13:45:59 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: "Charles E. Perkins" References: <486561DA.8090609@earthlink.net> X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080628:tsirtsis@googlemail.com::s14OuiTDUh9SlNbG:000000000000000000000000000000000000000iAb X-Hashcash: 1:20:080628:mext@ietf.org::YjqHp+kx0zDYF7h8:00002IRN X-Hashcash: 1:20:080628:charles.perkins@earthlink.net::HKkR4y0+Oh/k4HbI:000000000000000000000000000000006ceC Date: Sat, 28 Jun 2008 13:45:40 +0200 In-Reply-To: <486561DA.8090609@earthlink.net> (Charles E. Perkins's message of "Fri, 27 Jun 2008 14:55:38 -0700") Message-ID: <87myl5zst7.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] Issue #4 Remove references to site-local addresses [George Tsirtsis ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1676635163==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1676635163== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Hi, "Charles E. Perkins" writes: > I've reviewed the discussion about issue #4, and it seems to me that > a relatively painless compromise is available. Namely, we could simply > delete the "SHOULD NOT" recommendation regarding the use of > ULAs as home or care-of addresses, while maintaining the cautionary > note about potential inaccessibility of correspondent nodes. great. > Here is the resultant text, which is otherwise almost identical to > George's text except for splitting a run-on sentence into two > sentences. > > 3.1. General Terms > > 4.6. Site-Local Addressability > > 10.4.2. Processing Intercepted Packets > > 11.3.1. Sending Packets While Away from Home > > 11.5.4. Returning Home > The changes you propose look fine. Cheers, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIZiRqAlWVfAR6UCYRAjVVAJ999AUVPP8rAnScGvnP2WiirZVWDACdHSJw YRJL0JNlcxQGz+pjGXanETo= =FGcl -----END PGP SIGNATURE----- --=-=-=-- --===============1676635163== 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://www.ietf.org/mailman/listinfo/mext --===============1676635163==-- From mext-bounces@ietf.org Sat Jun 28 04:59:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DD8C3A6A0C; Sat, 28 Jun 2008 04:59:50 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E780D3A69D6 for ; Sat, 28 Jun 2008 04:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRfF9C1zlOUY for ; Sat, 28 Jun 2008 04:59:48 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 120D73A6993 for ; Sat, 28 Jun 2008 04:59:48 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KCZ5p-0000eT-QH; Sat, 28 Jun 2008 13:59:50 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: "Charles E. Perkins" References: <48653AAD.6020909@earthlink.net> X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080628:mext@ietf.org::nFbmdCb2jJWhF92k:00001va0 X-Hashcash: 1:20:080628:charles.perkins@earthlink.net::Ed4KP9x6ytMAWBpm:000000000000000000000000000000007AEz Date: Sat, 28 Jun 2008 13:59:36 +0200 In-Reply-To: <48653AAD.6020909@earthlink.net> (Charles E. Perkins's message of "Fri, 27 Jun 2008 12:08:29 -0700") Message-ID: <87iqvtzs5z.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] Issue #1: Last accepted SQN X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0151808540==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0151808540== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Hi, "Charles E. Perkins" writes: > Hello folks, > > The intention in RFC 3775 was pretty clearly to allow the mobile > node to update its record for the sequence number. An authenticated > Binding Acknowledgement is clearly useful for this purpose. The > discussion up until now was sticking on the need for a new protocol > element, which Ahmad specified as an extension. > > Since I'm in the process of collecting mailing-list inputs and > trying to make recommendations according to the discussion > so far, I thought I'd like to at least suggest a text revision for > rfc3775bis that (a) allows the original intention of RFC 3775 > but (b) does not require a new protocol element. > > ======================================================================== > > OLD TEXT: > > o The Sequence Number field matches the Sequence Number sent by the > mobile node to this destination address in an outstanding Binding > Update. > > ======================================================================== > > NEW TEXT: > > o The Sequence Number field matches the Sequence Number sent by the > mobile node to this destination address in an outstanding Binding > Update, and the Status field is not 135. > > ... and, just before the bulleted text for Status field #1 (currently on > pg. 139): I don't see where, can you give some context (the end of previous sentence, for instance)? > > o Additionally, if the Binding Acknowledgement correctly passes > authentication and the Status field value is 135 (Sequence Number > out of window), then the mobile node MUST update its binding > sequence number appropriately to match the sequence number given > in the Binding Acknowledgement. Otherwise, if the Status field > value is 135 but the the Binding Acknowledgement does not pass ^^^^^^^ small typo > authentication, the message MUST be silently ignored. > > ======================================================================== > > If this is O.K., I plan to use it as a recommendation for resolution > of this issue. Cheers, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIZieoAlWVfAR6UCYRAhNHAJ9/0Ziiw0P38e80EYdPs6Xndr0MrwCfc+Tj 76Dgzc2CzdH8VrSW1auZiMc= =kFXK -----END PGP SIGNATURE----- --=-=-=-- --===============0151808540== 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://www.ietf.org/mailman/listinfo/mext --===============0151808540==-- From mext-bounces@ietf.org Sat Jun 28 05:21:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81DAC3A68A0; Sat, 28 Jun 2008 05:21:29 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 087593A68A0 for ; Sat, 28 Jun 2008 05:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaYFddy2U7ii for ; Sat, 28 Jun 2008 05:21:27 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id C496D3A6888 for ; Sat, 28 Jun 2008 05:21:26 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KCZQm-0000xZ-8k; Sat, 28 Jun 2008 14:21:28 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: "Charles E. Perkins" References: <200803271024.49601.julien.IETF@laposte.net> <48654BFB.5000005@earthlink.net> X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080628:charles.perkins@earthlink.net::N3wfPTY6Sed1NoVa:000000000000000000000000000000001p71 X-Hashcash: 1:20:080628:mext@ietf.org::j6WWpkbc68cjQvyU:00003Cq9 X-Hashcash: 1:20:080628:julien.ietf@laposte.net::3W7qaf3cwg+jW/Rc:000000000000000000000000000000000000003Mgw Date: Sat, 28 Jun 2008 14:21:14 +0200 In-Reply-To: <48654BFB.5000005@earthlink.net> (Charles E. Perkins's message of "Fri, 27 Jun 2008 13:22:19 -0700") Message-ID: <87ej6hzr5x.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Issue #2: Recommendation for closure on on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0699250134==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0699250134== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Hi, "Charles E. Perkins" writes: > After 80,000 messages, discussion about the DHAAD > discovery message suddenly stopped when, it seemed > to me, a resolution was nearly at hand. After reading > through the "harmful" ID that was submitted, I imported > a bit of text for another try at a resolution to be used in > rfc3775bis. Here is the resulting modification to > Julien's previous effort. > > ------------------------------------------------------------------------ > OLD: > > 15.5. Dynamic Home Agent Address Discovery > > The dynamic home agent address discovery function could be used to > learn the addresses of home agents in the home network. > > The ability to learn addresses of nodes may be useful to attackers > because brute-force scanning of the address space is not practical > with IPv6. Thus, they could benefit from any means which make > mapping the networks easier. For example, if a security threat > targeted at routers or even home agents is discovered, having a > simple ICMP mechanism to easily find out possible targets may prove > to be an additional (though minor) security risk. > > Apart from discovering the address(es) of home agents, attackers will > not be able to learn much from this information, and mobile nodes > cannot be tricked into using wrong home agents, as all other > communication with the home agents is secure. > > NEW: > > 15.5. Dynamic Home Agent Address Discovery > > The dynamic home agent address discovery function could be used to > learn the addresses of home agents in the home network. > > The ability to learn addresses of nodes may be useful to attackers > because brute-force scanning of the address space is not practical > with IPv6. Thus, they could benefit from any means which make > mapping the networks easier. For example, if a security threat > targeted at routers or even home agents is discovered, having a > simple ICMP mechanism to easily find out possible targets may prove > to be an additional (though minor) security risk. > > * This document does not define any authentication mechanism for > * dynamic home agent address discovery messages. Therefore the home > * agent cannot verify the home address of the mobile node that > * requested the list of home agents. simple and explicit. good. > Apart from discovering the address(es) of home agents, attackers will > not be able to learn much from this information, and mobile nodes > cannot be tricked into using wrong home agents, as all other > communication with the home agents is secure. > > * In cases where additional security is needed, one may consider > * instead the use of MIPv6 bootstrapping [RFC5026] (based on > * DNS SRV Resource Records [RFC2782]) in conjunction with security > * mechanisms suggested in these specifications. In that solution, > * security is provided by the DNSSEC [RFC4033] framework. The needed > * pre-configured data on the mobile node for this mechanism is the > * domain name of the mobile service provider, which is marginally better > * than the home subnet prefix. For the security, a trust anchor which > * dominates the domain is needed. I don't have an opinion on that block. > * Finally, it should be noted that the specification of ICMP to carry > * DHAAD incurs a certain deployability risk related to the perceived > * insecurity of ICMP messages. Many ISPs are blocking ICMP on all links > * except the first hop, because ICMP is known to be a vehicle for DoS > * attacks and other sorts of threats. IMHO, this should go. Most of the ISP I know do not filter ICMPv6 which do not target their routers and based on tests I performed, they can flow without problem on the IPv6 internet. Can you point an ISP that implement what you describe? Does it specifically filter some type/code? The ability to mount DoS attacks with ICMPv6 messages is very limited, IMHO, compared to TCP SYN packets, UDP packets against specific upper layer protocols and possibly some IPv6 extension headers. Cheers, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIZiy6AlWVfAR6UCYRAsBaAJwN7PkfV16tb94IRPugyeNAG9b79ACfWIaC 2II05e5nTJS0nA2TX+nQZvM= =hwfy -----END PGP SIGNATURE----- --=-=-=-- --===============0699250134== 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://www.ietf.org/mailman/listinfo/mext --===============0699250134==-- From mext-bounces@ietf.org Sat Jun 28 05:25:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BF583A6888; Sat, 28 Jun 2008 05:25:15 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63A3B3A690E for ; Sat, 28 Jun 2008 05:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXD2p1nnm03S for ; Sat, 28 Jun 2008 05:25:13 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 942233A6888 for ; Sat, 28 Jun 2008 05:25:13 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KCZUS-0000xh-EU; Sat, 28 Jun 2008 14:25:16 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: "Charles E. Perkins" References: <48655401.1060905@earthlink.net> X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080628:mext@ietf.org::mVPqRjA4IVF+wd7L:00004Ftm X-Hashcash: 1:20:080628:charles.perkins@earthlink.net::UnQRE+/H/rGb7JYK:000000000000000000000000000000005VoJ Date: Sat, 28 Jun 2008 14:25:03 +0200 In-Reply-To: <48655401.1060905@earthlink.net> (Charles E. Perkins's message of "Fri, 27 Jun 2008 13:56:33 -0700") Message-ID: <8763rtzqzk.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] Issue #5 (Wrong protocol number used in discussion about checksum pseudo-header:) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1573159846==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1573159846== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Hi, "Charles E. Perkins" writes: > I've created issue #5; > see http://www3.tools.ietf.org/wg/mext/trac/ticket/5 > > I recommend accepting the proposed change in rfc3775bis-01. +1 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIZi2fAlWVfAR6UCYRAiP4AJ9PZzzuveUAZ321BzySGJHaDY6bIQCZAa4T Wa+/772U6cf0i4Ri0Ml0+yg= =s3sC -----END PGP SIGNATURE----- --=-=-=-- --===============1573159846== 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://www.ietf.org/mailman/listinfo/mext --===============1573159846==-- From mext-bounces@ietf.org Sat Jun 28 07:29:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7C173A6AA7; Sat, 28 Jun 2008 07:29:44 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF0D28C10E for ; Sat, 28 Jun 2008 07:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQvWG4vP5EyA for ; Sat, 28 Jun 2008 07:29:42 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 05AC528B56A for ; Sat, 28 Jun 2008 07:29:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=q1vTFOtj1m43BclFEl1SGljki/6rkVZK/QL6uG0Hj+8XT9ey0gUUsuVzzRK/ewNZ; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.245.61.96] (helo=[10.0.0.144]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KCbQs-0007rU-M4; Sat, 28 Jun 2008 10:29:43 -0400 Message-ID: <48664ACB.9050805@earthlink.net> Date: Sat, 28 Jun 2008 07:29:31 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Arnaud Ebalard References: <48653AAD.6020909@earthlink.net> <87iqvtzs5z.fsf@natisbad.org> In-Reply-To: <87iqvtzs5z.fsf@natisbad.org> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52cbd56179844bba24f0ca9a4532ab47d3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.245.61.96 Cc: mext@ietf.org Subject: Re: [MEXT] Issue #1: Last accepted SQN X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Arnaud Ebalard wrote: > >> >> ... and, just before the bulleted text for Status field #1 (currently on >> pg. 139): >> > > I don't see where, can you give some context (the end of previous > sentence, for instance)? > From the current draft, here is the precedeing paragraph and the first sentence of the next paragraph: ------------------------------------------------------------------- Mobile nodes SHOULD send a new Binding Update well before the expiration of this period in order to extend the lifetime. This helps to avoid disruptions in communications which might otherwise be caused by network delays or clock drift. o Additionally, if the Status field value is 1 (accepted but prefix ... ------------------------------------------------------------------- Thanks for catching the typo. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 30 02:18:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA3A3A68D2; Mon, 30 Jun 2008 02:18:16 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA8393A6A06 for ; Mon, 30 Jun 2008 02:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4MLCbjnaMGP for ; Mon, 30 Jun 2008 02:18:14 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id ECBA23A67FB for ; Mon, 30 Jun 2008 02:18:10 -0700 (PDT) Received: from localhost ([127.0.0.1]:48032 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KDFWc-0000vl-Gy; Mon, 30 Jun 2008 11:18:18 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: julien.ietf@laposte.net X-Trac-Project: mext Date: Mon, 30 Jun 2008 09:18:18 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/1#comment:2 Message-ID: <074.e47383fef54e1ff2363d14623fe84429@tools.ietf.org> References: <065.2ae99a08058bb69e889aa8f753aa0831@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <065.2ae99a08058bb69e889aa8f753aa0831@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: julien.ietf@laposte.net, mext@ietf.org, marcelo@it.uc3m.es, amuhanna@nortel.com X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #1: Last Accepted SQN [Ahmad Muhanna ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ticket #1: Last Accepted SQN [Ahmad Muhanna ] >From julien.ietf@laposte.net): * cc: mext@ietf.org, julien.ietf@laposte.net, marcelo@it.uc3m.es, amuhanna@nortel.com (removed) * owner: julien.ietf@laposte.net => charliep@computer.org * component: RFC3775 changes => draft-ietf-mext-rfc3775bis ----------------------------------------+----------------------------------- Reporter: julien.ietf@laposte.net | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: | Resolution: Keywords: | ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 30 02:19:19 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BFE328C100; Mon, 30 Jun 2008 02:19:19 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F01B028C100 for ; Mon, 30 Jun 2008 02:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWAMW6tKS1Sr for ; Mon, 30 Jun 2008 02:19:17 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 16C373A6AAB for ; Mon, 30 Jun 2008 02:19:17 -0700 (PDT) Received: from localhost ([127.0.0.1]:44078 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KDFXh-0002yt-JK; Mon, 30 Jun 2008 11:19:25 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: julien.ietf@laposte.net X-Trac-Project: mext Date: Mon, 30 Jun 2008 09:19:25 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/2#comment:3 Message-ID: <074.b034e53b1985cc1842700524f6c49cd1@tools.ietf.org> References: <065.744112d66f824a6edb74d88125950f36@tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <065.744112d66f824a6edb74d88125950f36@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: julien.ietf@laposte.net, mext@ietf.org, marcelo@it.uc3m.es, jeanmichel.combes@gmail.com X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #2: Removing DHAAD mechanism [Jean-Michel Combes ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ticket #2: Removing DHAAD mechanism [Jean-Michel Combes ] >From julien.ietf@laposte.net): * owner: julien.ietf@laposte.net => charliep@computer.org * component: RFC3775 changes => draft-ietf-mext-rfc3775bis ----------------------------------------+----------------------------------- Reporter: julien.ietf@laposte.net | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: | Resolution: Keywords: | ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 30 02:20:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 574D528C144; Mon, 30 Jun 2008 02:20:18 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BB9228C144 for ; Mon, 30 Jun 2008 02:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjePdg9spNRz for ; Mon, 30 Jun 2008 02:20:16 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id A251E28C136 for ; Mon, 30 Jun 2008 02:20:15 -0700 (PDT) Received: from localhost ([127.0.0.1]:44094 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KDFYc-0005JB-Jv; Mon, 30 Jun 2008 11:20:23 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: julien.ietf@laposte.net X-Trac-Project: mext Date: Mon, 30 Jun 2008 09:20:22 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/3#comment:2 Message-ID: <074.38ca38d2dfb93099f7445b1c9aca5b1f@tools.ietf.org> References: <065.3dcc374ac20c8e176e52b82612be2b65@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <065.3dcc374ac20c8e176e52b82612be2b65@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: julien.ietf@laposte.net, mext@ietf.org, marcelo@it.uc3m.es, alexandru.petrescu@gmail.com X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #3: BRR, BErr are sent by HA too, not only by CN [Alexandru Petrescu ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ticket #3: BRR, BErr are sent by HA too, not only by CN [Alexandru Petrescu ] >From julien.ietf@laposte.net): * owner: julien.ietf@laposte.net => charliep@computer.org * component: RFC3775 changes => draft-ietf-mext-rfc3775bis ----------------------------------------+----------------------------------- Reporter: julien.ietf@laposte.net | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: | Resolution: Keywords: | ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 30 02:20:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE03728C127; Mon, 30 Jun 2008 02:20:48 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE35328C15C for ; Mon, 30 Jun 2008 02:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tL+1nuspMTlA for ; Mon, 30 Jun 2008 02:20:46 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id C063328C156 for ; Mon, 30 Jun 2008 02:20:46 -0700 (PDT) Received: from localhost ([127.0.0.1]:44112 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KDFZ7-0006iy-Pj; Mon, 30 Jun 2008 11:20:54 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: julien.ietf@laposte.net X-Trac-Project: mext Date: Mon, 30 Jun 2008 09:20:53 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/4#comment:1 Message-ID: <074.b55edbd66acf693bc1e369ad89d41194@tools.ietf.org> References: <065.1f7010cc7fe6a13ec11344bf7562afde@tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <065.1f7010cc7fe6a13ec11344bf7562afde@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: julien.ietf@laposte.net, mext@ietf.org, marcelo@it.uc3m.es, tsirtsis@googlemail.com X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #4: Remove references to site-local addresses [George Tsirtsis ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ticket #4: Remove references to site-local addresses [George Tsirtsis ] >From julien.ietf@laposte.net): * owner: julien.ietf@laposte.net => charliep@computer.org * component: RFC3775 changes => draft-ietf-mext-rfc3775bis ----------------------------------------+----------------------------------- Reporter: julien.ietf@laposte.net | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: | Resolution: Keywords: | ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 30 02:23:32 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC823A6907; Mon, 30 Jun 2008 02:23:32 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC77528C100 for ; Mon, 30 Jun 2008 02:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drJdjtVwIfAM for ; Mon, 30 Jun 2008 02:23:30 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 441AB28C195 for ; Mon, 30 Jun 2008 02:21:23 -0700 (PDT) Received: from localhost ([127.0.0.1]:44127 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KDFZk-000885-0z; Mon, 30 Jun 2008 11:21:32 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: julien.ietf@laposte.net X-Trac-Project: mext Date: Mon, 30 Jun 2008 09:21:32 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/1#comment:3 Message-ID: <074.37f014630bef95e519a397b765376fb7@tools.ietf.org> References: <065.2ae99a08058bb69e889aa8f753aa0831@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <065.2ae99a08058bb69e889aa8f753aa0831@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: julien.ietf@laposte.net, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #1: Last Accepted SQN [Ahmad Muhanna ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ticket #1: Last Accepted SQN [Ahmad Muhanna ] >From julien.ietf@laposte.net): * cc: mext@ietf.org (added) ----------------------------------------+----------------------------------- Reporter: julien.ietf@laposte.net | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: | Resolution: Keywords: | ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 30 10:01:08 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEE533A677D; Mon, 30 Jun 2008 10:01:07 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E61253A67E9 for ; Mon, 30 Jun 2008 10:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvEQkE2dCO-Y for ; Mon, 30 Jun 2008 10:01:05 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 4DA3A3A63EC for ; Mon, 30 Jun 2008 10:01:05 -0700 (PDT) Received: from localhost ([127.0.0.1]:51386 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KDMka-0003rD-AZ; Mon, 30 Jun 2008 19:01:12 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Mon, 30 Jun 2008 17:01:11 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/7 Message-ID: <063.eee1db399c39efaaf5a50a65984c5bdf@tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, tero.kauppinen@ericsson.com, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: tero.kauppinen@ericsson.com, mext@ietf.org Subject: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ticket #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen ] DSMIPv6 BU format and RFC 3775 Tero Kauppinen While reading the current version of DSMIPv6 (draft-ietf-mip6-nemo-v4traversal-06) and I came across with one sentence which strikes me as odd. "4.2. NAT detection and traversal NAT detection is done when the initial binding update message is sent from the mobile node to the home agent. When located in an IPv4-only foreign link, the mobile node sends the binding update message encapsulated in UDP and IPv4. The source address of the IPv6 packet is the mobile node's IPv6 home address. The destination address is the IPv6 address of the home agent. The IPv4 header contains the IPv4 care-of address in the source address field and the IPv4 address of the home agent in the destination address field. When the home agent receives the encapsulated binding update it compares the IPv4 address of the source address field in the IPv4 header with the IPv4 address in the source address of the IPv6 header." If the IPv6 header contains the mobile node's IPv6 home address, how can it ever match with the IPv4 address of the source address field in the IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the Lifetime specified in the Binding Update is zero or the specified care-of address matches the home address for the binding, then this is a request to delete the cached binding for the home address." So, (1) Should the IPv6 header actually contain an IPv4 mapped IPv6 address? Or (2) Should the IPv4 address of the source address field in the IPv4 header be compared with the address specified in the packet's IPv4 CoA option? --------------------------------------------------------------------- George Tsirtsis I would go with (2), as I think this was the intention (i.e., I consider this a typo). It is not, however, clear to me what the relevance of the quoted text from 3775 is. Whether (1) or (2) is used it should not result in the condition of CoA==HoA in the BU. --------------------------------------------------------------------- Pascal Thubert I favor 1) and the text seems to be a leftover from your original draft which worked that way. But I remember that the question was cut against it by the chairs because there was no proper consensus either way. Now I really hate the idea of a BU process that would have to figure if a BU is a registration or deregistration just because the packet was received over an interface that is an IPv4 tunnel as opposed to the Home Link. That seems plain wrong. I have a tendency to think that what's wrong is really RFC 3775 (lifetime 0 should be the way to deregister) but unless we revise it, I'd suggest we keep consistent with that foundation RFC. If we REALLY do not want a mapped address as source, then maybe we could use the UNSPECIFIED address instead? --------------------------------------------------------------------- Vijay Devarapalli : > "4.2. NAT detection and traversal > > NAT detection is done when the initial binding update message is sent > from the mobile node to the home agent. When located in an IPv4-only > foreign link, the mobile node sends the binding update message > encapsulated in UDP and IPv4. The source address of the IPv6 packet > is the mobile node's IPv6 home address. The destination address is > the IPv6 address of the home agent. The IPv4 header contains the IPv4 > care-of address in the source address field and the IPv4 address of > the home agent in the destination address field. > > When the home agent receives the encapsulated binding update it > compares the IPv4 address of the source address field in the IPv4 > header with the IPv4 address in the source address of the IPv6 > header." This text is old. The home agent needs to compare it with the IPv4 address in the IPv4 CoA option. So this paragraph should actually say When the home agent receives the encapsulated binding update it compares the IPv4 address of the source address field in the IPv4 header with the IPv4 address in the IPv4 care-of address option in the Binding Update. > If the IPv6 header contains the mobile node's IPv6 home address, how can > it ever match with the IPv4 address of the source address field in the > IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the Lifetime > specified in the Binding Update is zero or the specified care-of address > matches the home address for the binding, then this is a request to > delete the cached binding for the home address." This text needs to be clarified in RFC 3775. Regarding the actual "violation", I don't think there is a conflict. The DS-MIPv6 binding update has an IPv4 CoA option (similar to the alt CoA option) which when present dictates a different behavior on the home agent that implements DS-MIPv6 extensions. It is more like DS-MIPv6 updates MIPv6 home agent behavior when the IPv4 CoA option is present. --------------------------------------------------------------------- Basavaraj Patil Option 2 is what I believe the intent has been. Option 2 IMO is a better choice even though it does diverge from RFC3775 design. But given that this I-D is extending the base MIP6 RFC, I believe it is okay to proceed with option 2. --------------------------------------------------------------------- Hesham Soliman => The relevance of the quote from 3775 is that we're putting the HoA in the src address of a normal registration. The text says that the receiver of a BU with the HoA in the src address field would assume it's a de-registration, which is obviously not what we want. Hence my question about violating 3775. -----------------------------------+---------------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: enhancement | Status: new Priority: minor | Milestone: Component: RFC3775 changes | Version: Severity: Active WG Document | Keywords: -----------------------------------+---------------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 30 10:04:38 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7BE33A69AB; Mon, 30 Jun 2008 10:04:38 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9D33A6A10 for ; Mon, 30 Jun 2008 10:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlIvvHb4A9ha for ; Mon, 30 Jun 2008 10:04:37 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id E0C1E3A6928 for ; Mon, 30 Jun 2008 10:04:36 -0700 (PDT) Received: from [75.26.137.116] (helo=[10.166.255.89]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KDMo2-0005zt-8G; Mon, 30 Jun 2008 13:04:46 -0400 Message-ID: <4869122D.5090701@computer.org> Date: Mon, 30 Jun 2008 10:04:45 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mext@ietf.org References: <063.eee1db399c39efaaf5a50a65984c5bdf@tools.ietf.org> In-Reply-To: <063.eee1db399c39efaaf5a50a65984c5bdf@tools.ietf.org> X-ELNK-Trace: 5a185a306015b1a28a306fc704168558239a348a220c26095ab8e7a730e2fe08d25bc5773798d2a5a7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: tero.kauppinen@ericsson.com Subject: Re: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, So far, I did not find a persuasive reason to make changes to RFC 3775 related to this issue with DSMIPv6. Unless someone can suggest text that might be needed, I would recommend to close this issue without modification to rfc3775bis. Regards, Charlie P. mext wrote: > Ticket #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen > ] > > DSMIPv6 BU format and RFC 3775 > Tero Kauppinen > > While reading the current version of DSMIPv6 > (draft-ietf-mip6-nemo-v4traversal-06) and I came across with one > sentence which strikes me as odd. > > "4.2. NAT detection and traversal > > NAT detection is done when the initial binding update message is sent > from the mobile node to the home agent. When located in an IPv4-only > foreign link, the mobile node sends the binding update message > encapsulated in UDP and IPv4. The source address of the IPv6 packet > is the mobile node's IPv6 home address. The destination address is > the IPv6 address of the home agent. The IPv4 header contains the IPv4 > care-of address in the source address field and the IPv4 address of > the home agent in the destination address field. > > When the home agent receives the encapsulated binding update it > compares the IPv4 address of the source address field in the IPv4 > header with the IPv4 address in the source address of the IPv6 > header." > > If the IPv6 header contains the mobile node's IPv6 home address, how can > it ever match with the IPv4 address of the source address field in the > IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the Lifetime > specified in the Binding Update is zero or the specified care-of address > matches the home address for the binding, then this is a request to > delete the cached binding for the home address." > > So, > > (1) Should the IPv6 header actually contain an IPv4 mapped IPv6 address? > > Or > > (2) Should the IPv4 address of the source address field in the IPv4 > header be compared with the address specified in the packet's IPv4 CoA > option? > > --------------------------------------------------------------------- > > George Tsirtsis > > I would go with (2), as I think this was the intention (i.e., I > consider this a typo). > > It is not, however, clear to me what the relevance of the quoted text > from 3775 is. > Whether (1) or (2) is used it should not result in the condition of > CoA==HoA in the BU. > > --------------------------------------------------------------------- > > Pascal Thubert > > I favor 1) and the text seems to be a leftover from your original draft > which worked that way. > But I remember that the question was cut against it by the chairs > because there was no proper consensus either way. > > Now I really hate the idea of a BU process that would have to figure if > a BU is a registration or deregistration just because the packet was > received over an interface that is an IPv4 tunnel as opposed to the Home > Link. That seems plain wrong. I have a tendency to think that what's > wrong is really RFC 3775 (lifetime 0 should be the way to deregister) > but unless we revise it, I'd suggest we keep consistent with that > foundation RFC. If we REALLY do not want a mapped address as source, > then maybe we could use the UNSPECIFIED address instead? > > --------------------------------------------------------------------- > > Vijay Devarapalli : > > > "4.2. NAT detection and traversal > > > > NAT detection is done when the initial binding update message is sent > > from the mobile node to the home agent. When located in an IPv4-only > > foreign link, the mobile node sends the binding update message > > encapsulated in UDP and IPv4. The source address of the IPv6 packet > > is the mobile node's IPv6 home address. The destination address is > > the IPv6 address of the home agent. The IPv4 header contains the IPv4 > > care-of address in the source address field and the IPv4 address of > > the home agent in the destination address field. > > > > When the home agent receives the encapsulated binding update it > > compares the IPv4 address of the source address field in the IPv4 > > header with the IPv4 address in the source address of the IPv6 > > header." > > This text is old. The home agent needs to compare it with the IPv4 > address in the IPv4 CoA option. So this paragraph should actually > say > > When the home agent receives the encapsulated binding update it > compares the IPv4 address of the source address field in the IPv4 > header with the IPv4 address in the IPv4 care-of address option > in the Binding Update. > > > If the IPv6 header contains the mobile node's IPv6 home address, how can > > it ever match with the IPv4 address of the source address field in the > > IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the Lifetime > > specified in the Binding Update is zero or the specified care-of address > > matches the home address for the binding, then this is a request to > > delete the cached binding for the home address." > > This text needs to be clarified in RFC 3775. Regarding the actual > "violation", I don't think there is a conflict. The DS-MIPv6 > binding update has an IPv4 CoA option (similar to the alt CoA > option) which when present dictates a different behavior on the > home agent that implements DS-MIPv6 extensions. It is more like > DS-MIPv6 updates MIPv6 home agent behavior when the IPv4 CoA > option is present. > > > --------------------------------------------------------------------- > > Basavaraj Patil > > Option 2 is what I believe the intent has been. Option 2 IMO is a better > choice even though it does diverge from RFC3775 design. But given that > this > I-D is extending the base MIP6 RFC, I believe it is okay to proceed with > option 2. > > > --------------------------------------------------------------------- > > Hesham Soliman > > => The relevance of the quote from 3775 is that we're putting the HoA in > the > src address of a normal registration. The text says that the receiver of a > BU with the HoA in the src address field would assume it's a > de-registration, which is obviously not what we want. Hence my question > about violating 3775. > > > -----------------------------------+---------------------------------------- > Reporter: charliep@computer.org | Owner: charliep@computer.org > Type: enhancement | Status: new > Priority: minor | Milestone: > Component: RFC3775 changes | Version: > Severity: Active WG Document | Keywords: > -----------------------------------+---------------------------------------- _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 30 16:17:13 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 740B83A7FF6; Mon, 30 Jun 2008 16:17:13 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5FD03A8185 for ; Mon, 30 Jun 2008 16:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O164RTqVsUdF for ; Mon, 30 Jun 2008 16:17:10 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 624F83A6B3A for ; Mon, 30 Jun 2008 16:17:10 -0700 (PDT) Received: from [127.0.0.1] ([75.26.137.116]) by outbound.mse15.exchange.ms with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Jun 2008 19:17:17 -0400 Message-ID: <48696974.2030503@wichorus.com> Date: Mon, 30 Jun 2008 16:17:08 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: charliep@computer.org References: <063.eee1db399c39efaaf5a50a65984c5bdf@tools.ietf.org> <4869122D.5090701@computer.org> In-Reply-To: <4869122D.5090701@computer.org> X-OriginalArrivalTime: 30 Jun 2008 23:17:17.0754 (UTC) FILETIME=[706D89A0:01C8DB07] Cc: tero.kauppinen@ericsson.com, mext@ietf.org Subject: Re: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Charlie, I think the text in RFC 3775 needs to be fixed. RFC 3775 assumes that a binding update is sent with the home address option and with the care-of address stored either in the source address in the IPv6 header or in alternate care-of address option. So it specifies that if the care-of address matches the home address in the home address option, it is safe for the home agent to assume that the binding update was sent from the home link and can be treated as a de-registration BU. In practice, I have never seen a Binding Update, where the lifetime is non-zero and the care-of address matches the home address, from a mobile node implementation. Only the TAHI test suite sends such a binding update, since they have to test conformance to RFC 3775. :) If the mobile node detects that its care-of address matches the home address, it knows it has returned home and sets the lifetime to zero in the binding update it sends to the home agent. I would suggest removing it and treat only the binding update with lifetime set to zero as a de-registration. It would help in simplifying the de-registration procedure a little bit. Vijay Charles E. Perkins wrote: > > Hello folks, > > So far, I did not find a persuasive reason to make > changes to RFC 3775 related to this issue with > DSMIPv6. Unless someone can suggest text that might > be needed, I would recommend to close this issue > without modification to rfc3775bis. > > Regards, > Charlie P. > > > > mext wrote: >> Ticket #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen >> ] >> >> DSMIPv6 BU format and RFC 3775 >> Tero Kauppinen >> >> While reading the current version of DSMIPv6 >> (draft-ietf-mip6-nemo-v4traversal-06) and I came across with one >> sentence which strikes me as odd. >> >> "4.2. NAT detection and traversal >> >> NAT detection is done when the initial binding update message is sent >> from the mobile node to the home agent. When located in an IPv4-only >> foreign link, the mobile node sends the binding update message >> encapsulated in UDP and IPv4. The source address of the IPv6 packet >> is the mobile node's IPv6 home address. The destination address is >> the IPv6 address of the home agent. The IPv4 header contains the IPv4 >> care-of address in the source address field and the IPv4 address of >> the home agent in the destination address field. >> >> When the home agent receives the encapsulated binding update it >> compares the IPv4 address of the source address field in the IPv4 >> header with the IPv4 address in the source address of the IPv6 >> header." >> >> If the IPv6 header contains the mobile node's IPv6 home address, how can >> it ever match with the IPv4 address of the source address field in the >> IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the Lifetime >> specified in the Binding Update is zero or the specified care-of address >> matches the home address for the binding, then this is a request to >> delete the cached binding for the home address." >> >> So, >> >> (1) Should the IPv6 header actually contain an IPv4 mapped IPv6 address? >> >> Or >> >> (2) Should the IPv4 address of the source address field in the IPv4 >> header be compared with the address specified in the packet's IPv4 CoA >> option? >> >> --------------------------------------------------------------------- >> >> George Tsirtsis >> >> I would go with (2), as I think this was the intention (i.e., I >> consider this a typo). >> >> It is not, however, clear to me what the relevance of the quoted text >> from 3775 is. >> Whether (1) or (2) is used it should not result in the condition of >> CoA==HoA in the BU. >> >> --------------------------------------------------------------------- >> >> Pascal Thubert >> >> I favor 1) and the text seems to be a leftover from your original draft >> which worked that way. >> But I remember that the question was cut against it by the chairs >> because there was no proper consensus either way. >> >> Now I really hate the idea of a BU process that would have to figure if >> a BU is a registration or deregistration just because the packet was >> received over an interface that is an IPv4 tunnel as opposed to the Home >> Link. That seems plain wrong. I have a tendency to think that what's >> wrong is really RFC 3775 (lifetime 0 should be the way to deregister) >> but unless we revise it, I'd suggest we keep consistent with that >> foundation RFC. If we REALLY do not want a mapped address as source, >> then maybe we could use the UNSPECIFIED address instead? >> >> --------------------------------------------------------------------- >> >> Vijay Devarapalli : >> >> > "4.2. NAT detection and traversal >> > >> > NAT detection is done when the initial binding update message is >> sent >> > from the mobile node to the home agent. When located in an >> IPv4-only >> > foreign link, the mobile node sends the binding update message >> > encapsulated in UDP and IPv4. The source address of the IPv6 packet >> > is the mobile node's IPv6 home address. The destination address is >> > the IPv6 address of the home agent. The IPv4 header contains the >> IPv4 >> > care-of address in the source address field and the IPv4 address of >> > the home agent in the destination address field. >> > >> > When the home agent receives the encapsulated binding update it >> > compares the IPv4 address of the source address field in the IPv4 >> > header with the IPv4 address in the source address of the IPv6 >> > header." >> >> This text is old. The home agent needs to compare it with the IPv4 >> address in the IPv4 CoA option. So this paragraph should actually >> say >> >> When the home agent receives the encapsulated binding update it >> compares the IPv4 address of the source address field in the IPv4 >> header with the IPv4 address in the IPv4 care-of address option >> in the Binding Update. >> >> > If the IPv6 header contains the mobile node's IPv6 home address, >> how can >> > it ever match with the IPv4 address of the source address field in the >> > IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the Lifetime >> > specified in the Binding Update is zero or the specified care-of >> address >> > matches the home address for the binding, then this is a request to >> > delete the cached binding for the home address." >> >> This text needs to be clarified in RFC 3775. Regarding the actual >> "violation", I don't think there is a conflict. The DS-MIPv6 >> binding update has an IPv4 CoA option (similar to the alt CoA >> option) which when present dictates a different behavior on the >> home agent that implements DS-MIPv6 extensions. It is more like >> DS-MIPv6 updates MIPv6 home agent behavior when the IPv4 CoA >> option is present. >> >> >> --------------------------------------------------------------------- >> >> Basavaraj Patil >> >> Option 2 is what I believe the intent has been. Option 2 IMO is a better >> choice even though it does diverge from RFC3775 design. But given that >> this >> I-D is extending the base MIP6 RFC, I believe it is okay to proceed with >> option 2. >> >> >> --------------------------------------------------------------------- >> >> Hesham Soliman >> >> => The relevance of the quote from 3775 is that we're putting the HoA in >> the >> src address of a normal registration. The text says that the receiver >> of a >> BU with the HoA in the src address field would assume it's a >> de-registration, which is obviously not what we want. Hence my question >> about violating 3775. >> >> >> -----------------------------------+---------------------------------------- >> >> Reporter: charliep@computer.org | Owner: charliep@computer.org >> Type: enhancement | Status: >> new Priority: minor | >> Milestone: Component: RFC3775 changes >> | Version: Severity: Active WG >> Document | Keywords: >> -----------------------------------+---------------------------------------- >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 30 16:36:06 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85C9C3A67F2; Mon, 30 Jun 2008 16:36:06 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C345F3A67F2 for ; Mon, 30 Jun 2008 16:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRJ9vSdZV5aD for ; Mon, 30 Jun 2008 16:36:04 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 448463A677D for ; Mon, 30 Jun 2008 16:36:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,729,1204531200"; d="scan'208";a="120646979" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 30 Jun 2008 16:36:15 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5UNaFdv012496; Mon, 30 Jun 2008 16:36:15 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m5UNaFF2002529; Mon, 30 Jun 2008 23:36:15 GMT Date: Mon, 30 Jun 2008 16:36:15 -0700 (PDT) From: Sri Gundavelli To: Vijay Devarapalli In-Reply-To: <48696974.2030503@wichorus.com> Message-ID: References: <063.eee1db399c39efaaf5a50a65984c5bdf@tools.ietf.org> <4869122D.5090701@computer.org> <48696974.2030503@wichorus.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10105; t=1214868975; x=1215732975; 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]=20[mext]=20#7=3A=20DSMIPv6=20BU= 20format=20and=20RFC=203775=20[Tero=20Kauppinen=0A=20] |Sender:=20; bh=fxfytAr7XZrgbB9V4W1Ts9Aak8kCYw55OXrauMZM0us=; b=Ru5F8wARo79v/0VTfCKa35Vidnv+WC6K1yDiTmiSK52OpfAWfh5nLGh7RD q3wbKVvfoWVOYaOxTm+4F5Cc/w+pI68sDWmiU/ZyhgifoVaVDq1TwOvdnV0R o89zHPS9Qm; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: charliep@computer.org, mext@ietf.org, tero.kauppinen@ericsson.com Subject: Re: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I agree with the view that a clear indicator such as life=0 should be treated as a dereg message and surely simplifies the dereg procedure. However, if the mobile is able to send a dereg message using, source address of the bu == hoA and if that messag is properly protected using IPsec, it implies the mobile is already defending that address, the HA can only release the binding as it cant defend the address. Is this not an inconsistent state, both HA and MN defending that address ? May be the best thing for the HA is log the error and release the binding. Sri On Mon, 30 Jun 2008, Vijay Devarapalli wrote: > Hi Charlie, > > I think the text in RFC 3775 needs to be fixed. RFC 3775 assumes that a > binding update is sent with the home address option and with the care-of > address stored either in the source address in the IPv6 header or in > alternate care-of address option. So it specifies that if the care-of address > matches the home address in the home address option, it is safe for the home > agent to assume that the binding update was sent from the home link and can > be treated as a de-registration BU. > > In practice, I have never seen a Binding Update, where the lifetime is > non-zero and the care-of address matches the home address, from a mobile node > implementation. Only the TAHI test suite sends such a binding update, since > they have to test conformance to RFC 3775. :) If the mobile node detects that > its care-of address matches the home address, it knows it has returned home > and sets the lifetime to zero in the binding update it sends to the home > agent. > > I would suggest removing it and treat only the binding update with lifetime > set to zero as a de-registration. It would help in simplifying the > de-registration procedure a little bit. > > Vijay > > > Charles E. Perkins wrote: >> >> Hello folks, >> >> So far, I did not find a persuasive reason to make >> changes to RFC 3775 related to this issue with >> DSMIPv6. Unless someone can suggest text that might >> be needed, I would recommend to close this issue >> without modification to rfc3775bis. >> >> Regards, >> Charlie P. >> >> >> >> mext wrote: >> > Ticket #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen >> > ] >> > >> > DSMIPv6 BU format and RFC 3775 >> > Tero Kauppinen >> > >> > While reading the current version of DSMIPv6 >> > (draft-ietf-mip6-nemo-v4traversal-06) and I came across with one >> > sentence which strikes me as odd. >> > >> > "4.2. NAT detection and traversal >> > >> > NAT detection is done when the initial binding update message is >> > sent >> > from the mobile node to the home agent. When located in an IPv4-only >> > foreign link, the mobile node sends the binding update message >> > encapsulated in UDP and IPv4. The source address of the IPv6 packet >> > is the mobile node's IPv6 home address. The destination address is >> > the IPv6 address of the home agent. The IPv4 header contains the >> > IPv4 >> > care-of address in the source address field and the IPv4 address of >> > the home agent in the destination address field. >> > >> > When the home agent receives the encapsulated binding update it >> > compares the IPv4 address of the source address field in the IPv4 >> > header with the IPv4 address in the source address of the IPv6 >> > header." >> > >> > If the IPv6 header contains the mobile node's IPv6 home address, how >> > can >> > it ever match with the IPv4 address of the source address field in the >> > IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the Lifetime >> > specified in the Binding Update is zero or the specified care-of >> > address >> > matches the home address for the binding, then this is a request to >> > delete the cached binding for the home address." >> > >> > So, >> > >> > (1) Should the IPv6 header actually contain an IPv4 mapped IPv6 >> > address? >> > >> > Or >> > >> > (2) Should the IPv4 address of the source address field in the IPv4 >> > header be compared with the address specified in the packet's IPv4 CoA >> > option? >> > >> > --------------------------------------------------------------------- >> > >> > George Tsirtsis >> > >> > I would go with (2), as I think this was the intention (i.e., I >> > consider this a typo). >> > >> > It is not, however, clear to me what the relevance of the quoted text >> > from 3775 is. >> > Whether (1) or (2) is used it should not result in the condition of >> > CoA==HoA in the BU. >> > >> > --------------------------------------------------------------------- >> > >> > Pascal Thubert >> > >> > I favor 1) and the text seems to be a leftover from your original draft >> > which worked that way. >> > But I remember that the question was cut against it by the chairs >> > because there was no proper consensus either way. >> > >> > Now I really hate the idea of a BU process that would have to figure if >> > a BU is a registration or deregistration just because the packet was >> > received over an interface that is an IPv4 tunnel as opposed to the >> > Home >> > Link. That seems plain wrong. I have a tendency to think that what's >> > wrong is really RFC 3775 (lifetime 0 should be the way to deregister) >> > but unless we revise it, I'd suggest we keep consistent with that >> > foundation RFC. If we REALLY do not want a mapped address as source, >> > then maybe we could use the UNSPECIFIED address instead? >> > >> > --------------------------------------------------------------------- >> > >> > Vijay Devarapalli : >> > >> > > "4.2. NAT detection and traversal >> > > >> > > NAT detection is done when the initial binding update message is >> > sent >> > > from the mobile node to the home agent. When located in an >> > IPv4-only >> > > foreign link, the mobile node sends the binding update message >> > > encapsulated in UDP and IPv4. The source address of the IPv6 packet >> > > is the mobile node's IPv6 home address. The destination address is >> > > the IPv6 address of the home agent. The IPv4 header contains the >> > IPv4 >> > > care-of address in the source address field and the IPv4 address of >> > > the home agent in the destination address field. >> > > >> > > When the home agent receives the encapsulated binding update it >> > > compares the IPv4 address of the source address field in the IPv4 >> > > header with the IPv4 address in the source address of the IPv6 >> > > header." >> > >> > This text is old. The home agent needs to compare it with the IPv4 >> > address in the IPv4 CoA option. So this paragraph should actually >> > say >> > >> > When the home agent receives the encapsulated binding update it >> > compares the IPv4 address of the source address field in the IPv4 >> > header with the IPv4 address in the IPv4 care-of address option >> > in the Binding Update. >> > >> > > If the IPv6 header contains the mobile node's IPv6 home address, >> > how can >> > > it ever match with the IPv4 address of the source address field in the >> > > IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the Lifetime >> > > specified in the Binding Update is zero or the specified care-of >> > address >> > > matches the home address for the binding, then this is a request to >> > > delete the cached binding for the home address." >> > >> > This text needs to be clarified in RFC 3775. Regarding the actual >> > "violation", I don't think there is a conflict. The DS-MIPv6 >> > binding update has an IPv4 CoA option (similar to the alt CoA >> > option) which when present dictates a different behavior on the >> > home agent that implements DS-MIPv6 extensions. It is more like >> > DS-MIPv6 updates MIPv6 home agent behavior when the IPv4 CoA >> > option is present. >> > >> > >> > --------------------------------------------------------------------- >> > >> > Basavaraj Patil >> > >> > Option 2 is what I believe the intent has been. Option 2 IMO is a >> > better >> > choice even though it does diverge from RFC3775 design. But given that >> > this >> > I-D is extending the base MIP6 RFC, I believe it is okay to proceed >> > with >> > option 2. >> > >> > >> > --------------------------------------------------------------------- >> > >> > Hesham Soliman >> > >> > => The relevance of the quote from 3775 is that we're putting the HoA >> > in >> > the >> > src address of a normal registration. The text says that the receiver >> > of a >> > BU with the HoA in the src address field would assume it's a >> > de-registration, which is obviously not what we want. Hence my question >> > about violating 3775. >> > >> > >> > -----------------------------------+---------------------------------------- >> > >> > Reporter: charliep@computer.org | Owner: charliep@computer.org >> > Type: enhancement | Status: new >> > Priority: minor | Milestone: >> > Component: RFC3775 changes >> > | Version: Severity: Active WG >> > Document | Keywords: >> > -----------------------------------+---------------------------------------- >> > >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 30 17:21:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39ED03A6951; Mon, 30 Jun 2008 17:21:50 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C0A93A6951 for ; Mon, 30 Jun 2008 17:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5QiiwiH9Pcz for ; Mon, 30 Jun 2008 17:21:47 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id B6E703A681F for ; Mon, 30 Jun 2008 17:21:46 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Jun 2008 20:21:54 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen ] Thread-Index: AcjbChe/sGvJxlr9SAi8/S15JzVU+QABcWQg References: <063.eee1db399c39efaaf5a50a65984c5bdf@tools.ietf.org> <4869122D.5090701@computer.org> <48696974.2030503@wichorus.com> From: "Vijay Devarapalli" To: "Sri Gundavelli" Cc: charliep@computer.org, mext@ietf.org, tero.kauppinen@ericsson.com Subject: Re: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > However, if the mobile is able to send a dereg message > using, source address of the bu == hoA and if that messag is properly > protected using IPsec, it implies the mobile is already defending > that address, The mobile node can't claim its home address until the HA stops proxy neighbor discovery for the home address. RFC 3775 is quite explicit about this. In particular, the mobile node is unable to use its home address as the Source Address in the Neighbor Solicitation until the home agent stops defending the home address. Vijay the HA can only release the binding as it cant > defend the address. Is this not an inconsistent state, both HA and > MN defending that address ? May be the best thing for the HA is > log the error and release the binding. > > Sri > > > On Mon, 30 Jun 2008, Vijay Devarapalli wrote: > > > Hi Charlie, > > > > I think the text in RFC 3775 needs to be fixed. RFC 3775 assumes that a > > binding update is sent with the home address option and with the care-of > > address stored either in the source address in the IPv6 header or in > > alternate care-of address option. So it specifies that if the care-of > address > > matches the home address in the home address option, it is safe for the > home > > agent to assume that the binding update was sent from the home link and > can > > be treated as a de-registration BU. > > > > In practice, I have never seen a Binding Update, where the lifetime is > > non-zero and the care-of address matches the home address, from a mobile > node > > implementation. Only the TAHI test suite sends such a binding update, > since > > they have to test conformance to RFC 3775. :) If the mobile node detects > that > > its care-of address matches the home address, it knows it has returned > home > > and sets the lifetime to zero in the binding update it sends to the home > > agent. > > > > I would suggest removing it and treat only the binding update with > lifetime > > set to zero as a de-registration. It would help in simplifying the > > de-registration procedure a little bit. > > > > Vijay > > > > > > Charles E. Perkins wrote: > >> > >> Hello folks, > >> > >> So far, I did not find a persuasive reason to make > >> changes to RFC 3775 related to this issue with > >> DSMIPv6. Unless someone can suggest text that might > >> be needed, I would recommend to close this issue > >> without modification to rfc3775bis. > >> > >> Regards, > >> Charlie P. > >> > >> > >> > >> mext wrote: > >> > Ticket #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen > >> > ] > >> > > >> > DSMIPv6 BU format and RFC 3775 > >> > Tero Kauppinen > >> > > >> > While reading the current version of DSMIPv6 > >> > (draft-ietf-mip6-nemo-v4traversal-06) and I came across with one > >> > sentence which strikes me as odd. > >> > > >> > "4.2. NAT detection and traversal > >> > > >> > NAT detection is done when the initial binding update message is > >> > sent > >> > from the mobile node to the home agent. When located in an IPv4- > only > >> > foreign link, the mobile node sends the binding update message > >> > encapsulated in UDP and IPv4. The source address of the IPv6 > packet > >> > is the mobile node's IPv6 home address. The destination address > is > >> > the IPv6 address of the home agent. The IPv4 header contains the > >> > IPv4 > >> > care-of address in the source address field and the IPv4 address > of > >> > the home agent in the destination address field. > >> > > >> > When the home agent receives the encapsulated binding update it > >> > compares the IPv4 address of the source address field in the > IPv4 > >> > header with the IPv4 address in the source address of the IPv6 > >> > header." > >> > > >> > If the IPv6 header contains the mobile node's IPv6 home address, > how > >> > can > >> > it ever match with the IPv4 address of the source address field in > the > >> > IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the Lifetime > >> > specified in the Binding Update is zero or the specified care-of > >> > address > >> > matches the home address for the binding, then this is a request to > >> > delete the cached binding for the home address." > >> > > >> > So, > >> > > >> > (1) Should the IPv6 header actually contain an IPv4 mapped IPv6 > >> > address? > >> > > >> > Or > >> > > >> > (2) Should the IPv4 address of the source address field in the IPv4 > >> > header be compared with the address specified in the packet's IPv4 > CoA > >> > option? > >> > > >> > ------------------------------------------------------------------- > -- > >> > > >> > George Tsirtsis > >> > > >> > I would go with (2), as I think this was the intention (i.e., I > >> > consider this a typo). > >> > > >> > It is not, however, clear to me what the relevance of the quoted > text > >> > from 3775 is. > >> > Whether (1) or (2) is used it should not result in the condition of > >> > CoA==HoA in the BU. > >> > > >> > ------------------------------------------------------------------- > -- > >> > > >> > Pascal Thubert > >> > > >> > I favor 1) and the text seems to be a leftover from your original > draft > >> > which worked that way. > >> > But I remember that the question was cut against it by the chairs > >> > because there was no proper consensus either way. > >> > > >> > Now I really hate the idea of a BU process that would have to > figure if > >> > a BU is a registration or deregistration just because the packet > was > >> > received over an interface that is an IPv4 tunnel as opposed to the > >> > Home > >> > Link. That seems plain wrong. I have a tendency to think that > what's > >> > wrong is really RFC 3775 (lifetime 0 should be the way to > deregister) > >> > but unless we revise it, I'd suggest we keep consistent with that > >> > foundation RFC. If we REALLY do not want a mapped address as > source, > >> > then maybe we could use the UNSPECIFIED address instead? > >> > > >> > ------------------------------------------------------------------- > -- > >> > > >> > Vijay Devarapalli : > >> > > >> > > "4.2. NAT detection and traversal > >> > > > >> > > NAT detection is done when the initial binding update message > is > >> > sent > >> > > from the mobile node to the home agent. When located in an > >> > IPv4-only > >> > > foreign link, the mobile node sends the binding update message > >> > > encapsulated in UDP and IPv4. The source address of the IPv6 > packet > >> > > is the mobile node's IPv6 home address. The destination address > is > >> > > the IPv6 address of the home agent. The IPv4 header contains > the > >> > IPv4 > >> > > care-of address in the source address field and the IPv4 > address of > >> > > the home agent in the destination address field. > >> > > > >> > > When the home agent receives the encapsulated binding update it > >> > > compares the IPv4 address of the source address field in the > IPv4 > >> > > header with the IPv4 address in the source address of the IPv6 > >> > > header." > >> > > >> > This text is old. The home agent needs to compare it with the IPv4 > >> > address in the IPv4 CoA option. So this paragraph should actually > >> > say > >> > > >> > When the home agent receives the encapsulated binding update it > >> > compares the IPv4 address of the source address field in the > IPv4 > >> > header with the IPv4 address in the IPv4 care-of address option > >> > in the Binding Update. > >> > > >> > > If the IPv6 header contains the mobile node's IPv6 home address, > >> > how can > >> > > it ever match with the IPv4 address of the source address field in > the > >> > > IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the Lifetime > >> > > specified in the Binding Update is zero or the specified care-of > >> > address > >> > > matches the home address for the binding, then this is a request > to > >> > > delete the cached binding for the home address." > >> > > >> > This text needs to be clarified in RFC 3775. Regarding the actual > >> > "violation", I don't think there is a conflict. The DS-MIPv6 > >> > binding update has an IPv4 CoA option (similar to the alt CoA > >> > option) which when present dictates a different behavior on the > >> > home agent that implements DS-MIPv6 extensions. It is more like > >> > DS-MIPv6 updates MIPv6 home agent behavior when the IPv4 CoA > >> > option is present. > >> > > >> > > >> > ------------------------------------------------------------------- > -- > >> > > >> > Basavaraj Patil > >> > > >> > Option 2 is what I believe the intent has been. Option 2 IMO is a > >> > better > >> > choice even though it does diverge from RFC3775 design. But given > that > >> > this > >> > I-D is extending the base MIP6 RFC, I believe it is okay to proceed > >> > with > >> > option 2. > >> > > >> > > >> > ------------------------------------------------------------------- > -- > >> > > >> > Hesham Soliman > >> > > >> > => The relevance of the quote from 3775 is that we're putting the > HoA > >> > in > >> > the > >> > src address of a normal registration. The text says that the > receiver > >> > of a > >> > BU with the HoA in the src address field would assume it's a > >> > de-registration, which is obviously not what we want. Hence my > question > >> > about violating 3775. > >> > > >> > > >> > -----------------------------------+-------------------------------- > -------- > >> > > >> > Reporter: charliep@computer.org | Owner: > charliep@computer.org > >> > Type: enhancement | Status: new > >> > Priority: minor | Milestone: > >> > Component: RFC3775 changes > >> > | Version: Severity: Active WG > >> > Document | Keywords: > >> > -----------------------------------+-------------------------------- > -------- > >> > > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 30 17:25:42 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DADA43A6B22; Mon, 30 Jun 2008 17:25:42 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99E5F3A6B23 for ; Mon, 30 Jun 2008 17:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9O99Xsgzoe-z for ; Mon, 30 Jun 2008 17:25:40 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D750A3A6B22 for ; Mon, 30 Jun 2008 17:25:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,729,1204531200"; d="scan'208";a="46886401" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 30 Jun 2008 17:25:52 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m610PqQl006425; Mon, 30 Jun 2008 17:25:52 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m610PqS6024012; Tue, 1 Jul 2008 00:25:52 GMT Date: Mon, 30 Jun 2008 17:25:52 -0700 (PDT) From: Sri Gundavelli To: Vijay Devarapalli In-Reply-To: Message-ID: References: <063.eee1db399c39efaaf5a50a65984c5bdf@tools.ietf.org> <4869122D.5090701@computer.org> <48696974.2030503@wichorus.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=316; t=1214871952; x=1215735952; 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]=20[mext]=20#7=3A=20DSMIPv6=20BU= 20format=20and=20RFC=203775=20[Tero=20Kauppinen=0A=20] |Sender:=20; bh=A7aJCQWxqhCToadJGC/WUa2zYpgiJQ8w8/k6Xxjt06s=; b=ROPuaWqTu5bduDeU9BR/wh7yZT3lFn9Xr3RngtB0+QZl7d+JwKC60XvFr0 msuTC4nVzRTfJg430+SjOOJdA5Q+RXUrH428bTZ7y3MWhUOr9AE+Bt9rhnTf 0nkSytMKEQ; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: charliep@computer.org, mext@ietf.org, tero.kauppinen@ericsson.com Subject: Re: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > The mobile node can't claim its home address until the HA stops proxy > neighbor discovery for the home address. > Sure. This is clearly an error case. I dont see a point of the HA maintaining a binding with CoA=HoA. HA can release the binding safely. Unless, there are some other usecases ... Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 30 17:39:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14ED3A6B3B; Mon, 30 Jun 2008 17:39:15 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76F183A6B3B for ; Mon, 30 Jun 2008 17:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEE5YiKGkGtt for ; Mon, 30 Jun 2008 17:39:13 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 9A8913A6B12 for ; Mon, 30 Jun 2008 17:39:13 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Jun 2008 20:39:21 -0400 Message-ID: In-Reply-To: <87ej6hzr5x.fsf@natisbad.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Issue #2: Recommendation for closure on on "Use of DHAADmechanism" Thread-Index: AcjZGYd0p25kl+7gRTq9V6CBhLRQrAB+Sq2w References: <200803271024.49601.julien.IETF@laposte.net><48654BFB.5000005@earthlink.net> <87ej6hzr5x.fsf@natisbad.org> From: "Vijay Devarapalli" To: "Arnaud Ebalard" , "Charles E. Perkins" Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Issue #2: Recommendation for closure on on "Use of DHAADmechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > * Finally, it should be noted that the specification of ICMP to carry > > * DHAAD incurs a certain deployability risk related to the perceived > > * insecurity of ICMP messages. Many ISPs are blocking ICMP on all > links > > * except the first hop, because ICMP is known to be a vehicle for DoS > > * attacks and other sorts of threats. > > IMHO, this should go. I agree, but for a different reason though. If ICMP is blocked, isn't it obvious that DHAAD messages can't make it through? Viujay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 30 17:48:14 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C86C3A6B12; Mon, 30 Jun 2008 17:48:14 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C703E3A6B12 for ; Mon, 30 Jun 2008 17:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQnEkFBKbDd2 for ; Mon, 30 Jun 2008 17:48:11 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 483253A69B2 for ; Mon, 30 Jun 2008 17:48:11 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Jun 2008 20:48:19 -0400 Message-ID: In-Reply-To: <48653AAD.6020909@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Issue #1: Last accepted SQN Thread-Index: AcjYiTYF9gkivEyGSRS2PzRtFmkP0QCisS2A References: <48653AAD.6020909@earthlink.net> From: "Vijay Devarapalli" To: "Charles E. Perkins" , Subject: Re: [MEXT] Issue #1: Last accepted SQN X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Charlie, > ======================================================================== > > OLD TEXT: > > o The Sequence Number field matches the Sequence Number sent by the > mobile node to this destination address in an outstanding Binding > Update. > > ======================================================================== > > NEW TEXT: > > o The Sequence Number field matches the Sequence Number sent by the > mobile node to this destination address in an outstanding Binding > Update, and the Status field is not 135. > > ... and, just before the bulleted text for Status field #1 (currently on > pg. 139): > > o Additionally, if the Binding Acknowledgement correctly passes > authentication and the Status field value is 135 (Sequence Number > out of window), then the mobile node MUST update its binding > sequence number appropriately to match the sequence number given > in the Binding Acknowledgement. Otherwise, if the Status field > value is 135 but the the Binding Acknowledgement does not pass > authentication, the message MUST be silently ignored. > > ======================================================================== > > If this is O.K., I plan to use it as a recommendation for resolution > of this issue. This sounds good to me. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jun 30 18:21:23 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F383A69B2; Mon, 30 Jun 2008 18:21:22 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EE2F3A69B2 for ; Mon, 30 Jun 2008 18:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbkjUwVVDwrA for ; Mon, 30 Jun 2008 18:21:19 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 789293A6800 for ; Mon, 30 Jun 2008 18:21:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 45CB5C8031 for ; Mon, 30 Jun 2008 21:21:27 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15386-18 for ; Mon, 30 Jun 2008 21:21:23 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Mon, 30 Jun 2008 21:21:23 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jun 2008 21:21:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Jun 2008 21:22:57 -0400 Message-ID: <4D35478224365146822AE9E3AD4A26660302C052@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 [TeroKauppinen ] Thread-Index: AcjbChe/sGvJxlr9SAi8/S15JzVU+QABcWQgAAG90tA= From: "Koodli, Rajeev" To: "Vijay Devarapalli" , "Sri Gundavelli" X-OriginalArrivalTime: 01 Jul 2008 01:21:23.0758 (UTC) FILETIME=[C69794E0:01C8DB18] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: charliep@computer.org, tero.kauppinen@ericsson.com, mext@ietf.org Subject: Re: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 [TeroKauppinen ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, > The mobile node can't claim its home address until the HA stops proxy > neighbor discovery for the home address. > > RFC 3775 is quite explicit about this. > > In > particular, the mobile node is unable to use its home address as the > Source Address in the Neighbor Solicitation until the home agent > stops defending the home address. > [RKo:>] To stop proxying, ND (2461, 4861) allows a node to send the Unsolicited NA with 'O' bit set to 1, which has the effect of over-riding proxy NC entry. I remember 2461 stating that use of 'O=1' allows the actual node (i.e., not the proxy) to announce its presence on the link. A de-registration BU only informs the HA. Unsolicited NA with 'O=1' informs all nodes on the link. We could consider UNA to be sent to address the proxying issue. However, I guess we still need BU with lifetime=0, perhaps because you can secure the BU today (and SEND is not deployed, yet). -Rajeev > Vijay > > the HA can only release the binding as it cant > > defend the address. Is this not an inconsistent state, both HA and > > MN defending that address ? May be the best thing for the HA is > > log the error and release the binding. > > > > Sri > > > > > > On Mon, 30 Jun 2008, Vijay Devarapalli wrote: > > > > > Hi Charlie, > > > > > > I think the text in RFC 3775 needs to be fixed. RFC 3775 assumes > that a > > > binding update is sent with the home address option and with the > care-of > > > address stored either in the source address in the IPv6 header or in > > > alternate care-of address option. So it specifies that if the > care-of > > address > > > matches the home address in the home address option, it is safe for > the > > home > > > agent to assume that the binding update was sent from the home link > and > > can > > > be treated as a de-registration BU. > > > > > > In practice, I have never seen a Binding Update, where the lifetime > is > > > non-zero and the care-of address matches the home address, from a > mobile > > node > > > implementation. Only the TAHI test suite sends such a binding > update, > > since > > > they have to test conformance to RFC 3775. :) If the mobile node > detects > > that > > > its care-of address matches the home address, it knows it has > returned > > home > > > and sets the lifetime to zero in the binding update it sends to the > home > > > agent. > > > > > > I would suggest removing it and treat only the binding update with > > lifetime > > > set to zero as a de-registration. It would help in simplifying the > > > de-registration procedure a little bit. > > > > > > Vijay > > > > > > > > > Charles E. Perkins wrote: > > >> > > >> Hello folks, > > >> > > >> So far, I did not find a persuasive reason to make > > >> changes to RFC 3775 related to this issue with > > >> DSMIPv6. Unless someone can suggest text that might > > >> be needed, I would recommend to close this issue > > >> without modification to rfc3775bis. > > >> > > >> Regards, > > >> Charlie P. > > >> > > >> > > >> > > >> mext wrote: > > >> > Ticket #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen > > >> > ] > > >> > > > >> > DSMIPv6 BU format and RFC 3775 > > >> > Tero Kauppinen > > >> > > > >> > While reading the current version of DSMIPv6 > > >> > (draft-ietf-mip6-nemo-v4traversal-06) and I came across with > one > > >> > sentence which strikes me as odd. > > >> > > > >> > "4.2. NAT detection and traversal > > >> > > > >> > NAT detection is done when the initial binding update > message is > > >> > sent > > >> > from the mobile node to the home agent. When located in an > IPv4- > > only > > >> > foreign link, the mobile node sends the binding update > message > > >> > encapsulated in UDP and IPv4. The source address of the IPv6 > > packet > > >> > is the mobile node's IPv6 home address. The destination > address > > is > > >> > the IPv6 address of the home agent. The IPv4 header contains > the > > >> > IPv4 > > >> > care-of address in the source address field and the IPv4 > address > > of > > >> > the home agent in the destination address field. > > >> > > > >> > When the home agent receives the encapsulated binding update > it > > >> > compares the IPv4 address of the source address field in the > > IPv4 > > >> > header with the IPv4 address in the source address of the > IPv6 > > >> > header." > > >> > > > >> > If the IPv6 header contains the mobile node's IPv6 home > address, > > how > > >> > can > > >> > it ever match with the IPv4 address of the source address field > in > > the > > >> > IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the > Lifetime > > >> > specified in the Binding Update is zero or the specified > care-of > > >> > address > > >> > matches the home address for the binding, then this is a > request to > > >> > delete the cached binding for the home address." > > >> > > > >> > So, > > >> > > > >> > (1) Should the IPv6 header actually contain an IPv4 mapped IPv6 > > >> > address? > > >> > > > >> > Or > > >> > > > >> > (2) Should the IPv4 address of the source address field in the > IPv4 > > >> > header be compared with the address specified in the packet's > IPv4 > > CoA > > >> > option? > > >> > > > >> > > ------------------------------------------------------------------- > > -- > > >> > > > >> > George Tsirtsis > > >> > > > >> > I would go with (2), as I think this was the intention (i.e., I > > >> > consider this a typo). > > >> > > > >> > It is not, however, clear to me what the relevance of the > quoted > > text > > >> > from 3775 is. > > >> > Whether (1) or (2) is used it should not result in the > condition of > > >> > CoA==HoA in the BU. > > >> > > > >> > > ------------------------------------------------------------------- > > -- > > >> > > > >> > Pascal Thubert > > >> > > > >> > I favor 1) and the text seems to be a leftover from your > original > > draft > > >> > which worked that way. > > >> > But I remember that the question was cut against it by the > chairs > > >> > because there was no proper consensus either way. > > >> > > > >> > Now I really hate the idea of a BU process that would have to > > figure if > > >> > a BU is a registration or deregistration just because the > packet > > was > > >> > received over an interface that is an IPv4 tunnel as opposed to > the > > >> > Home > > >> > Link. That seems plain wrong. I have a tendency to think that > > what's > > >> > wrong is really RFC 3775 (lifetime 0 should be the way to > > deregister) > > >> > but unless we revise it, I'd suggest we keep consistent with > that > > >> > foundation RFC. If we REALLY do not want a mapped address as > > source, > > >> > then maybe we could use the UNSPECIFIED address instead? > > >> > > > >> > > ------------------------------------------------------------------- > > -- > > >> > > > >> > Vijay Devarapalli : > > >> > > > >> > > "4.2. NAT detection and traversal > > >> > > > > >> > > NAT detection is done when the initial binding update > message > > is > > >> > sent > > >> > > from the mobile node to the home agent. When located in an > > >> > IPv4-only > > >> > > foreign link, the mobile node sends the binding update > message > > >> > > encapsulated in UDP and IPv4. The source address of the > IPv6 > > packet > > >> > > is the mobile node's IPv6 home address. The destination > address > > is > > >> > > the IPv6 address of the home agent. The IPv4 header > contains > > the > > >> > IPv4 > > >> > > care-of address in the source address field and the IPv4 > > address of > > >> > > the home agent in the destination address field. > > >> > > > > >> > > When the home agent receives the encapsulated binding > update it > > >> > > compares the IPv4 address of the source address field in > the > > IPv4 > > >> > > header with the IPv4 address in the source address of the > IPv6 > > >> > > header." > > >> > > > >> > This text is old. The home agent needs to compare it with the > IPv4 > > >> > address in the IPv4 CoA option. So this paragraph should > actually > > >> > say > > >> > > > >> > When the home agent receives the encapsulated binding update > it > > >> > compares the IPv4 address of the source address field in the > > IPv4 > > >> > header with the IPv4 address in the IPv4 care-of address > option > > >> > in the Binding Update. > > >> > > > >> > > If the IPv6 header contains the mobile node's IPv6 home > address, > > >> > how can > > >> > > it ever match with the IPv4 address of the source address > field in > > the > > >> > > IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the > Lifetime > > >> > > specified in the Binding Update is zero or the specified > care-of > > >> > address > > >> > > matches the home address for the binding, then this is a > request > > to > > >> > > delete the cached binding for the home address." > > >> > > > >> > This text needs to be clarified in RFC 3775. Regarding the > actual > > >> > "violation", I don't think there is a conflict. The DS-MIPv6 > > >> > binding update has an IPv4 CoA option (similar to the alt CoA > > >> > option) which when present dictates a different behavior on the > > >> > home agent that implements DS-MIPv6 extensions. It is more like > > >> > DS-MIPv6 updates MIPv6 home agent behavior when the IPv4 CoA > > >> > option is present. > > >> > > > >> > > > >> > > ------------------------------------------------------------------- > > -- > > >> > > > >> > Basavaraj Patil > > >> > > > >> > Option 2 is what I believe the intent has been. Option 2 IMO is > a > > >> > better > > >> > choice even though it does diverge from RFC3775 design. But > given > > that > > >> > this > > >> > I-D is extending the base MIP6 RFC, I believe it is okay to > proceed > > >> > with > > >> > option 2. > > >> > > > >> > > > >> > > ------------------------------------------------------------------- > > -- > > >> > > > >> > Hesham Soliman > > >> > > > >> > => The relevance of the quote from 3775 is that we're putting > the > > HoA > > >> > in > > >> > the > > >> > src address of a normal registration. The text says that the > > receiver > > >> > of a > > >> > BU with the HoA in the src address field would assume it's a > > >> > de-registration, which is obviously not what we want. Hence my > > question > > >> > about violating 3775. > > >> > > > >> > > > >> > > -----------------------------------+-------------------------------- > > -------- > > >> > > > >> > Reporter: charliep@computer.org | Owner: > > charliep@computer.org > > >> > Type: enhancement | Status: new > > >> > Priority: minor | Milestone: > > >> > Component: RFC3775 changes > > >> > | Version: Severity: Active WG > > >> > Document | Keywords: > > >> > > -----------------------------------+-------------------------------- > > -------- > > >> > > > >> > > >> _______________________________________________ > > >> MEXT mailing list > > >> MEXT@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 1 01:55:21 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6F503A69CF; Tue, 1 Jul 2008 01:55:21 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6987B3A69CF for ; Tue, 1 Jul 2008 01:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bT6ER6j+Mvj for ; Tue, 1 Jul 2008 01:55:19 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 941B83A6782 for ; Tue, 1 Jul 2008 01:55:19 -0700 (PDT) Received: from localhost ([127.0.0.1]:47047 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KDbdz-0004da-1Y; Tue, 01 Jul 2008 10:55:24 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: julien.ietf@laposte.net X-Trac-Project: mext Date: Tue, 01 Jul 2008 08:55:22 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/7#comment:1 Message-ID: <072.1340302c9b548066f73c22252af5f822@tools.ietf.org> References: <063.eee1db399c39efaaf5a50a65984c5bdf@tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <063.eee1db399c39efaaf5a50a65984c5bdf@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: julien.ietf@laposte.net, tero.kauppinen@ericsson.com, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: tero.kauppinen@ericsson.com, mext@ietf.org Subject: Re: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ticket #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen ] >From julien.ietf@laposte.net): * component: RFC3775 changes => draft-ietf-mext-rfc3775bis ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: enhancement | Status: new Priority: minor | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: Active WG Document | Resolution: Keywords: | ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext